The Model Context Protocol, explained from the specification

TL;DR

• The Model Context Protocol (MCP) is an open, JSON-RPC 2.0 protocol that connects AI applications (hosts) to tool and data servers through one client per server. Anthropic open-sourced it on 25 November 2024; the Linux Foundation’s Agentic AI Foundation has governed it since December 2025.
• The current revision, 2026-07-28, makes MCP stateless: no initialize handshake, no protocol sessions, version and capabilities on every request, and a mandatory server/discover method.
• Servers expose three primitives (tools, resources, prompts). Of the client features, elicitation stays; sampling and roots are deprecated, eligible for removal no earlier than revisions released from 28 July 2027.
• Remote servers use OAuth 2.1 with Protected Resource Metadata (RFC 9728) and Resource Indicators (RFC 8707). Token passthrough is forbidden, and tool annotations are untrusted unless the server is.
• In production, teams put an MCP gateway such as Bifrost, an open-source AI gateway, between hosts and servers to centralize credentials, per-caller tool allow-lists and authentication.

The Model Context Protocol (MCP) is an open standard that lets an AI application discover and call external tools, read data and use prompt templates through one common interface instead of a custom integration per system. Its specification defines the messages, transports, authorization flow and security rules that every MCP client and server follow. The current revision, dated 2026-07-28, is the largest change since launch: it turned MCP into a stateless protocol and deprecated three features. This guide works through the specification section by section, then covers the registry, SDKs, adoption, governance and how teams run MCP in production.

What the Model Context Protocol is

The Model Context Protocol is an open protocol for connecting LLM applications to external data sources and tools. It uses JSON-RPC 2.0 messages between hosts, clients and servers, and lets servers offer tools, resources and prompts that any compatible application can use without bespoke integration code.

The specification’s own overview describes MCP as a standardized way for applications to share context with language models, expose tools and capabilities to AI systems, and build composable integrations. The authors say MCP takes inspiration from Microsoft’s Language Server Protocol, which did the same job for programming-language support in editors: one protocol on each side, so N editors and M languages need N plus M implementations rather than N times M.

The normative source is a TypeScript schema; the prose specification defines requirements using the RFC 2119 keywords (MUST, SHOULD, MAY). The key details list three server features (resources, prompts, tools), one client feature in the current list (elicitation), and utilities for configuration, progress, cancellation and error reporting. Optional extensions such as Tasks and MCP Apps sit outside the core and must be supported by both sides.

MCP history, from launch to revision 2026-07-28

MCP launched as an Anthropic open-source project on 25 November 2024 and has shipped five dated revisions. Each revision’s date marks the last backwards-incompatible change, so a single version string identifies what both sides must implement.

Anthropic’s launch post introduced the specification and SDKs, local MCP server support in the Claude Desktop apps, and an open-source repository of reference servers for systems such as Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. The versioning page defines the date scheme and the Draft, Current and Final states.

The 2026-07-28 revision also adopted a formal feature lifecycle with Active, Deprecated and Removed states and a minimum twelve-month deprecation window. That policy is why sampling and roots still work today, though new implementations are told not to adopt them.

MCP architecture: hosts, clients and servers

MCP follows a client-host-server architecture. The host is the AI application, it creates one MCP client per server, and each client holds a one-to-one connection with exactly one server. The host keeps the conversation and enforces consent; servers see only what their own client sends them.

The architecture section assigns each role specific duties:

• Host: creates and manages clients, enforces security policies and consent, handles user authorization decisions, coordinates the model, and aggregates context across clients. Claude Desktop, an IDE or an agent framework can be the host.
• Clients: each talks to exactly one server, attaches the protocol version and capabilities to every request, and maintains security boundaries between servers.
• Servers: expose resources, tools and prompts; run as local processes or remote services; and request client input only inside a reply.

Figure 1: The host owns the conversation and consent; each server sees only the requests its own client sends it.

Four design principles explain the shape. Servers should be very easy to build, because hosts do the orchestration. Servers should be composable. Servers should not be able to read the whole conversation or “see into” other servers. And features should be added progressively through capability negotiation. The third principle is the security model in one line: isolation between servers is the host’s job, which is why a malicious server is dangerous mainly through what the host lets the model do with its output.

The JSON-RPC base protocol

