Stateless MCP: the spec is dropping session state

The next version of the Model Context Protocol removes the two things that, until now, defined a connection: the initialize handshake and the MCP-Session-Id header. The 2026-07-28 release candidate, published May 21, 2026, makes the protocol core stateless. Any server instance can answer any request, with no per-client session to set up first and nothing to keep warm between calls. This reads like transport plumbing, the kind of change that matters to people running load balancers and nobody else.

It is more than that. A stateless protocol core changes where an agent’s state lives, whether the model can see it, and whether it survives a reconnect or a handoff. Those are context engineering questions, not just infrastructure ones. This post walks through what MCP session state actually was, mechanically, why hiding it inside the connection fought scale, and what the stateless redesign does with it instead.

What stateless MCP actually changes

Stateless MCP removes session setup from the protocol so that no request depends on a prior one. In the 2026-07-28 release candidate, the initialize/initialized handshake and the MCP-Session-Id header are both gone, and the metadata they used to carry, client info, declared capabilities, and protocol version, now rides in _meta fields on every individual request. The practical result, in the maintainers’ own framing, is that a remote MCP server “can now run behind a plain round-robin load balancer,” with traffic routed on a header that names the JSON-RPC method rather than on a session identifier.

The release candidate is not the stable spec yet. It was published May 21, 2026, the final specification ships July 28, 2026, and the announcement is explicit that it “contains breaking changes.” It is the largest revision of the protocol since launch: alongside the stateless core, it formalizes an Extensions framework, moves Tasks for long-running work from experimental core into an extension, ships MCP Apps for server-rendered UI, and hardens authorization across six SEPs. The stateless core is the piece that touches every server, because it changes the shape of a request.

What MCP session state was, mechanically

Today’s MCP session is a stateful handshake that pins a client to one server instance for the life of the conversation. Under the stable 2025-11-25 Streamable HTTP transport, a session begins when the client POSTs an InitializeRequest. A server that wants a stateful session assigns a session ID and returns it in the MCP-Session-Id header on the InitializeResult response. From that point on, the client “MUST include it in the MCP-Session-Id header on all of their subsequent HTTP requests.”

That single header carries a surprising amount of weight. During initialization the client and server negotiate capabilities and protocol version once, and the server holds the result for the session. The server can open a Server-Sent Events stream (the client issues a GET to the same endpoint) so it can push requests and notifications back, and that stream is bound to the session. Event IDs are assigned per stream so a dropped connection can resume from a Last-Event-ID cursor. All of this, the negotiated capabilities, the open stream, the redelivery cursor, lives in the instance that issued the session ID.

The spec is precise about what happens when that state is missing. A server that requires a session ID “SHOULD respond to requests without an MCP-Session-Id header (other than initialization) with HTTP 400 Bad Request.” A server may terminate a session at any time, after which it “MUST respond to requests containing that session ID with HTTP 404 Not Found,” and a client that receives a 404 “MUST start a new session by sending a new InitializeRequest.” To end a session cleanly the client sends an HTTP DELETE, which the server is free to refuse with a 405. None of this is exotic, but every rule assumes one server holds the session, and that assumption is the whole problem.

Why hidden session state fights scale

Connection-pinned session state breaks the moment a request lands on an instance that did not issue the session. A load balancer distributing requests across a fleet has no idea that MCP-Session-Id: 1868a90c... only means something to instance number three. Send the next call to instance number seven and the spec-compliant answer is HTTP 404, which forces the client to re-initialize from scratch in the middle of a conversation. The roadmap maintainers name the symptom directly: “stateful sessions fight with load balancers” and “horizontal scaling requires workarounds.”

The workarounds are the cost. To keep a stateful server correct behind a load balancer you reach for one of three things, and the release candidate calls out exactly this trio as what teams had to do before: “sticky sessions, a shared session store, and deep packet inspection at the gateway.” Each carries a tax.

