Stateless MCP: Your Server Just Inherited the State

On 28 July 2026 the Model Context Protocol removed its initialization handshake and the Mcp-Session-Id header. If you operate a remote MCP server, the deployment win landed the same day: requests are self-contained, any instance can serve any one of them, and the sticky routing you built around the old transport can go in the bin.

Stateless MCP is the 2026-07-28 specification's core change: every request now carries its own protocol version and client capabilities, so no server has to remember anything about the last one. The protocol got smaller. The state did not go anywhere. Cross-call state becomes an explicit handle your tools mint and the model passes back as an ordinary argument, and identity gets re-established on every single request. Sessions were quietly doing three jobs for you, and only one of them was transport plumbing.

Here is what changed, why the working group went further than "make sessions optional", and the three responsibilities that just landed on whoever owns the server.

What "stateless MCP" actually means in the 2026-07-28 spec

A stateless protocol is one where the receiver must not retain session state between requests: every request can be understood on its own. SEP-2575, the standards-track proposal that did the work, quotes that definition directly and makes the obvious comparison to HTTP, which is stateless while carrying most of the stateful applications on the internet.

Before, a client opened with an initialize call, got back a session, and then attached an Mcp-Session-Id header to everything that followed. That header pinned it to one server instance. Now the request carries what the handshake used to negotiate:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{...clientInfo...}}}

Four details in that request matter more than they look.

MCP-Protocol-Version is mandatory on HTTP and has to match the value inside _meta, or the server must answer 400 Bad Request. Mcp-Method and Mcp-Name are new required headers, added so gateways can route and authorize on headers without parsing a JSON-RPC body. Client capabilities ride along on every request, and the spec is blunt that servers MUST NOT infer them from prior requests: an empty capabilities object means the client supports nothing optional, even if it declared otherwise thirty seconds ago. And version negotiation happens inline. Send your preferred version; if the server does not implement it you get UNSUPPORTED_PROTOCOL_VERSION (-32022) carrying the list of versions it does support, and you retry.

Worth knowing before you write the validator: client identity is softer than client capabilities. io.modelcontextprotocol/clientInfo was made optional after SEP-2575 was finalized, and clients now SHOULD send it unless they are configured not to. Reject a request for a missing protocol version. Do not reject one for a missing clientInfo.

There is a discovery RPC, server/discover, which returns supported versions, capabilities and usage instructions. Servers MUST implement it. Clients may ignore it entirely.

The practical effect, in the release-candidate post's words, is that a remote MCP server "can now run behind a plain round-robin load balancer". Cloudflare, which had been using Durable Objects to hold the stateful connection MCP required, now says MCP no longer needs one to speak the protocol and servers can run on request-scoped Workers. Netlify calls the result an ordinary HTTP workload. Nango, looking at it from the client side, counts the first tool call dropping from four HTTP round trips to two, and to one if the client has cached the tool list.

Those are platform and vendor posts, and they are all telling the true half of the story: the half where your infrastructure gets simpler.

Why sessions had to go, and not just become optional

The announcement coverage skipped the argument, which is a shame, because the argument is the most useful thing in the release. SEP-2567, the companion proposal that removed sessions themselves, makes a case that is worth reading even if you never touch MCP.

Nobody agreed what a session was. After more than a year in the spec, sessions had not converged on a consistent meaning across clients. ChatGPT created a fresh one for every individual tool call. Most desktop and IDE clients created one at application launch and held it for the process lifetime. Web clients typically created one per page load. Almost none resumed. If you wrote a server that tied a browser instance to "the session", you had no way to know whether that meant one user turn, one chat, or one week.

The reference SDK could not rehydrate one anyway. The TypeScript SDK's StreamableHTTPServerTransport stored session state in private instance fields with no API to restore it from external storage, so multi-node deployments could not honour resumption even when a client tried. Servers that appeared to be using session state successfully were usually stdio servers relying on process lifetime, which is a property of the transport rather than the protocol.

One session bought you exactly one of everything. Session state has a cardinality of one: the model gets one cart, one browser, one of whatever you scoped there. It cannot have two and it cannot have zero. SEP-2567's example is an orchestrator spawning subagents to research products. They should share a cart. They each need their own browser. No session boundary gives you both:

