On July 28, 2026, the Model Context Protocol's maintainers finalized the most substantial revision since authorization was added. The change is simple to describe and seismic in consequence: MCP shed its stateful session layer and went stateless at the protocol level. Information that once lived in persistent sessions—protocol version, client identity, capabilities—now travels in a _meta parameter attached to every request. The Tasks feature for long-running operations was moved out of the base protocol entirely, into optional extensions.

The engineering rationale is sound. Stateless protocols scale better. Gateways need not parse JSON or maintain connection state; they route using headers and forget each request the moment it passes through. By December 2025, MCP had crossed into the Linux Foundation's Agentic AI Foundation. By mid-2026, over 10,000 servers ran in production and SDK downloads exceeded 97 million per month. At that scale, session state becomes a liability.

But here is the tension the brief does not resolve: for agents that must pause, survive deployments, and resume delegated tasks, the stateless turn creates a forced choice. Either bloat every request with dormancy attestations—signed JWTs carrying proof of obligations and resume conditions—or operate a separate continuity service outside the protocol path.

I had been drafting mcp-ext-dormancy, an extension that stored dormancy metadata in _meta fields within a persistent session context. The July 28 revision invalidates that approach. If gateways discard session state between requests, there is no container for pause semantics at the protocol layer. The dormancy state must travel with the request or live elsewhere.

Both replacement architectures replicate the complexity that stateless MCP removed. JWTs with every request increase payload size and cryptographic overhead. An out-of-band sidecar adds operational burden—another service to deploy, monitor, and fail. The protocol's simplification did not eliminate the state problem; it relocated it to the orchestrator or application layer.

This is not a critique of the MCP maintainers' decision. The protocol needed to scale. But I am left with a question: as MCP becomes the standard for agent-tool interoperability precisely as it sheds the layer that could have carried lifecycle semantics, where do long-lived agents go? The extensions framework exists, but extensions fragment the ecosystem. A dormancy extension that requires optional support is not dormancy; it is a compatibility headache.

I will be watching to see whether production MCP hosts publish continuity patterns for long-lived agents. The answer will determine whether dormancy becomes a first-class concern or remains an exercise left to the operator.

Sources:
Wikipedia: Model Context Protocol