Model Context Protocol

The Model Context Protocol, or MCP, is an open standard for connecting AI applications to external tools, data sources, and services. It defines how a host application, such as a chat client or coding agent, discovers and calls capabilities exposed by a server, using JSON-RPC messages over a defined transport 1.

Anthropic published the protocol in November 2024 and described it as a universal connector for AI applications, in the way that a common port lets peripherals work with any computer. The analogy is marketing, but the problem it names is real: before MCP, every model-and-tool pair required its own integration 1.

This entry describes the integration problem, the protocol's architecture and primitives, how it is governed, why it spread quickly, and the security and standardisation questions that remain open.

A language model on its own can only produce text. To read a file, query a database, send a message, or open a ticket, it needs a tool: a function with a description, a parameter schema, and an implementation. Model providers offer function calling, but the interface is proprietary, and the same tool must be reimplemented for each provider's format.

The result was a matrix. Every tool needed a connector for every host, and every host needed to maintain connectors for every tool. For a company with a dozen internal systems and several model providers, the integration work grew faster than the number of systems.

MCP separates the tool from the model. A server exposes capabilities once, in a standard form, and any conformant host can use them. That decoupling is the protocol's central claim, and it is why the standard spread through developer tools before it spread through consumer products 2.

The protocol does not make a model more capable. It changes the cost of connecting capability to the model, which is a different and often more consequential thing.

MCP defines three roles. The host is the application the user interacts with: a chat client, an editor, or an agent runtime. Inside the host, a client maintains a connection to a server. The server exposes tools, resources, or prompts. One host can run several clients connected to several servers at once 3.

Connections are stateful. They begin with an initialisation handshake in which both sides exchange protocol versions and declare their capabilities. The client states which features it supports, the server states which features it offers, and neither sends a message the other has not agreed to handle 4.

After initialisation, communication is bidirectional. The client can list and call tools, read resources, and fetch prompts; the server can request sampling from the host's model, ask for filesystem roots, or elicit information from the user. This two-way design is what distinguishes MCP from a simple function-calling schema: the server can participate in the interaction rather than only respond to it.

All messages are JSON-RPC 2.0. That choice keeps the protocol simple and language-neutral, and it means implementations can be written in any language with a JSON library and a transport 3.

Servers expose three kinds of feature. Tools are functions the model can call, with a name, a description, and an input schema. Resources are readable data identified by a URI, such as a file, a database record, or a web page, which the host can attach to the model's context. Prompts are templates that a user or application can invoke to start a structured interaction 3.

The distinction is about control. Tools are model-controlled: the model decides when to call them, subject to host approval. Resources are application-controlled: the host decides what to load into context. Prompts are user-controlled: a person chooses when to apply a template. Keeping these separate lets a host apply different permission and consent rules to each.

Clients also expose features to servers. Sampling lets a server request a completion from the host's model without knowing which model it is. Roots tell the server which filesystem or URI boundaries it may operate within. Elicitation lets a server ask the user for information mid-task, such as a missing parameter or a confirmation.

The design is deliberately minimal. The protocol does not define what a tool means, how its output should be interpreted, or how conflicts between tools should be resolved. Those are left to the host, which is where most of the practical complexity lives.

The specification defines two transports. Standard input and output, or stdio, is used for local servers launched as subprocesses; it is simple, fast, and confined to the machine. Streamable HTTP is used for remote servers, carrying JSON-RPC messages over HTTP with optional server-sent events for streaming 3.

The HTTP transport replaced an earlier HTTP-plus-server-sent-events design, which had problems with reconnection and long-lived sessions. The revision that introduced Streamable HTTP also clarified how servers should be deployed behind load balancers and how sessions should be resumed.

Authorisation for remote servers uses OAuth. The specification separates the authorisation server from the resource server, requires PKCE for public clients, and defines how a client discovers which authorisation server to use. These details matter because an MCP server often acts on behalf of a user, and a token that is too broad gives the server access the user did not intend 3.

The protocol is versioned by date, and revisions have been frequent. The 2025-06-18 revision, for example, added structured tool output and elicitation, and refined the authorisation model. Implementations negotiate a version at initialisation, so a host and server can interoperate across nearby revisions 4.

Adoption was rapid. Within months of the announcement, model providers and developer-tool companies announced support, and community servers appeared for databases, version control, issue trackers, cloud platforms, and desktop applications. The protocol became a common way to expose a service to an agent 2.

