In this article
What MCP actually is
In late 2024, Anthropic published the Model Context Protocol — an open specification for how AI models communicate with external tools and data sources. The framing in the announcement was modest: a standard interface that makes it easier to connect AI to the things it needs to act. The implications are considerably larger than that framing suggests.
To understand why, it helps to understand what the problem was before MCP existed. When developers wanted to give a language model access to an external tool — say, the ability to query a database, browse the web, or read files from disk — they had two options. They could write a custom integration for each model and each tool, resulting in a combinatorial explosion of one-off glue code. Or they could use the function-calling feature built into a specific model's API, which worked for simple cases but broke down as the number of tools grew and as you tried to compose outputs from different agents.
MCP solves this by establishing a common language. An MCP server exposes capabilities using a standard schema. An MCP client — which could be a model, an agent, or an orchestrator — discovers those capabilities and calls them using the same protocol regardless of what system is on the other side. The integration is written once, on the server side, and any MCP-compatible client can use it immediately.
This is the same architectural move that made the web work. HTTP is a protocol for transferring documents. Any browser, on any device, can fetch any document from any server that speaks HTTP. Before HTTP, every document exchange system was proprietary. MCP applies the same logic to AI tool use.
The request/response pattern
The mechanics of an MCP interaction follow a clean request/response cycle. When a model decides it needs to use a tool, it constructs a tool call request — a structured JSON object containing the tool name and the input parameters. This request is sent to the MCP server hosting that tool. The server executes the underlying operation, formats the result, and returns a response in a standardised structure the model can parse and reason over.
In practice, the cycle looks like this for a file-system operation:
// Model requests a file read
{
"tool": "read_file",
"input": {
"path": "/workspace/config.json"
}
}
// Server returns the result
{
"content": [
{
"type": "text",
"text": "{ \"model\": \"claude-sonnet\", \"max_tokens\": 4096 }"
}
]
}The simplicity is deliberate. Each exchange is stateless from the protocol's perspective. The model maintains conversational state in its context window; the MCP server handles the mechanics of calling the underlying system. Neither side needs to know the internal implementation of the other. This is standard client/server separation — applied, for the first time, consistently across the AI tool-use space.
What makes the pattern powerful is that tool calls can be chained. A model reads a file, parses the result, decides it needs to query a database to cross-reference data in that file, sends a second tool call, receives a response, and continues reasoning. Each round trip extends the model's reach into external systems without any special handling in the model itself. The protocol is uniform; the tools behind it can be arbitrarily complex.
Tool definitions and server discovery
An MCP server describes its tools through a standardised capability manifest. When a client connects to a server, the first thing it does is request this manifest — a list of available tools with their names, descriptions, and input schemas. The schema is expressed in JSON Schema format, which means any existing JSON validation tooling can be used to verify inputs before they're sent.
A tool definition for a database query might look like:
{
"name": "query_database",
"description": "Execute a read-only SQL query against the production replica",
"inputSchema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "SQL SELECT statement to execute"
},
"limit": {
"type": "integer",
"description": "Maximum rows to return",
"default": 100
}
},
"required": ["query"]
}
}The description field is not incidental. Models use natural language to reason about which tool to call and how to call it. A well-written description is the primary interface between the model's reasoning and the server's implementation. Poorly written descriptions — vague, ambiguous, or incorrect — are the single most common cause of agent tool-use failures in production.
Server discovery has evolved as MCP has matured. Early implementations required manual configuration: tell the client the address of each server you want it to use. More recent patterns support dynamic discovery through registries — a client can query a registry server to find available MCP servers that match a capability it needs, connect automatically, and begin using tools without any manual setup. This is the foundation for truly self-configuring agent systems.
Real-world examples
The range of what MCP servers can expose is essentially unbounded — anything with a programmatic interface can be wrapped in an MCP server. The most common categories in production deployments cover four areas.
File systems and code: Read, write, and search files in a local or remote directory. This is the foundation for coding agents — a model that can read the full codebase, write new files, run tests, and iterate on failures without ever leaving its reasoning loop.
Databases: Query structured data, look up records, and in writable configurations, insert or update rows. A customer-service agent with database access can look up order history, check inventory, and issue credits in a single conversation flow without any API middleware.
External APIs: Any REST or GraphQL API can be wrapped in an MCP server. Search APIs, weather services, financial data feeds, internal business systems — if there's an API, there can be an MCP tool. This is where the long tail of enterprise integrations lives.
Browser control: MCP servers for browser automation let agents navigate the web, fill forms, extract structured data from pages, and interact with web applications that don't expose APIs. This is the escape hatch for systems that were never designed to be programmatically accessible.
Why this is different from function calling
Function calling — the feature available through most major model APIs — allows a model to request that specific functions be executed and their results returned. On the surface, this sounds like what MCP does. The distinction is architectural, and it matters.
Function calling is a feature of a specific model's API. The functions are defined in the API request, executed by whatever runtime is calling the API, and the results are passed back in the API response. The model has no concept of where the functions live, how they're discovered, or whether the same function is available in a different context. Each integration is bespoke.
MCP is a protocol that is independent of any specific model or API. A tool defined as an MCP server can be called by Claude, by any other MCP-compatible model, by an orchestrator agent, or by a human-built client application. The tool author writes the implementation once. Any compatible consumer can use it immediately, without any changes on either side.
The key difference: function calling creates a dependency between a specific model and a specific runtime. MCP creates a shared interface layer that any participant in an agent ecosystem can connect to. One is a feature. The other is infrastructure.
This distinction becomes critical at scale. A business with twenty internal systems and three different AI models in production would need sixty custom integrations under a function-calling-only model. Under MCP, it needs twenty MCP servers and three MCP clients. The combinatorial growth is eliminated.
Implications for multi-agent architectures
The most significant implication of MCP is what it enables for multi-agent systems. When agents can share tools through a common protocol, the architecture of a multi-agent system changes qualitatively.
In a system without MCP, each agent needs its own set of integrations. A researcher agent has its web search tools. An executor agent has its database tools. If the researcher needs to save something to the database, or the executor needs to search the web, the integration has to be rebuilt or duplicated for each agent. Toolsets are siloed per agent.
With MCP, tool servers are shared resources. An orchestrator can expose its tool registry to all worker agents. A specialist agent's tools — the web scraper an expert research agent uses, the code execution environment a coding agent relies on — can be called by any other agent that needs them, without duplicating the integration. Tools become composable infrastructure rather than per-agent features.
This also enables agent-to-agent tool use in a clean way. An orchestrator agent can call a specialist agent as if it were a tool — pass structured inputs, receive structured outputs. The specialist agent, from the protocol's perspective, is just another MCP server. The orchestrator doesn't need to know whether the tool it's calling is a database query, a file operation, or another agent running its own reasoning loop.
The result is that MCP provides the connective tissue for the kind of deeply integrated multi-agent systems that can actually replace operational layers in a business. Without it, those systems are built on custom glue code that breaks whenever anything changes. With it, they're built on a stable protocol that scales as the number of agents and tools grows — without the complexity growing proportionally.
This is still early infrastructure. The MCP ecosystem is expanding rapidly, but discovery, authentication, and versioning patterns are still maturing. The developers building on it now are establishing the patterns that the rest of the industry will standardise on. The protocol is the bet — on a world where AI agents are first-class participants in software systems, rather than bolted-on consumers of APIs that were never designed for them.