MCP Goes Stateless in Its Biggest Spec Update Yet

There's a particular kind of architectural mistake that only becomes obvious in retrospect: the kind where the original design choice seemed reasonable at the time, maybe even elegant, but slowly revealed itself as a load-bearing assumption that broke everything downstream. MCP's stateful session model was that mistake.

The 2026-07-28 release candidate for the Model Context Protocol fixes it — and the fix is substantial enough that Better Stack called it "a great reset for MCP, doing things the way they should have been done from the start."

That's a pointed thing to say about a protocol that's been moving fast and collecting real production deployments. But having looked at what the old design actually required of server operators, it's hard to argue otherwise.

The Original Problem Was Load Balancing, Basically

Here's what stateful MCP looked like in practice. A client would POST an initialize request to your MCP endpoint. Your server minted a session ID and sent it back. Every subsequent request carried that session ID — and crucially, that session ID was tied to the specific server instance that issued it.

Scale your MCP server to three instances, and you had an immediate problem: the next request might land on a different instance that had never seen that session. The result was a 400 session not found error, which is exactly as fun to debug as it sounds. Pod goes down? Same outcome — the session state was just gone.

The workarounds were real but genuinely annoying. Sticky sessions meant your load balancer had to route each client to the same instance, which undermines most of the reasons you'd want multiple instances in the first place. Alternatively, you could park session state in a shared Redis instance so any server could look it up — which works, but now you've added a dependency, additional latency, and something else to operate.

Better Stack's walkthrough puts it plainly: those workarounds "just added unnecessary complexity and also latency and costs."

What the New Spec Actually Does

The 2026-07-28 spec addresses this with two linked proposals. The first removes the initialize/initialized handshake. The second removes the Mcp-Session-Id header and the protocol-level session concept entirely. Every request is now fully independent.

The practical effect is that an MCP tool call shrinks from a multi-step sequence with session setup and headers to a single self-contained request. Any instance behind a load balancer can handle any request, because there's no shared state the instances need to agree on.

Cloudflare, which has its own stake in this given its Workers platform, noted in a post about the update that MCP no longer requires durable objects to speak the protocol. That's significant: durable objects are Cloudflare's solution for maintaining state across serverless invocations, and requiring them was a meaningful constraint on what kinds of infrastructure MCP could run on. Scale-to-zero deployments on Workers or Google Cloud Run are now straightforward, because there are no persistent connections to maintain.

Two new HTTP headers — Mcp-Method and Mcp-Name — also arrive with this spec. Previously all MCP metadata lived inside the JSON request body, which meant a gateway, rate limiter, or firewall had to parse JSON to make routing decisions. Surfacing method and name as HTTP headers lets that infrastructure work the way it already knows how to work.

The spec also adds ttlMs and cacheScope hints to tool, prompt, and resource list calls — borrowed directly from HTTP caching semantics. A client can now know how long a tool list stays fresh, and whether it's safe to share that cache across users.

Where the Handshake Information Went

Removing the handshake raises a reasonable question: some of that information was actually useful. The server might need to know what protocol version a client is running or what capabilities it supports. The new spec handles this by moving that information into a meta field in the JSON of each request, rather than requiring a dedicated setup exchange. Clients that need to discover what a server can do have a new optional server/discover method for that purpose.

The state question is worth pausing on, because "stateless" sometimes gets misread as "stateless forever, for everything." That's not what this is. If your application genuinely needs state — a shopping basket, a browser session, a multi-step workflow — you manage it yourself, the way HTTP APIs have always done it. Your tool mints an explicit identifier (a basket ID, a session handle), and the model passes it back as an ordinary argument on subsequent calls. The protocol stops pretending to own state management; you own it.

Multi-Round-Trip Requests and Long-Running Tasks

Two features that required rethinking under the stateless model are elicitation — the server asking the client a follow-up question — and long-running async tasks.

The old elicitation model needed a persistent open stream to push a question from server to client. Better Stack's breakdown flags why this was problematic beyond the architectural headache: "the user could be prompted out of nowhere without having asked for anything, which is a pretty bad experience and also a possible security problem."

The replacement is multi-round-trip requests. When a tool needs user input before proceeding — say, confirming a destructive operation — the server returns an input_required result instead of blocking. Attached to that result is a request_state payload: a serialized snapshot of all the context for that call. The client presents the question, collects the answer, and reissues the original request with the user's response and the echoed request state. Because the full context travels with the request, any server instance can pick it up. The flow is explicit, auditable, and doesn't depend on a persistent connection.

Long-running tasks get similar treatment through the Tasks extension, which graduates from experimental to an official extension in this spec. The model is familiar to anyone who's worked with async job queues: a tool writes its initial state to a database, kicks off the async work, and immediately returns a response telling the agent and user that processing has started. Clients can then poll for status with tasks/get or subscribe to progress updates through the tasks subscription mechanism.

What Upgrading Actually Costs

The spec ships with a substantial list of breaking changes and deprecations. The project has committed to a minimum 12-month deprecation window before anything is officially removed, which is at least a reasonable timeline for production services to adapt.

SDK support is already in place. Most SDKs have moved to a major version bump to reflect the scope of the changes. The TypeScript SDK, notably, replaced its monolithic package with separate server and client libraries — a modular split that makes the new architecture more explicit. A codemod exists to handle standard API renames automatically, though Better Stack is direct that this is not a "update the package and leave" situation.

The 12-month window makes this feel more manageable than it might look at first glance. But for teams running MCP in production today, the migration still represents real work — the kind that tends to get scheduled and then rescheduled when something more urgent shows up.

The Underlying Question

What's interesting about this update isn't just the technical delta — it's what the need for it reveals about how the protocol's original design assumptions interacted with real deployment environments.

MCP launched into a world where teams were immediately trying to run it at scale on standard cloud infrastructure. The stateful model required workarounds for what should have been defaults: round-robin load balancing, horizontal scaling, serverless deployment. The 2026-07-28 spec doesn't add new capabilities so much as it removes the friction that made standard infrastructure patterns awkward.

There's a broader pattern here that shows up repeatedly in protocol design: stateful designs feel cleaner during initial development (the server remembers things, you don't have to pass context around) but create operational pain at scale that stateless designs avoid by pushing state management to the application layer where it belongs. HTTP learned this. REST learned this. MCP has now learned this.

The more interesting question going forward is whether the ecosystem of tools and agents built on MCP adapts smoothly to the new model, or whether the migration surface — all those session IDs and handshakes baked into existing implementations — creates a long tail of half-upgraded deployments running against the grain of where the spec is headed.

---

By Dev Kapoor, Open Source & Developer Communities Correspondent