MCP Goes Stateless: The 2026-07-28 Spec Milestone

On July 28, 2026, the Model Context Protocol project officially released the next spec version, 2026-07-28, along with updated TypeScript, Python, Go, and C# SDKs. The headline change is a stateless protocol core: MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol.

Why Statelessness Matters

Over the past year, MCP has grown at an astonishing rate: nearly half a billion downloads a month across Tier 1 SDKs, with both TypeScript and Python SDKs crossing the 1 billion total download threshold. MCP has become the data and interactivity substrate for agentic workflows. But the stateful core — depending on persistent bidirectional streams and session IDs — limited server reliability and scalability.

Statelessness was one of the most highly requested features from developers. It lets MCP servers deploy on standard, scalable infrastructure without managing sessions or persistent connections. Each request is self-describing and can land on any instance behind a round-robin load balancer, with no shared storage. As MCP co-inventor David Soria Parra put it, this is the protocol's most important release since remote MCP launched, drawing on 18 months of lessons to provide a robust foundation for MCP's future.

How the Stateless Protocol Works

The new spec formally retires the initialize/initialized handshake and the Mcp-Session-Id header. Each request now travels on its own, carrying its protocol version, client identity, and client capabilities in _meta. If a client wants to learn a server's capabilities before anything else, there is a new server/discover RPC — but it is not required. Any request can now land on any server instance behind a plain round-robin load balancer.

Dropping the protocol-level session does not force your application to be stateless. If your server needs to carry state across calls, mint an explicit handle from a tool and have the model pass it back as an argument. The team found this works better than session state hidden in the transport — the model can see the handle and thread it between tools.

Making Interactions Possible on a Stateless Protocol

The hardest challenge of statelessness is handling interactions that need input mid-call, such as a confirmation or a missing parameter. The new version solves this with MRTR (Multi Round-Trip Requests): the server returns a resultType of 'input_required' along with the requests it needs answered, and the client retries the original call with the answers attached in inputResponses. This replaces the server-initiated requests (elicitation/create, sampling/createMessage, roots/list) that previously required a held-open stream.

This matters for enterprises. Supabase's MCP, for example, runs statelessly and previously could not easily implement confirming the cost of a new project before creating it, or confirming a query that would delete data. MRTR makes these possible — confirmation and destructive-action protection no longer require a persistent bidirectional connection.

Architecture Upgrades for Gateways and Scale

The new version introduces header-based routing: Streamable HTTP requests must now include Mcp-Method and Mcp-Name headers. Your gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies. This significantly lowers the barrier to bringing agent traffic into enterprise security infrastructure.

List results are now cacheable: responses from tools/list, prompts/list, resources/list, and resources/read carry ttlMs and cacheScope, letting clients determine the best caching strategy and reduce unnecessary re-fetching while keeping upstream prompt caches stable across reconnects. For large-scale deployments, this can meaningfully cut traffic and cost.

Authorization Hardening and the Extensions Framework

Authorization is where implementers spend most of their integration time. The new spec continues to evolve MCP's auth and security posture: authorization servers should return the iss parameter per RFC 9207 and clients must validate it, closing an authorization-server mix-up hole; client credentials are bound to the issuer that minted them, with no reuse across authorization servers; and Dynamic Client Registration (DCR) is formally deprecated in favor of Client ID Metadata Documents (CIMD).

The extensions framework is now formal. Tasks moves out of the experimental core and into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update. Alongside extensions like MCP Apps and Enterprise Managed Authorization (EMA), MCP now has a proper mechanism for capabilities to evolve on demand without blocking the protocol core.

Roots, Sampling, and Logging Deprecated

The new version formally deprecates Roots, Sampling, and Logging (SEP-2577). They still work and will keep working for at least twelve months, but new implementations should not adopt them. The legacy HTTP+SSE transport is also officially deprecated, with a year-long off-ramp. A formal deprecation policy guarantees a minimum twelve-month window, so enterprises can plan upgrades instead of reacting to them.

For enterprises, the practical takeaway is clear: if you are building agent infrastructure, you can adopt the 2026-07-28 SDKs today and deploy MCP servers as ordinary, scalable web services. This is not just a technical evolution — it is an important step toward bringing MCP into enterprise-grade operations and security.

References: Model Context Protocol blog, "The 2026-07-28 Specification", 2026-07-28, https://blog.modelcontextprotocol.io/posts/2026-07-28