Every MCP message is a JSON-RPC 2.0 request, result, error or notification, encoded in UTF-8. MCP tightens JSON-RPC in a few places: request IDs must not be null, every result carries a resultType, and a reserved error-code range now belongs to the specification.

The messages section sets the rules on top of the JSON-RPC 2.0 specification:

• Requests carry a string or integer ID that must not be null and must not repeat an ID still awaiting a response.
• Result responses must include resultType: "complete" for a final answer or "input_required" when the server needs more information. Clients treat a missing resultType from older servers as complete.
• Error responses carry an integer code and a message.
• Notifications are one-way and carry no ID.

The error-code policy splits the JSON-RPC server-error range. Codes from -32000 to -32019 are legacy and implementation-defined; -32020 to -32099 are reserved for the specification, which currently defines HeaderMismatch (-32020), MissingRequiredClientCapability (-32021) and UnsupportedProtocolVersion (-32022). JSON-RPC batching, added in 2025-03-26, was removed again in 2025-06-18.

Lifecycle and capability negotiation

Until 2025-11-25, an MCP connection began with an initialize handshake that fixed the version and capabilities for the session. Revision 2026-07-28 removed it: every request now carries its protocol version and client capabilities in _meta, and servers must answer a server/discover call.

Under the 2025-11-25 lifecycle, the client sent initialize, the server answered with its capabilities, the client confirmed with notifications/initialized, and the rest of the connection inherited those terms. That made every connection a session, which complicated load balancing: a remote server behind several replicas needed sticky routing or shared session storage.

The current revision defines MCP as a stateless protocol. Servers must not rely on earlier requests on the same connection for capabilities, version or client identity, and state that spans requests must travel as an explicit identifier the client passes each time. The changelog lists the concrete removals: the handshake, the Mcp-Session-Id header, ping, logging/setLevel and SSE stream resumability.

Capability negotiation now happens per request. Clients put their capabilities in _meta.io.modelcontextprotocol/clientCapabilities, and servers advertise theirs in response to server/discover, which clients may call first to pick a version. If a server does not support the requested version it returns UnsupportedProtocolVersionError listing the versions it does support, and the client retries (version negotiation).

Figure 2: No handshake and no session: every request carries its own version and capabilities, and a server that needs input asks for it in its reply.

The other half of the change is multi round-trip requests (MRTR). Servers can no longer send their own JSON-RPC requests to the client. When a tool needs user input, a model completion or a list of roots, the server returns an InputRequiredResult; the client gathers the input and retries the original request, with a new request ID, carrying inputResponses. Because each retry is self-contained, any replica can answer it.

Old and new implementations coexist through a compatibility matrix. A modern client talking to a legacy server fails unless it is “dual-era” and falls back to initialize; a legacy client can only reach a modern server that also implements the old handshake. Anyone operating a mixed fleet of clients and servers in late 2026 has to plan for that matrix.

MCP transports: stdio and Streamable HTTP

MCP defines two standard transports. Stdio runs the server as a subprocess of the client and exchanges newline-delimited JSON-RPC over standard input and output. Streamable HTTP sends each message as an HTTP POST to one endpoint. The original HTTP+SSE transport is formally deprecated.

The transports overview treats a transport as a binding: it decides framing, delivery, metadata and cancellation, never what messages mean. Custom transports are allowed if they preserve the JSON-RPC format and message patterns.

Stdio is for local servers. The server reads from stdin, writes only valid MCP messages to stdout, may log to stderr, and must not write requests to stdout. Authorization does not apply to stdio; the base protocol says stdio implementations should take credentials from the environment instead.

Streamable HTTP is for remote servers. The client POSTs every message to a single MCP endpoint, and the server replies with either one JSON object or an SSE stream scoped to that request. The current revision removed the GET stream; long-lived change notifications now arrive on the response stream of a subscriptions/listen request. Three rules matter for operators:

• Origin validation: servers must validate the Origin header to block DNS rebinding and should bind to 127.0.0.1 when running locally.
• Request metadata headers: every POST carries MCP-Protocol-Version, Mcp-Method, and for tool, resource and prompt calls Mcp-Name, so load balancers and gateways can route without parsing the body. A mismatch with the body returns HeaderMismatch.
• No resumability: a broken stream loses the in-flight request, and the client re-issues it.