Session model	Cart (want: shared)	Browser (want: isolated)
Subagents share the parent's	shared	shared, and they clobber each other
Subagents get their own	isolated, so the order splits	isolated

And sessions taxed the clients that never used them. Because a tools/list result was allowed to vary by session, no client could safely cache one across a session boundary. For an orchestrator spawning short-lived subagents that meant O(subagents × servers) list calls, every subagent, every server, every time, even when the tool set was fixed at build time. Sessionless, the same workload is O(servers). The point that decided it: that cost came from sessions being possible, not from sessions being used, so making them opt-in would not have removed it.

Removing the session is what makes a list result a stable thing to cache. The same release then gave you the mechanics: tools/list, prompts/list, resources/list and resources/read responses now carry ttlMs and cacheScope (SEP-2549), so a client can hold a list for a stated period and invalidate on a list_changed notification instead of re-fetching on principle.

That is also why the working group rejected keeping an optional handshake. Two parallel interaction models would have meant two code paths in every server, every client and every SDK.

Transfer one: the session was your state container

With sessions gone, a server that needs state across calls mints an explicit handle. A creation tool returns an id, and subsequent tools take it as a parameter:

// → tools/call
{ "name": "create_basket", "arguments": {} }

// ← result
{ "content": [{ "type": "text", "text": "Created basket bsk_a1b2c3" }],
  "structuredContent": { "basket_id": "bsk_a1b2c3" } }

// → tools/call
{ "name": "add_item",
  "arguments": { "basket_id": "bsk_a1b2c3", "sku": "shoes" } }