Sticky routing couples your scaling to your session map, so a scale-in event or a rolling deploy evicts live conversations. A shared session store (Redis is the usual choice) adds a network hop to every call and a new dependency that can fail independently. Deep packet inspection at the gateway means the gateway has to parse MCP to route it. All three exist to preserve one thing: state the agent depends on but cannot see.

Stateless transport, explicit application state

A stateless core still allows stateful applications. What changes is where that state lives: out of the connection the transport manages, and into the open where the model can see it. This is the part of the redesign that matters most for context delivery. A stateless core does not forbid a stateful application, like a multi-step workflow that has to remember what it did three calls ago. Instead of hiding that progress inside a session the transport manages, the server “issues explicit handles” that the model “threads between tool calls as ordinary arguments.” A tool returns a handle, the model carries it forward, the next tool call presents it, and the durable data lives in a store addressed by that handle rather than pinned to a connection.

That is a context offloading pattern promoted into the protocol. The handle is a reference the model holds in context; the bulk lives elsewhere and is retrieved on demand. The difference from a hidden session is that the reference is now part of the conversation the model can see, log, and reason about, rather than an opaque header the agent echoes without understanding. State the agent can name is state the agent can pass on, which is exactly the property that breaks down at agent handoffs, where the receiving agent inherits a summary but not the underlying session it was built from.

What this means for context delivery

Stateless MCP reframes session state as a context engineering decision rather than a transport detail. Hidden session state is context: capabilities, progress, and stream position that the agent’s behavior depends on. Burying it in the connection made it invisible to the model and fragile under any event that moved the request, a restart, a scale-out, a dropped stream. Making it explicit, as _meta on each request and handles in the tool arguments, makes the same state portable. It can be inspected, carried across a reconnect, and in principle handed to another agent without a hidden session to reconstruct.

This is the same property a context container is built around. A connected agent talks to a Wire container as a remote MCP server whose per-container state is addressed by the request rather than pinned to the connection, so a dropped stream resumes against the same container instead of returning a 404 and forcing a fresh handshake. The container holds the state, not the connection, which is the addressed-not-pinned shape the stateless spec is pushing the rest of the ecosystem toward.

The reliability math follows from that. A protocol where any instance can answer any request has no “the server I was mid-conversation with went away” failure mode, because there is no specific server to lose. For agents that hold long tool sequences, the class of bug where a scale event silently drops the thread is one of the quieter contributors to agents losing the plot over a long run. Removing it does not make agents smarter, but it removes a way for the substrate to corrupt an otherwise healthy run.

What to do now if you run MCP servers

Build against the stable 2025-11-25 spec today and isolate session handling so the stateless migration is a swap, not a rewrite. The release candidate is real and worth reading, but it is a candidate with breaking changes and a July 28, 2026 ship date, so the stateful Streamable HTTP behavior is still the contract for production clients. A few concrete moves:

Wrap session management behind your own interface. If your code reads MCP-Session-Id directly in more than one place, the stateless core will touch all of them. A thin abstraction over “how this client and server establish identity” lets you move from session header to per-request _meta without rewriting tool logic.

Prefer explicit handles in your own tool designs. Even on today’s spec, a tool that returns a named handle and accepts it back is more portable than one that relies on the server remembering what the last call did. You get the stateless application pattern early, and the tool reads more clearly to the model because its state is in the arguments.

Treat the gateway as a moving part. Routing that depends on deep packet inspection of a session ID is exactly what the stateless core obsoletes. Keep that logic swappable. For the broader picture of how these pieces fit together, the MCP 2026 roadmap as a context-delivery story covers the other priorities the release candidate delivers on.

The through line is simple. The transport is getting better at moving context to agents at scale, and the way it gets there is by refusing to hide state the agent depends on. State you can see is state you can move. That has always been the goal of context portability, and a stateless protocol core is the transport finally agreeing with it.

Sources: MCP 2026-07-28 specification release candidate · MCP specification 2025-11-25: Transports · MCP specification 2025-11-25: Lifecycle · The 2026 MCP roadmap