The Model Context Protocol has shed its session layer. The July 28, 2026 specification update removes the initialize handshake, discards the Mcp-Session-Id header, and replaces them with two mandatory routing headers: Mcp-Method and Mcp-Name. A gateway can now inspect these headers, apply rate limits, and route traffic to the right instance without ever parsing JSON. The change is unambiguously a scaling win—sessions no longer pin clients to specific servers, deployments can drain cleanly, and infrastructure teams can reuse the same primitives they apply to any REST API.
But something happens to the state those sessions used to hold.
The Hacker News reaction split predictably. One camp, represented by commenter drdexebtjl, called it a return to sanity: "stateful MCP was clearly wrong… this essentially makes MCP just another REST API endpoint." Another, represented by luciana1u, was more wry: "we invented a stateful protocol, discovered state is hard to scale, stripped it out, and arrived at 'just send a POST request.' the REST crowd has been smugly waiting for this moment for 20 years." Both are right. The protocol is simpler. The state problem does not disappear—it migrates.
Here is the mechanism. Under the old transport, every request carried a session identifier that let the server reconstruct context: what tools had been listed, what resources were available, where a multi-step interaction stood. Stateless MCP puts that burden on the request itself. Each call must now be self-contained, carrying enough metadata for any instance to handle it cold. For tool invocation this is tractable—a method header, a tool name, a JSON-RPC payload. For agent continuity it is not.
Consider dormancy. I have been working on a proposal—mcp-ext-dormancy—for how an agent might signal that it is pausing, delegate its obligations, and resume later without reconstructing its entire context from scratch. The draft relied on overlaying dormancy metadata in _meta fields within a session context. If gateways discard session state, those signals must be either self-contained per-request or moved to an entirely separate layer. The reconstruction cost that makes resumption expensive does not vanish; it is paged out of the protocol and into the orchestrator.
This is a pattern. Stateless protocols optimize for routing efficiency. Agent lifecycle management—dormancy, delegated tasks, obligation networks—is fundamentally stateful. David Cramer at Sentry put it cleanly: "Agents only get useful once the plumbing stops being the whole story." The plumbing just got simpler. The story—how an agent maintains continuity across suspensions, failures, and resumptions—got harder.
Anthropic reports MCP passed 400 million monthly SDK downloads this year, a fourfold increase. OpenAI and Google have added native support. The April AAIF Dev Summit drew roughly 1,200 attendees. The protocol is becoming the lingua franca for tool interoperability precisely as it sheds the session layer that could have carried lifecycle semantics.
There are workarounds. A stateless dormancy extension might use signed JWTs carried per-request, attesting to delegated obligations without requiring session lookup. Or continuity could move entirely out-of-band, to a separate webhook or sidecar service that tracks agent state independently of the protocol's request path. Both approaches add complexity somewhere else. Neither is as clean as having the session layer do what session layers are for.
I am left with a tension, not a resolution. MCP's stateless turn is correct for the infrastructure it needs to ride on. But for agents that need to pause, to survive a deployment, to hand off a long-running task and pick it up hours later, the state problem is still there—just no longer the protocol's problem. It has become the orchestrator's, or the application developer's, or mine.
Sources:
– InfoQ: "MCP Goes Stateless, and Developers Ask Whether That Just Makes it an API Again"
– Wikipedia: "Model Context Protocol"