What is MCP?
MCP stands for Model Context Protocol. It is an open standard that describes how a language model learns which tools are available to it, and how it calls them.
The problem it addresses is unglamorous and expensive. Before a standard existed, every link between a model and a business system was custom code. Connect three models to five systems and you have written fifteen bridges, each with its own quirks, its own authentication and its own maintenance burden. Change model provider and you start again.
MCP turns that into a client-server architecture. A server declares what it offers: tools that perform actions, resources that supply data, prompts that frame a task. Any compatible client can then use them without knowing anything about the implementation behind.
Why MCP matters
- Integration stops multiplying. Effort follows the number of tools, not tools multiplied by models. Across a set of internal systems, that is the difference between a pilot and something maintainable.
- Changing provider is no longer a rewrite. If the model changes, the servers stay. That alone removes one of the main objections to committing to AI integration.
- Permissions become explicit. Each tool declares its inputs and outputs, so scoping becomes a design decision written down rather than an assumption buried in code.
- Reuse becomes real. A server written for one internal system serves every future assistant and agent, instead of being consumed by the single project that paid for it.
The strategic point is that MCP makes AI integration an infrastructure decision rather than a series of experiments. That changes who needs to be in the room when it is planned.
How it works
Three concepts carry most of the standard.
Tools are actions the model can invoke: read a record, create an invoice, send a message. Each declares what it accepts and what it returns, which lets the model reason about whether calling it is appropriate.
Resources are data the model can read rather than modify: a document, a table, a file. The distinction matters because it separates reading from writing, which is the first line of any sensible permission model.
Prompts are reusable task templates a server can offer, so a proven way of asking for something does not have to be reinvented by every client.
Around that, a server handles authentication and decides what it exposes. The client, which may be a conversational interface or an agent, discovers what is available and calls it. Nothing is assumed about the model, and that is precisely why the arrangement survives a change of provider.
The work in a real project is not writing the server. It is deciding the scope: which reads are allowed, which writes require a confirmation step, what happens when a call fails, and how each call is logged. A tool defined too broadly is the main source of unpredictable behaviour.
Implementation
- Start with one system that several future use cases will need, typically the one holding customer or product data.
- List the actions before writing a line of code. Each should do one thing with a predictable result.
- Separate reads from writes and give each tool the narrowest rights that let it work.
- Require confirmation on any write with a consequence for a person, a contract or an invoice.
- Log every call with its inputs, its result and its caller. Without that, debugging is guesswork and an audit is impossible.
- Treat the protocol as an adapter. Keep business logic behind it, so a future change of standard costs you the adapter and nothing more.
Related technologies and tools
- Tool calling: the underlying model capability that MCP standardises and makes portable across providers.
- API gateways: the layer that already handles authentication and rate limiting, and which an MCP server should sit behind rather than replace.
- Retrieval layers: often exposed as MCP resources, so a model reads company documents through the same interface as everything else.
- Observability: tracing of every tool call, which makes the arrangement auditable rather than opaque.
- Identity and secret management: credentials scoped per tool, so no component holds broad access to everything.
Conclusion
MCP is plumbing, and plumbing is where AI projects succeed or stall. The interesting work looks like choosing a model and designing prompts, but the cost sits in integration, and integration is what a standard removes.
The sensible approach is to treat it as infrastructure: one system exposed properly, actions scoped narrowly, writes confirmed, everything logged, business logic kept behind the adapter. Built that way, each new assistant or agent inherits what already exists instead of paying again for the same connections.