The HTTP+SSE transport from 2024-11-05, deprecated in spirit since 2025-03-26, is now formally Deprecated with Streamable HTTP as the migration path. Platforms have moved accordingly: Google’s Gemini documentation states that remote MCP only works with Streamable HTTP servers.

Server primitives: tools, resources and prompts

MCP servers expose three primitives that differ by who controls them. Tools are model-controlled functions that the model can invoke. Resources are application-driven data identified by URIs. Prompts are user-controlled templates, typically surfaced as slash commands.

Tools are designed to be model-controlled, but the specification says there should always be a human in the loop able to deny an invocation. A tool definition has a name, optional title, description, inputSchema (JSON Schema 2020-12 by default), optional outputSchema and optional annotations. Results can return structured content alongside text, images, audio and resource links. Because the protocol has no sessions, stateful tools return an explicit handle, such as a basket ID, that later calls pass back as an argument.

Resources let the host decide what context to include, through pickers, search or automatic heuristics. Clients can follow changes through subscriptions/listen rather than the removed resources/subscribe.

Prompts are user-controlled: the user decides when to use one, even though the server authors its content.

Two newer requirements matter for cost and caching. Servers should return tools from tools/list in a deterministic order to improve client caching and LLM prompt-cache hit rates, and list and read results now carry ttlMs and cacheScope hints (minor changes). Large tool catalogs are still expensive in tokens; the coding-agent server comparison measures what tool definitions cost a context budget.

Client features: sampling, roots and elicitation

Clients can offer three features to servers. Elicitation lets a server ask the user for input, in a form or through a URL. Sampling let a server request a model completion through the client, and roots told a server which directories mattered. Sampling and roots are deprecated as of 2026-07-28.

Elicitation has two modes. Form mode requests structured data validated against a JSON schema. URL mode sends the user to an external page for interactions that must not pass through the client. Servers must not use form mode for passwords, API keys, access tokens or payment credentials, and must use URL mode for them; clients must show which server is asking and, for URLs, display the target domain and get consent first. Under MRTR, an elicitation arrives inside an input_required result.

Sampling let servers borrow the host’s model, with no server-side API key, and gained tool calling in 2025-11-25. Roots were informational: the specification notes they were never an access-control mechanism and that the protocol does not enforce them.

The deprecated features registry gives the migrations. Instead of sampling, integrate directly with LLM provider APIs. Instead of roots, pass directories or files as tool parameters, resource URIs or server configuration. Instead of the logging utility, write to stderr on stdio or use OpenTelemetry. All three become eligible for removal in the first revision released on or after 28 July 2027.

MCP authorization with OAuth 2.1

MCP authorization is optional and applies to HTTP transports. A protected MCP server is an OAuth 2.1 resource server. It must publish Protected Resource Metadata (RFC 9728) naming its authorization server, and clients must use PKCE and send a resource indicator (RFC 8707) so each token is bound to one server.

The standards list draws on the OAuth 2.1 draft, bearer tokens (RFC 6750), authorization server metadata (RFC 8414), RFC 9728, RFC 8707, issuer identification (RFC 9207), Client ID Metadata Documents and OpenID Connect Discovery. The roles are standard OAuth: the MCP server is the resource server, the MCP client is the OAuth client, and the authorization server may be co-hosted or separate.

Figure 3: The resource parameter binds each token to one MCP server, which must reject tokens issued for anyone else.

The flow, as Figure 3 shows, starts with a 401 whose WWW-Authenticate header points to the server’s resource metadata. The client reads it, discovers the authorization server through RFC 8414 or OpenID Connect metadata, and obtains a client ID. The registration order now prefers Client ID Metadata Documents, where the client ID is an HTTPS URL the authorization server fetches; Dynamic Client Registration is deprecated and kept for compatibility.

Several requirements are worth checking in any implementation:

• Resource parameter: clients must include resource, set to the server’s canonical URI, in both authorization and token requests.
• PKCE: clients must use S256 where possible and must refuse to proceed if the metadata does not advertise code_challenge_methods_supported.
• Issuer validation: clients must compare a returned iss with the recorded issuer before redeeming the code, which blocks mix-up attacks.
• Scopes: servers should name required scopes in the 401 challenge, and clients request more later through step-up authorization rather than asking for everything at once.
• Token handling: tokens go in the Authorization header on every request, never in the query string, and servers must validate that each token was issued for them.

Machine-to-machine and enterprise identity-provider flows live in authorization extensions, including OAuth client credentials and enterprise-managed authorization.

