II · THE IDEA · ARTIFICIAL INTELLIGENCE
Standardised Tool Connections
▶ Listen · narrated
Building a tool for one model meant rewriting it for the next. MCP proposes a common language, so tools and models connect through a shared protocol rather than point-to-point integrations.
At a glance
- What it is
- An open protocol defining how models discover and invoke tools
- Architecture
- Client-server over JSON-RPC, with hosts, clients and servers
- Current status
- Open specification with reference implementations
- Key benefit
- One tool implementation works with any compliant model or application
Imagine you have a universal adapter for power plugs. Instead of carrying a different adapter for every country, you carry one adapter and every socket works with it. MCP is a universal adapter for tools and models. Before MCP, if you built a tool — say, something that checks your calendar — you had to write separate code to make it work with each different model or application. One version for this app, another version for that model. With MCP, you write the tool once, following the protocol's rules, and any application that understands MCP can use it immediately. The tool describes itself in a standard format, listing what it can do and what information it needs. The application reads that description and knows how to ask the tool to do things. When the model wants to check your calendar, the application translates that request into the standard MCP format, sends it to your calendar tool, gets the answer back, and gives it to the model. The model doesn't need to know anything about MCP; the application handles the translation. The benefit is that tools become portable. A calendar tool that works with one application will work with any other application that speaks MCP, without rewriting.
MCP is a client-server protocol built on JSON-RPC 2.0. The architecture defines three roles: the host is the user-facing application, the client is the MCP-speaking component within the host, and the server is a separate process that exposes tools, resources or prompts. Communication is message-based, with requests and responses encoded as JSON. The reference implementation uses stdio as the transport layer, so servers are typically local processes launched by the host, reading from stdin and writing to stdout.
The lifecycle begins with initialization. The host spawns the server process and sends an initialize request containing protocol version and client capabilities. The server responds with its own capabilities, including lists of available tools, resources and prompts. Each tool is described using JSON Schema, specifying parameter names, types, and constraints. Resources are identified by URI. Prompts are named templates with optional arguments.
To invoke a tool, the client sends a tools/call request with the tool name and a JSON object of arguments. The server executes the tool and returns a result or an error. Resources are fetched with resources/read, supplying a URI. Prompts are retrieved with prompts/get, optionally supplying arguments that customize the template.
The protocol supports sampling, allowing a server to request that the host invoke the model on its behalf, but this is optional and not all hosts implement it. Error handling uses standard JSON-RPC error codes, extended with MCP-specific codes for cases like invalid tool arguments or missing resources.
Because the protocol is transport-agnostic, remote servers are possible, but the stdio pattern is simpler and avoids network overhead. Security is inherited from the operating system: the server runs with the permissions of the user who launched the host. The host is responsible for policy decisions — whether to execute a tool call automatically, whether to show the user, whether to allow it at all. The protocol itself is neutral.
Servers are stateless between requests, though they may maintain internal state. The host may connect to multiple servers simultaneously, and the client is responsible for routing requests to the correct server based on which tools or resources were declared during initialization. The protocol does not define service discovery; the host must be configured with the location and launch command for each server.
Look closer
Three roles, not two
MCP defines three distinct roles. The host is the application the user interacts with — Claude Desktop, for instance. The client is the component inside the host that speaks MCP. The server is the process that exposes tools, prompts or resources. A single host may connect to many servers simultaneously, each offering different capabilities. This three-part division means the model itself is not necessarily aware of MCP; the host mediates, translating between the model's expectations and the protocol's messages.
Transport is local by default
The reference implementation uses standard input and output streams, so an MCP server is typically a local process launched by the host. This keeps the protocol simple and avoids network configuration, but it also means the server runs with the permissions of the user who started the host. Remote servers are possible — the protocol layer is transport-agnostic — but the documented pattern is stdio, which makes deployment straightforward and security boundaries clear.
Discovery is active, not passive
When a host connects to an MCP server, it sends an initialize request and receives back a list of capabilities: which tools are available, which resources, which prompts. The server describes each tool with a JSON Schema, specifying parameter names, types and constraints. The model does not search a registry or guess at what might exist; it is handed a manifest. This means adding a new tool is a matter of updating the server's capability list, not teaching the model about it separately.
The story
Before MCP, connecting a model to a tool meant writing integration code specific to both. A calendar plugin for one application could not be reused in another without translation. Each new model, each new host environment, required its own adapter. The effort scaled quadratically: ten models and ten tools meant up to a hundred bespoke integrations, each with its own assumptions about authentication, error handling and data formats.
The Model Context Protocol addresses this by defining a single interface. A tool author writes an MCP server once, describing the tool's parameters in JSON Schema and implementing handlers for each operation. Any application that speaks MCP — the host — can then connect to that server, discover what it offers, and invoke its tools. The model itself interacts with tools as it always has, by generating structured requests; the host translates those requests into MCP calls and returns the results.
The architecture is deliberately minimal. Communication happens over JSON-RPC 2.0, a lightweight remote procedure call protocol. Messages are JSON objects; there is no binary encoding, no custom transport. The reference implementation uses stdio, so an MCP server is just a program that reads requests from standard input and writes responses to standard output. This makes servers easy to write in any language that can handle text streams and JSON.
The protocol defines three kinds of capability. Tools are functions the model can call: search a database, send an email, read a file. Resources are data the server can provide: the contents of a document, the state of a system, a list of recent transactions. Prompts are reusable templates or workflows the server offers, which the host can present to the user or invoke programmatically. A single server can expose any combination of these.
When a host starts, it reads a configuration file listing which MCP servers to launch and how to reach them. It spawns each server process, sends an initialize handshake, and receives back the server's declared capabilities. From that point on, the host can invoke tools by sending a tools/call request with the tool name and arguments, or fetch a resource by sending a resources/read request with a URI. The server processes the request, performs whatever work is required, and returns a result or an error.
The model never sees MCP directly. When the model generates a tool call — typically as a structured object in its output — the host recognises it, maps it to an MCP request, sends that request to the appropriate server, waits for the response, and feeds the result back to the model as part of the conversation. The model experiences this as a simple request-response cycle; the protocol machinery is hidden.
This separation is deliberate. MCP is not a model API; it is a tool API. The host is responsible for translating between the two, which means different hosts can adopt different strategies. One might show the user every tool call before executing it. Another might allow automatic execution within certain boundaries. The protocol itself is neutral on policy.
Because the protocol is open and the reference implementations are available, anyone can write a server. A developer who builds an MCP server for accessing a database can publish it, and any MCP-compliant host can use it immediately. The same server works with Claude Desktop, with a command-line agent, with a web application, without modification. The integration cost drops from quadratic to linear: each tool is written once, each host implements MCP once, and every combination works.
Why it mattered then
The immediate motivation was proliferation. As models became capable of using tools, each integration was built separately. Anthropic's own tools worked with Claude but not with other models. Third-party developers who wanted their tools to work across multiple environments faced a choice: write separate integrations for each, or pick one and accept limited reach. Neither scaled. The cost of integration was becoming a barrier to experimentation, and the lack of a common interface meant tools were often locked to a single vendor or application. MCP was proposed in 2024 as a way to decouple tools from hosts, so that effort spent building a tool would compound rather than fragment.
Why it matters now
The protocol is recent enough that adoption is still unfolding, but the pattern it represents — a shared interface layer between models and external systems — is likely to persist. As models are embedded in more environments, the need for a standard way to expose capabilities grows. MCP is one answer, and whether it becomes the dominant standard or simply influences others, the idea that tools should be portable across models is now established. For developers, it means a tool written today has a longer useful life. For users, it means less lock-in: the tools you rely on are not tied to a single application or vendor. The protocol is open, so it can be extended, adapted or replaced as requirements change, but the architectural principle — separate the model from the tool, and mediate between them with a well-defined protocol — is sound.
The surprising detail
The protocol is transport-agnostic, but the reference implementation uses stdio, which means MCP servers are local processes rather than network services. This is unusual in an era when most integration happens over HTTP. The choice reflects a specific set of priorities: simplicity, security and low latency. A local process avoids network configuration, certificate management and firewall rules. It inherits the user's permissions, which makes the security model explicit. And it can respond in microseconds rather than milliseconds. The trade-off is that remote servers require additional work, and the stdio pattern assumes the host and server are on the same machine. For many use cases, that assumption holds, but it is not universal, and the protocol's designers have acknowledged that remote transport will matter as adoption grows.
Remember this
MCP is a common interface so that tools written once work with any compliant host, replacing the need for bespoke integrations between each model and each tool.
Test yourself
A company builds an MCP server that exposes a tool for querying their internal database. They want to allow some users to run the tool automatically, but require others to approve each query before it executes. Where in the MCP architecture does this policy decision belong, and why?
The policy belongs in the host, not in the server or the protocol. MCP defines how the host communicates with the server — the format of requests and responses — but it does not dictate when or whether a tool should be invoked. The host is responsible for mediating between the user and the model, and that includes enforcing policy. One host might execute every tool call automatically; another might prompt the user for confirmation; a third might allow automatic execution only for certain tools or certain users. The server simply responds to requests when they arrive. This separation means the same server can be used in different contexts with different security requirements, without modification. The protocol is neutral; the host is where judgement lives.
Go deeper
- What is the Model Context Protocol (MCP)? - Model Context Protocol · modelcontextprotocol.io
- GitHub - modelcontextprotocol/modelcontextprotocol: Specification and documentation for the Model Context Protocol · GitHub · github.com
Image: Original diagram, The Daily Triptych. Licence: Original work. Source.