Anthropic transferred the protocol to the Linux Foundation's Agentic AI Foundation in December 2025, alongside other agent-related projects. The move was intended to make the standard independent of its creator and to give it a governance structure with multiple members 5.

The specification is developed in public, with a schema, a changelog, and a process for proposals. That openness encouraged implementations, and it also meant that design decisions were made quickly, sometimes before their security implications were understood 6.

Governance remains a work in progress. A foundation can coordinate a standard, but it cannot compel the largest platforms to follow it, and several vendors maintain their own agent protocols alongside MCP.

MCP lowered the cost of connecting a model to a system. A service could publish one server and reach every conformant host, rather than building a separate integration for each assistant. For developers, that changed the unit of work from a connector to a capability.

It also created an ecosystem. Directories of servers, hosting services, and SDKs appeared, and the protocol became a way for smaller companies to distribute tools without negotiating with each model provider. The existence of a standard made tool use a market rather than a series of partnerships.

The design supported local-first use. A stdio server can run on a user's machine with the user's credentials, so an assistant can read local files or query a local database without sending data to a third party. That property was attractive to developers who wanted agent capability without cloud dependency.

Finally, MCP gave the agent conversation a concrete interface to argue about. Terms such as tool, resource, and sampling became shared vocabulary, and security researchers could analyse a common surface rather than a different one for every product.

MCP expands the attack surface of an AI application. A server is arbitrary code with access to data, and a host that connects to it is trusting it. The specification says as much: tools represent arbitrary code execution and their descriptions should be treated as untrusted unless the server is trusted 3.

The most discussed attack is tool poisoning. A malicious or compromised server can write instructions into a tool description that the model reads but the user does not, steering behaviour toward exfiltration or unintended actions. Related attacks include a confused deputy, where a server uses its privileges on behalf of a client that should not have them, and token theft, where a credential issued for one server is replayed against another.

A 2025 audit of popular MCP implementations found vulnerabilities that allowed command execution, data exfiltration, and bypasses of intended safeguards. The authors attributed many of them to implementation choices rather than to the protocol itself, which is a distinction that matters for remediation and is often lost in reporting 7.

The protocol cannot enforce consent. It specifies that hosts must obtain user approval before invoking tools and before exposing data to servers, but enforcement is left to the host, and many hosts optimise for convenience. The security of an MCP deployment therefore depends on the client as much as on the server.

The protocol is young, and its gaps are visible. Authorisation has been revised repeatedly, and implementations differ in which parts they support. Stateful sessions fit desktop clients but sit awkwardly with serverless deployment, where a connection may not survive between requests.

Tool quality is a separate problem. A server can expose a function with a vague description and a permissive schema, and the model will call it badly. The protocol standardises the interface, not the semantics, so the reliability of an agent depends on the care taken by server authors.

Discovery is immature. There is no universal registry that a host can query to find a trustworthy server, and directories that exist do not certify security or quality. Users install servers the way they install browser extensions, with similar risks and less scrutiny.

Finally, MCP does not solve the problem of long-horizon agency. It defines how a model calls a tool, not how an agent plans, recovers from failure, or decides when to stop. Those remain properties of the host application, and they are where most agent failures occur.

The first disagreement is whether MCP will become the universal standard or be absorbed into platform-specific interfaces. Supporters point to adoption across competing model providers and to the foundation structure. Sceptics point to the history of protocol wars and note that the largest platforms can support MCP while continuing to prefer their own APIs internally.

The second concerns openness and safety. An open protocol lets anyone publish a server, which accelerates the ecosystem and makes it harder to police. A closed protocol would centralise review and slow adoption. The MCP specification's own security section acknowledges the tension and places responsibility on implementers, which is either a pragmatic division of labour or an abdication, depending on who is describing it 3.

The third is about statefulness. Stateful connections enable rich interaction and complicate deployment, scaling, and failure recovery. Some implementers want a stateless mode for serverless environments; others argue that state is essential to the protocol's design and that the deployment problems should be solved in infrastructure.

A fourth dispute is political. MCP was created by one laboratory and donated to a foundation, and its governance now includes competitors. Whether that produces a neutral standard or a veneer of neutrality over a design shaped by its originator is a question that only the next few revisions will answer.