MCP security best practices

The specification’s security guidance names concrete attacks: confused deputy through OAuth proxies, token passthrough, server-side request forgery, state handle hijacking and local server compromise. Tool poisoning is handled by a simpler rule: clients must treat tool annotations as untrusted unless the server is trusted.

The trust and safety principles set the frame: users must consent to data access and operations, hosts must get consent before exposing user data or invoking any tool, and tools represent arbitrary code execution. The specification admits it cannot enforce these at the protocol level; implementations have to.

Token passthrough deserves emphasis because it is the easiest mistake for a proxy. The best-practices page lists what it breaks: rate limits and monitoring that depend on token audience, the server’s ability to tell clients apart, and downstream logs that show the wrong caller. The audience-binding rule and the confused deputy section of the authorization specification restate it as a MUST.

Tool poisoning is the prompt-injection problem in MCP form: the model reads a full tool description or tool result that the user never sees. The OWASP MCP Top 10 lists it as MCP03. The tools security considerations put duties on both sides: servers must validate inputs, enforce access control, rate-limit and sanitize outputs; clients should confirm sensitive operations, show inputs before calling, validate results before passing them to the model, and log tool use.

The Frontier Wire’s MCP security tools survey maps scanners and gateways to each of these risks, and its prompt injection explainer covers the underlying attack. Further reading includes a breakdown of MCP security risks and how to mitigate them.

The MCP registry and official SDKs

The official MCP Registry, in preview, is a metadata catalog for publicly accessible MCP servers, with namespaces verified through GitHub or DNS. Ten official SDKs, in TypeScript, Python, C#, Go, Rust, Ruby, Java, Swift, PHP and Kotlin, are ranked in three tiers by completeness and maintenance.

The registry stores a server.json per server: a reverse-DNS name such as io.github.user/server-name, where to get it (an npm package or a remote URL), how to run it, and discovery data. It points to packages rather than hosting them, and it is built for downstream aggregators and marketplaces that pull metadata periodically. It does not take private servers; organizations are told to run their own registry implementing the same OpenAPI interface.

Its trust model is namespace authentication. Security scanning is delegated to the package registries and to aggregators, so a registry listing proves who published a server, not that the server is safe. For curated lists, The Frontier Wire compares the most widely used MCP servers on auth, transports and security record.

The SDK table places TypeScript, Python, C#, Go, Rust and Ruby in Tier 1, Java in Tier 2, and Swift, PHP and Kotlin in Tier 3. All of them build servers and clients, support local and remote transports, and type-check protocol messages. Since revision 2026-07-28 breaks the session model, SDK version matters: a deployment should confirm which protocol revisions each SDK release speaks before relying on stateless behavior.

MCP adoption at OpenAI, Google and Microsoft

MCP has been adopted well beyond Anthropic. OpenAI’s Responses API calls remote MCP servers, Google’s Gemini API and Agent Development Kit connect to them, and Microsoft supports MCP in Copilot Studio and Visual Studio Code. The Linux Foundation counted more than 10,000 published servers in December 2025.

The Linux Foundation’s announcement says MCP has been adopted by Claude, Cursor, Microsoft Copilot, Gemini, VS Code, ChatGPT and other platforms, and reports more than 10,000 published servers; both are the foundation’s figures. One pattern repeats across vendors: the developer, not the model, decides whether a call needs approval. OpenAI’s require_approval setting and the Agents SDK’s tool filtering are client-side versions of the controls a gateway applies centrally.

MCP connects an agent to its tools. Agent-to-agent communication is a separate protocol, A2A; the A2A vs MCP comparison explains how they divide the work.

Governance and the Agentic AI Foundation

MCP is no longer an Anthropic project. On 9 December 2025 the Linux Foundation formed the Agentic AI Foundation with MCP, Block’s goose and OpenAI’s AGENTS.md as founding projects. The specification is maintained under a formal governance model with lead and core maintainers chosen as individuals.

The Linux Foundation announcement names Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI as platinum members. The protocol’s governance page states that it is established as Model Context Protocol a Series of LF Projects, LLC, with code and specifications under the Apache License 2.0 and documentation under CC BY 4.0.

