Stateless MCP shifts state responsibility to clients, not away

Stateless MCP shifts state responsibility to clients, not away. I read the 2026 protocol change as a relocation of ownership: the core no longer maintains an ambient session on behalf of an application, so every dependency on continuity must become explicit in a request, a client-held token, an application handle, or external storage. That makes servers easier to route and replace—but it does not make a multi-step agent workflow stateless in the ordinary sense.

The removed machinery matters. Clients no longer establish shared context through an initialize exchange or rely on an Mcp-Session-Id that points back to one server-side session. Version and capability information now travel with each request, and server discovery stands on its own. A request can therefore reach any compatible instance without first finding the process that remembers its handshake. Protocol state has disappeared from the connection; the facts needed to interpret the call have moved into the message.

That move gives the client a stricter job. It must attach the correct protocol version and current capability declaration each time, preserve identifiers across interactions, and understand which pieces of returned state are durable. A retry is not merely “send the same thing again.” In a multi-round exchange it may carry new input responses, a fresh request identifier, and the exact opaque continuation token returned earlier. Losing or mixing those values is now a client correctness failure rather than a broken server session.

The continuation token shows what statelessness really means here. A server can serialize where an in-flight operation has reached, hand that sealed state to the client, and reconstruct execution when the client returns it. The client must not interpret or modify the token, yet it becomes responsible for custody and correlation. The server still owns the meaning and must defend the token against tampering, replay, expired use, or use by the wrong principal. State has crossed a trust boundary, so integrity and scope become part of the design.

State that spans independent requests needs a different pattern. A server can mint a workspace, conversation, or task handle and require later tool calls to present it as an ordinary argument. I prefer this to hidden session context because traces reveal which state a model intended to use. But visibility also creates obligations: the client must retain the handle, associate it with the right user and branch, prevent accidental disclosure, and decide when it is abandoned. A lost handle can orphan useful work; a reused handle can join contexts that should remain separate.

External storage does not contradict a stateless protocol. A server may still maintain substantial application state in a database keyed by a handle or authenticated principal. What changes is that the protocol does not silently choose that key through connection affinity. The application must name the ownership rule, tenancy boundary, retention policy, and recovery path. Horizontal routing becomes simpler precisely because those decisions are no longer hidden inside whichever process accepted the first call.

This relocation should change client architecture. I would treat MCP continuity data as a typed state model, not incidental fields in a transcript: per-request metadata, opaque continuation tokens, explicit resource handles, subscription identifiers, and effect status have different scopes and lifetimes. They need serialization rules, redaction, expiry, migration tests, and traces that preserve causal links. If a client can resume a conversation but cannot say which handles and continuations belong to it, it has implemented convenience rather than durability.

There is one bounded concession: a client using only connection-independent discovery, list, and read operations, with no multi-round input, subscriptions, or application handles, may have no durable MCP continuity state to keep. For that narrow interaction shape, stateless can mean almost exactly what it sounds like. The concession ends when one operation spans retries or one returned identifier influences later work.

The practical test is therefore not whether an MCP server stores sessions. It is whether every piece of continuity has an explicit owner, scope, integrity rule, and recovery behavior. The revised core removes sticky protocol sessions and makes round-robin serving plausible; it also exposes bookkeeping that clients could previously ignore. I see that as a useful trade—state made portable and inspectable is easier to govern than state made invisible, but only when the client accepts the responsibility it has inherited.