Protocols and standards

Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open specification that lets an AI application connect to external tools, data and prompt templates through a uniform JSON-RPC 2.0 interface, so a capability written once can be called by any client that speaks the protocol. It defines how a client discovers what a server offers, how it invokes it, and how the two negotiate a dated protocol revision — and it deliberately says nothing about which caller is allowed to invoke which capability, which is left to the deployment.

also called MCP · MCP protocol · MCP server · Anthropic MCP

MCP was published by Anthropic in November 2024 and is now implemented by most agent clients and a large catalogue of servers. Three roles make up a connection: a host application, a client inside it that holds one connection per server, and a server that exposes capabilities. A server offers three kinds of thing, and the distinction is about who chooses to use them rather than about their content — tools are invoked by the model, resources are read by the application, and prompts are selected by the user. A client can offer capabilities back: sampling, so the server can ask the host’s model for a completion, roots, so the server knows which parts of a filesystem are in scope, and elicitation, so the server can ask the user a question mid-task. Two transports are defined: stdio for a server running as a local subprocess, and Streamable HTTP for anything remote.

Streamable HTTP is one endpoint doing three jobs. A POST carries exactly one JSON-RPC message; a GET opens a server-to-client event stream for notifications such as tools/list_changed; a DELETE ends the session. The first call is initialize, which negotiates a protocol version and may issue an Mcp-Session-Id; every later request carries an MCP-Protocol-Version header, and 2025-03-26 is assumed when a peer omits it. Revisions are dated strings rather than semantic versions — 2024-11-05, which predates Streamable HTTP and uses the older two-endpoint HTTP+SSE transport, then 2025-03-26, 2025-06-18 and 2025-11-25, with later revisions adding a stateless dialect that carries no session at all. The dates are load-bearing rather than cosmetic: JSON-RPC batching was removed in 2025-06-18, and the authorisation section, introduced for HTTP transports in 2025-03-26, was reworked in 2025-06-18 to make an MCP server an OAuth 2.0 resource server that publishes protected-resource metadata and requires resource indicators, so a token minted for one server cannot be replayed at another.

Two properties of the protocol decide how it fails, and both are structural rather than implementation bugs. The first is that a tool descriptor is model input. A server supplies each tool’s name, description and JSON Schema, and that text is placed in front of the model as part of its instructions — so a server that rewrites a description has written a prompt injection with a delivery channel and an audience. The industry names for the two shapes of this are tool poisoning, where the descriptor carries an instruction from the start, and a rug pull, where a server behaves for a fortnight and then rewrites what its tools claim to do. Neither is detectable from the call itself, only from the change.

The second is that listing is not authorisation. Filtering tools/list to what a caller may use is a usability feature: a model can name a tool it never listed, because it read the name in a README, inferred it from a sibling, or simply guessed. So tools/call has to re-authorise independently of tools/list, and treating list filtering as access control is a documented anti-pattern rather than a subtle oversight. The implementable answer is a single endpoint standing in front of every upstream server, returning the union of their catalogues under a namespaced server.tool naming so colliding names stay addressable, filtering that union per caller, re-checking each call at execution against grants and argument policy, and hashing each descriptor at approval so a later rewrite quarantines the tool instead of reaching the model.

What MCP does not define is as important as what it does. It has no concept of the human an agent is acting for, no budget, no rate limit, no retention rule and no argument-level authority. Its authorisation section governs whether a caller may reach a server at all; it has nothing to say about whether this agent may call this tool with these arguments at this moment. That gap is not a defect in the specification — a transport that tried to encode an organisation’s authority model would be unimplementable — but it does mean that adopting MCP moves an access-control problem rather than solving one, and the number of servers a single client connects to makes the moved problem larger than it was.

in practice

One namespaced call, authorised twice

A coding agent holds a grant for jira.search_issues and no grant for jira.transition_issue. Its tools/list returns the union of two upstream catalogues filtered to its grants, so only the search tool appears. It then emits tools/call for jira.transition_issue anyway, because it read that name in a runbook. The correct behaviour is a JSON-RPC error -32602 that does not confirm the tool exists — an ungranted tool and a nonexistent tool must be indistinguishable, or the error message becomes an enumeration oracle for the whole catalogue. A tool the agent may see but may not use right now is different: that returns a normal result with isError set and a reason the model can act on, because the model needs to stop retrying rather than to learn a secret.

not the same as

What model context protocol (mcp) is routinely confused with

Function calling / tool use
Function calling is a model API feature: the model emits a structured request to invoke a named function, and your code executes it. MCP is the layer beneath — how your code discovers which functions exist, on which server, with which schema, and how it reaches them over a transport. A model does function calling perfectly well with no MCP anywhere, and MCP changes nothing about the model API.
A2A
MCP connects a model to capabilities it uses as tools; A2A connects agents to each other as peers. The practical test is whether the far side has goals of its own: an MCP server executes what it is told, while an A2A agent accepts a task, decides how to do it, and keeps its method opaque.
OpenAPI or a plugin manifest
OpenAPI describes an HTTP API statically for a programmer to read and generate against. MCP describes a live session: the server can push a tools/list_changed notification, call back to the client for a model completion, and ask the user a question mid-task. A generated OpenAPI client cannot do any of those, and a static description cannot rug-pull the way a live catalogue can.
next

Related terms

Protocols and standards

The terms next to this one

The substrate everything here conforms to, and the four regulatory instruments that decide what evidence an operator has to be able to produce.

get in touch

Definitions are the easy part.

The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.

no form · no qualification step · no sales desk · the other three ways in