How the Model Context Protocol Works (2026-07-28 Revision)

Hosts, clients and servers

MCP describes three roles. A host is the LLM application a person uses, such as a chat app or an AI coding tool. Inside it, each client is a connector that talks to one server, a service that provides context and capabilities. All three exchange JSON-RPC 2.0 messages.² The specification says it takes inspiration from the Language Server Protocol, which standardized how code editors add support for programming languages: MCP aims to do the same for connecting tools and data to AI applications.²

The split matters for trust: the specification states that hosts must obtain explicit user consent before exposing user data to servers, and must not transmit resource data elsewhere without it.²

Tools, resources and prompts

Servers offer any of three features. Tools are functions for the AI model to execute; resources are context and data for the user or the model to use; prompts are templated messages and workflows for users.² A tool is described by a name and a JSON Schema for its inputs, and optionally its outputs; revision 2026-07-28 allows any JSON Schema 2020-12 keyword in those schemas.³⁷

Clients can offer features back to servers. In 2026-07-28 the one listed is elicitation, a server's request for more information from the user, first added in revision 2025-06-18.²¹⁰ Sampling, listed since revision 2024-11-05 as "server-initiated agentic behaviors and recursive LLM interactions", and Roots, which points a server at directories or files, were both deprecated in 2026-07-28, along with Logging.³⁸ Deprecated features keep working for at least twelve months (ninety days under an expedited exception), and the changelog suggests replacements: passing directories or files as tool parameters instead of Roots, and calling LLM provider APIs directly instead of Sampling.¹³

Two transports: stdio and Streamable HTTP

A transport only defines how messages are framed and delivered; the meaning of the messages is the same on every one. The specification defines two standard bindings. With stdio, the client launches the server as a subprocess and they exchange newline-delimited messages over its standard input and output. With Streamable HTTP, each message is an HTTP POST to a single MCP endpoint, and the reply arrives either as a JSON object or as a server-sent events (SSE) stream scoped to that request.⁴ Custom transports are allowed.⁴

Streamable HTTP arrived in revision 2025-03-26, replacing the earlier HTTP+SSE transport.⁹ The old transport has been deprecated since then, and 2026-07-28 formally reclassified it as Deprecated under the new feature lifecycle policy.³

What changed in 2026-07-28: no handshake, no sessions

Revisions up to 2025-11-25 were handshake-based: a client opened a connection with initialize and a notifications/initialized reply, and the base protocol was listed as "stateful connections".¹⁸ Revision 2026-07-28 removes that handshake. Every request now carries its protocol version and the client's capabilities in its _meta field, and the server accepts or rejects each request on its own; on Streamable HTTP the version also travels in the MCP-Protocol-Version header.¹³

Servers must now implement server/discover, an RPC that returns their supported protocol versions, capabilities and identity in one request. Calling it is optional for clients, which may instead send a request directly and handle an UnsupportedProtocolVersionError.¹ The revision also drops protocol-level sessions and the Mcp-Session-Id header (servers that need state pass their own handles as tool arguments), replaces subscriptions with a single subscriptions/listen stream, removes ping, moves long-running tasks into an official extension, and introduces Multi Round-Trip Requests: instead of sending its own requests to the client, a server returns an input_required result and the client retries with the answers.³

The version string itself is a date. MCP only changes it when a backwards-incompatible change is made, so a revision can keep receiving compatible updates while it is current.¹

Authorization: OAuth for remote servers

Authorization is optional in MCP and applies to HTTP-based transports; implementations using stdio should not follow it and should instead retrieve credentials from the environment.⁵ When it is used, a protected MCP server acts as an OAuth 2.1 resource server and an MCP client acts as an OAuth 2.1 client. Servers must publish OAuth 2.0 Protected Resource Metadata (RFC 9728), which clients use to find the right authorization server, and clients must send Resource Indicators (RFC 8707) naming the server they intend to reach, so a token issued for one server cannot be replayed at another.⁵¹⁰

Revision 2026-07-28 tightened this further: clients must check the iss value in authorization responses (RFC 9207), must bind stored credentials to the authorization server that issued them, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents.³

The security risks the spec names

The specification is direct about the risk: tools represent arbitrary code execution and must be treated with caution, hosts must get explicit user consent before invoking any tool, and descriptions of tool behavior, such as annotations, are to be treated as untrusted unless they come from a trusted server.²⁷ That is the opening for what researchers call prompt injection or tool poisoning: text a server supplies, in a description or a result, that tries to steer the model into actions the user never asked for. The tools page says there should always be a human in the loop with the ability to deny tool invocations, with clear indicators when a tool runs and confirmation prompts for operations.⁷

A separate Security Best Practices page lists the attacks implementers must design against, among them the confused deputy problem, token passthrough (an anti-pattern the authorization rules forbid), server-side request forgery, compromise of local MCP servers, mix-up attacks and over-broad scopes.⁶ MCP itself cannot enforce these principles at the protocol level; the specification leaves consent flows and access controls to implementers.²

Governance, and MCP vs A2A

Anthropic donated MCP to the Agentic AI Foundation on Dec 9, 2025. The AAIF is a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI; MCP joined Block's goose and OpenAI's AGENTS.md as its founding projects, and Anthropic said MCP's governance model would stay unchanged.¹²¹³ At the time, Anthropic stated there were more than 10,000 active public MCP servers and 97M+ monthly SDK downloads across Python and TypeScript.¹² Those were vendor-stated figures; the table above gives today's counts from the registries themselves.

A2A, the Agent2Agent Protocol, was originally developed by Google and is now hosted by the Linux Foundation.¹⁹ Its first stable specification, 1.0.0, came out on Mar 12, 2026.¹⁸ Both projects describe the two as complementary: MCP covers how an agent connects to tools, APIs and data, while A2A covers how independent agents discover each other, negotiate and delegate work as peers, with each agent publishing an Agent Card that describes its skills and endpoints.¹⁷²⁰ On the Linux Foundation's April 2026 count, more than 150 organizations support A2A, and Microsoft and AWS have built it into Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime.²⁰ By package downloads over the last month, MCP's SDKs are installed far more often: on npm, about 18 times as often as A2A's JavaScript SDK (266.7 million vs 14.8 million; our ratio of the two npm figures for the same 30-day window).¹⁵²¹