The thing most summaries get wrong: this is not a protocol feature. There is no handles/* method and no handle type in the schema. From the wire's point of view basket_id is a string in a result and a string in an argument, indistinguishable from any other tool data. Explicit state handles are a tool-design pattern the spec documents and recommends, and the normative change is only the removal of sessions.

If that sounds familiar, it should. SEP-2567 points out that the large remote servers already work this way: Linear's create_issue returns an issue id, Notion returns a page id, GitHub returns a PR number, Stripe returns a customer id. Anyone who has designed a REST API in the last twenty years has written this pattern. The novelty is not the shape.

The novelty is where the handle lives. It sits in the model's context window, which means it also sits in the chat transcript, in subagent prompts, in whatever the user copied into Slack, and in the part of the conversation your client is about to compact away. SEP-2567 is direct about the client's job here: keep that string alive across compaction, because if the summariser drops it, the state it names is orphaned.

Three habits make handles behave. Keep them opaque, because a handle like cart_user42_2026-03-11 invites a model to guess the next one. Put the parameters on the creation call, so create_context(cluster="staging") beats create_context() followed by set_cluster() and the state can never exist half-configured. Ship a destroy_* and a list_* so a model that has lost track of what it made can recover.

Transfer two: the session was your lifecycle signal

A session ending was a free garbage-collection trigger. You do not get one now. A stateless server sitting behind a load balancer never sees a connection close.

So you own expiry. Pick a TTL, and then do the part that is easy to miss: write the durability policy into the tool's own description, not into your documentation. "Returns a basket_id; baskets expire after 24h idle" belongs where the model can read it at the moment it decides to create state. A policy that lives only in your docs site is invisible to the thing making the decision.

Then make the failure legible. When a tool gets a handle for state that has expired, the error should say basket bsk_a1b2c3 has expired, not invalid argument. A model that reads the first one calls create_basket again and carries on. A model that reads the second one retries the same broken call until something gives up.

Worth being honest about the baseline here: sessions never delivered reliable cleanup either. Against a per-tool-call client the state was destroyed before the next call; against a per-app-launch client it outlived every conversation in the window. Servers were already leaning on TTL-based expiry. The change is that the TTL is now the whole mechanism instead of a backstop, and the model can see it.

Transfer three: the session was your identity and correlation key

SEP-2575 puts the security consequence in one line: without a handshake, every request must be independently authenticated and authorized, and implementations MUST make sure authentication is not bypassed by the removal of the initialization phase.

The rule that follows is the one to tattoo somewhere. Possession of a handle is not authorization. For an authenticated server, validate the pair (handle, auth_context) on every call, because handles end up in chat logs and copy-paste buffers and other people's screens. The model for this is a Google Doc id or a GitHub PR number: the id names the resource, the auth context on the request decides access. For a server with no authentication, the handle is a bearer token, so generate it from a cryptographically secure source with at least 128 bits of entropy and give it a bounded lifetime.

If that feels like new work, look at what it replaced. SEP-2567 documents that the Python SDK's stateful session manager routed on Mcp-Session-Id alone, without checking that the authenticated identity on the request matched the one that created the session, so a leaked session id let any other authenticated principal hijack it. Session ids were already capability-bearing. The spec change did not create that requirement, it made it visible.

The rest of transfer three is bookkeeping, and it is the part that bites in production:

• Telemetry and rate limits keyed on the session id need a new key. Use the authenticated principal (bearer-token subject, API key) or a request-level correlation id.
• PKCE verifiers stored against a session move to a server-generated nonce carried in the OAuth state parameter, which was never an MCP request and never had the header anyway.
• Session-to-user pinning can be deleted. It existed to defend against session routing being decoupled from auth, which stops being a problem once every request authenticates itself.

Alongside this, the same release hardened OAuth. Issuer validation is now required, client credentials are bound to the issuer that minted them, and Client ID Metadata Documents replace Dynamic Client Registration, which Cloudflare notes is slated for removal after summer 2027. WorkOS's walkthrough of the auth changes covers the RFCs involved if you are implementing the client half.

The removals that never make the changelog summary

The bullet-list recaps stop at the session header. These are the ones that will page someone:

• Resumable SSE streams are gone. A dropped connection now implicitly cancels the request, and reconnecting with Last-Event-ID no longer resumes anything. On HTTP, closing the response stream is the cancellation signal. Anything long-running has to move to the Tasks extension, where a tools/call can return a task handle that the client drives with tasks/get, tasks/update and tasks/cancel. If you shipped against the experimental Tasks API in 2025-11-25, that lifecycle changed too.
• ping is removed in both directions, on the reasoning that any normal RPC already proves the server is alive and transport keep-alives handle the rest.
• resources/subscribe and resources/unsubscribe are gone, along with the HTTP GET channel for server-to-client messages. Everything is POST now. A client that wants notifications calls subscriptions/listen and opts in explicitly to each type; the server must not send a type that was not requested.
• logging/setLevel is removed with no replacement RPC. Log level is a per-request _meta field, and if it is absent the server must send no log notifications for that request.
• Your tool list may no longer change as a side effect of another call. The pattern where calling connect_database() makes query and list_tables appear in the next tools/list is not allowed. Expose them unconditionally and have them take a connection_id, and return an error pointing at connect_database when it is missing.
• Servers can only initiate a request while processing one. Elicitation, sampling and roots round-trips are replaced by Multi Round-Trip Requests: the server returns input_required with a requestState token, and the client re-issues the original call with the answers attached. Any instance can pick up that retry, which is the whole point.

One thing to keep straight, because it is the easiest mistake to make when skimming the release notes. Roots, Sampling and Logging are deprecated, and the new policy guarantees them for at least twelve months. Sessions were removed, with no deprecation window at all. The migration path for a server that still needs session semantics is to stay on the older protocol version until it has moved to handles.

What to change, by server category

SEP-2567 ran an automated survey of a 1,000-repo random sample of open-source MCP servers, classified by per-repo LLM analysis, and sorted them by how much work the change creates:

What your code does with the session id	Share	What you do
Nothing; no application-level reference to it	90.0%	Nothing
Map<sessionId, Transport> routing (TS SDK boilerplate)	3.5%	Disappears with a sessionless SDK transport
Transport setup only (sessionIdGenerator, never read)	2.8%	Delete one constructor option
Keys application state	2.5%	Move to explicit handles, or to the auth principal
Sticky routing in a proxy or gateway	0.7%	Needs a designed replacement
Binds auth artifacts (JWT claims, PKCE verifier)	0.5%	Server-generated nonce, or the token subject

Read that top row with the methodology in mind: it is a sample of public repositories classified by a model, not a census of production deployments, and the servers doing the most interesting work are disproportionately the ones in the last three rows. Still, the shape is credible, and it matches the fact that every official SDK except PHP already had a stateless mode. sessionIdGenerator: undefined in TypeScript and stateless_http=True in Python were opt-in flags. The new spec version makes that the only mode.

Gateways are the genuinely hard case, and SEP-2567 says so: routing by session id needs a designed replacement rather than a mechanical edit. The consolation is that a gateway only needed a sticky routing key because its upstream was stateful. Once the upstream keys its state on a handle that any replica can look up in shared storage, the sticky routing has nothing left to do. The residual case is bridging HTTP to a stdio subprocess, which needs its own correlation key at the transport layer.

If you are supporting both protocol versions for a while, the fallback differs by transport. On HTTP, send a new-style request and fall back when you get a 400. On stdio there is no per-request error to key off, so probe with server/discover first.

The order we would work in: grep for Mcp-Session-Id and sessionIdGenerator to find out which row of that table you are in; add the create_* tool and its destroy_* before touching anything else, so the state has somewhere to live; move authorization to (handle, auth_context) on every call before you advertise the new protocol version; then re-key telemetry last, because that is the one that fails quietly.

What the spec still refuses to decide for you

StackOne, who sell tooling in this space and so have a stake in the answer, make a fair point about what the specification deliberately leaves out. It standardises how a tool is described, called and transported. It says nothing about whether a given agent should be allowed to run a given action against a system of record, who approved a write, or what was logged and whether you can still query it in six months. Their view is that this work lives at the execution and governance layer, and they are sceptical that a human approval prompt survives contact with volume.

We think that boundary is correct for a protocol, and we would rather it stay there than watch a standards body try to model your approval workflow. It is also worth noticing that statelessness makes that layer easier to build. Every request now carries its own identity and announces its method and target in headers, so a gateway can authorize tools/call on payments.refund without terminating a session or parsing a body. That is the same move as routing LLM traffic through a provider-agnostic gateway: the protocol keeps getting simpler and the operational surface keeps sliding toward the team running the thing.

Frequently asked questions

Is MCP fully stateless now?

No, and the spec is careful to say "stateless by default". SSE streams still carry several messages inside a single HTTP request, so there is state inside that window. The difference is that the complexity is constrained to one request and optional to use.

Do I have to rewrite my MCP server?

Probably not. In SEP-2567's survey, 90% of sampled servers made no application-level reference to the session id at all. Grep for Mcp-Session-Id and sessionIdGenerator: if neither appears outside transport setup, your migration is an SDK upgrade.

What replaces Mcp-Session-Id for keeping state between tool calls?

An explicit state handle. A creation tool returns an opaque id, later tools accept it as an argument, your server owns the underlying state, and the model carries the name. The protocol has no idea any of this is happening.

Does removing sessions make my server less secure?

It changes the exposure surface rather than introducing a new class of vulnerability. Handles reach places session ids did not, so validate (handle, auth_context) on every call. That was already the correct posture for session ids, and at least one reference SDK got it wrong.

How long until the old protocol version stops working?

Two different clocks. Deprecated features (Roots, Sampling, Logging, the legacy HTTP+SSE transport) are guaranteed for at least twelve months under the new deprecation policy. Session removal came with no window, so a server that depends on session semantics stays on the older protocol version until it migrates.

Pin the version before you chase the feature

Stateless MCP is a good change, and the deployment story genuinely improves. The part worth planning for is that a protocol version bump is a behaviour change with an agent on the other end of it, which puts it in the same category as swapping the model underneath a feature. We argued previously for putting an eval gate in front of a model swap; the same reasoning applies to a client that quietly stops declaring a capability it used to have.

So before you migrate: pin the protocol versions your server accepts, log the version and client identity that every request actually sends, and keep the old path alive until that log tells you nobody is using it. The header is right there on every request now. You may as well read it.

If you are building agent infrastructure and want a team that has shipped this kind of thing before, that is what we do at Vantaso, or say hello at contact@vantaso.org.