MCP Goes Stateless in Its Biggest Spec Change Yet

How often does a protocol revision delete the concept of a session? The Model Context Protocol specification released on July 28, 2026 does exactly that, and it is the largest change to MCP since it launched.

The short version: MCP moves "from a bidirectional stateful protocol into a request/response stateless protocol." Every request now carries what it needs, so it can be routed to any server instance without a held-open connection behind it.

What actually changed

The specification touches most layers of the protocol at once:

• Sessions are gone. The initialize and initialized exchange and the Mcp-Session-Id header have been removed. Protocol version, client identity and capabilities now travel in _meta on each request, with an optional server/discover call replacing mandatory capability negotiation.
• Multi Round-Trip Requests. Servers that need a mid-call confirmation or a missing parameter return resultType: "input_required" instead of relying on server-initiated requests over a persistent stream.
• Header-based routing. The new Mcp-Method and Mcp-Name headers let gateways route and meter requests without parsing JSON bodies.
• Cacheable list results. tools/list, prompts/list, resources/list and resources/read now return ttlMs and cacheScope.
• Hardened authorization. RFC 9207 issuer validation is required, and Dynamic Client Registration gives way to Client ID Metadata Documents, with client credentials bound to the issuing authorization server.
• A formal extensions framework. Tasks moved out of the experimental core into an io.modelcontextprotocol/tasks extension.

SDKs for TypeScript, Python, Go, C# and Rust in beta have been updated alongside the release.

Why stateless matters for cost

A stateful protocol needs somewhere for the state to live. In practice that has meant long-running processes, sticky routing, and infrastructure that stays warm whether or not anyone is calling it. That is the main reason MCP servers have mostly been deployed as always-on services.

Removing sessions removes that requirement. An MCP server can now run on serverless or edge infrastructure and scale to zero between calls. For a team running a handful of internal integrations, the difference between an always-on container and a function that bills per invocation is not a rounding error.

Header-based routing points at the same operational problem from the gateway side. Being able to route, rate limit and meter on headers rather than by inspecting payloads is what makes MCP traffic manageable at organizational scale.

The breaking part

Four of these changes are backward-incompatible: the removal of sessions, Multi Round-Trip Requests, header routing, and the authorization changes. Roots, sampling, logging and the legacy HTTP+SSE transport are deprecated with a stated minimum window of twelve months.

Twelve months sounds generous until you consider how many MCP servers were written quickly as internal tools, with no owner and no migration budget. Those are the ones that quietly stop working.

If you run an MCP server today

Nothing breaks this week, and the deprecation window is real. What is worth doing now is inventory rather than migration:

• List what you actually run. MCP servers tend to accumulate as side projects. Find them, and note which ones have an owner.
• Check for the deprecated pieces. If a server uses sampling, roots, logging or the HTTP+SSE transport, it has a defined shelf life and should be scheduled rather than discovered later.
• Look at your authorization path. Anything relying on Dynamic Client Registration will need to move to Client ID Metadata Documents, and that touches your identity provider, not just your server code.

The direction here is clear enough. MCP started as a way to connect one assistant to one developer's tools, and this revision is what a protocol looks like when it is being prepared to run behind a corporate gateway with metering, auditing and identity attached.

Sources: Model Context Protocol, VentureBeat