Technical governance runs through lead maintainers, core maintainers, maintainers and contributors, together forming the MCP Steering Group. Membership is for individuals, not companies, and no seats are reserved for employers. Specification changes move through Specification Enhancement Proposals; the 2026-07-28 changelog cites SEP numbers for every major change, which makes the reasoning behind each decision traceable on GitHub.

Running MCP in production through a gateway

Once more than a handful of servers and users are involved, teams put an MCP gateway between hosts and servers. The gateway is an MCP server to every host and an MCP client to every upstream server, so authentication, per-caller tool allow-lists, credentials and logs sit in one place instead of in each laptop’s configuration.

The specification motivates the pattern without naming it. It requires audience-bound tokens, forbids passthrough, asks clients to log tool use and asks servers to rate-limit, and the Streamable HTTP headers exist so that intermediaries can route and inspect requests. A gateway is the intermediary that turns those duties into configuration. The Frontier Wire’s MCP gateway comparison measures ten products against those specification rules; a guide to what an MCP gateway does for production agents covers the category.

Bifrost is the worked example here because its documentation describes each control and the project is open source and self-hostable. Bifrost is an open-source AI gateway written in Go, released by Maxim AI under Apache 2.0, that routes model calls to 25+ providers and 10,000+ models through one OpenAI-compatible API. Its published benchmark reports 11 µs of overhead at 5,000 RPS on an AWS t3.xlarge.

Figure 4: Hosts see one endpoint; credentials and tool allow-lists for every upstream server are configured in one place.

The Bifrost MCP documentation describes the gateway as an MCP client to upstream servers over STDIO, HTTP or SSE and an MCP server that exposes the aggregated tools on /mcp to clients such as Claude Desktop and Cursor. Mapped to the specification:

• Inbound authorization. In oauth or both gateway auth modes, Bifrost acts as an OAuth 2.1 authorization server for /mcp, returning a 401 with a resource metadata URL and serving the .well-known discovery endpoints; the default headers mode accepts virtual keys instead.
• No passthrough to upstreams. Six outbound auth types (none, static headers, admin OAuth, per-user headers, per-user OAuth and token exchange) give each upstream server its own credential, with token exchange swapping the caller’s identity-provider token rather than forwarding it.
• Deny-by-default tool access. MCP tool filtering gives each virtual key an allow-list; a key with no MCP configuration gets no tools, and the list is enforced again at execution time.
• Curated endpoints. Virtual MCPs bundle selected tools from several servers behind one /mcp/<slug> URL reachable only through attached keys.
• Human approval. By default, tool calls are not auto-executed; in gateway mode, approval stays with the host’s own client settings.
• Token cost. Code mode replaces a large tool catalog with four generic tools and has the model write Python that runs in a sandbox; the docs report up to 92.8% fewer input tokens. A separate explainer covers how code mode works.

The Bifrost team’s essay on MCP as protocol, plumbing and gateway sets out the reasoning for routing tool traffic through one control point, and the MCP gateway resource page summarizes the feature set. Enterprise tier. Token exchange, prompt guardrails on MCP inputs and outputs, and audit logs are part of Bifrost Enterprise.

A gateway does not replace the host’s duties. Consent dialogs, showing tool inputs, and validating results before the model sees them remain client work under the specification. Coding agents on employee machines add their own exposure, covered in the Frontier Wire’s look at Claude Code security.

Building on MCP after the stateless revision

The 2026-07-28 revision changes what “MCP-compatible” means. Statelessness makes remote servers simpler to scale, but it breaks the handshake every pre-2026 client and server was built around, and it retires sampling and roots that some servers relied on.

For a team adopting the Model Context Protocol now, the specification points to a short checklist. Build on Streamable HTTP or stdio and nothing else. Confirm which revisions each SDK release supports, and decide whether clients must be dual-era. Replace sampling with direct provider calls and roots with explicit parameters before the 2027 removal window. Implement the full authorization profile for remote servers, including resource indicators, PKCE and issuer checks, and never forward a token a server was not issued. Treat every tool description and result as untrusted input. Then put a gateway in front of the fleet once more than one team shares servers, so allow-lists and credentials live in one place.

What would change this picture is the next revision. The authorization specification already expects to upgrade authorization servers’ inclusion of the iss parameter from SHOULD to MUST, the Tasks and MCP Apps extensions are maturing outside the core, and the registry is still in preview. The protocol has shipped five revisions in under two years; anyone building on MCP should read each changelog as it lands rather than assume last year’s integration still conforms.