The 2026-07-28 Model Context Protocol spec makes MCP stateless by default, and the reflex reaction — "great, no more state to manage" — is the wrong read. **Statelessness moves state out of the protocol, not out of existence.** Your server can be exactly as stateful as your product needs; the spec just stops handing you a session for free. So the real decision is not do I need state — you often do — but who owns it: the wire, or me? After July 28, the answer is you.
Here is the short version for anyone deciding whether to worry: for a plain request/response tool server, going stateless is a straight win and barely any work. For a long-lived, streaming, back-channel-heavy server, it is a genuine rebuild. The rest of this piece is how to tell which one you are.
What the session was quietly giving you#
A session is not just an ID. Under the old 2025-11-25 model, the initialize handshake and the Mcp-Session-Id header bought you three conveniences you may not have noticed you were using:
- Ambient context. Capabilities negotiated once at the handshake rode along every later request for free.
- Held-open streaming. A long job could keep an SSE stream open and push progress down it.
- A back-channel to the host's model. Sampling let the server ask the client's LLM to generate something mid-call.
Delete the session and all three change. Context now travels explicitly in _meta on each request. Long jobs move to polled task handles. And Sampling is deprecated — the server calls an LLM provider API directly instead of borrowing the host's.
What you get in exchange#
The payoff is entirely operational, and for most teams it is worth more than what you gave up:
- Horizontal scale for free. Any instance serves any request. Round-robin load balancer, no sticky sessions, no shared session store to run and pay for.
- Gateway routing. Proxies route on the
Mcp-MethodandMcp-Nameheaders without parsing the body. - A smaller, more honest contract. The host owns the model and the filesystem boundary; MCP is the stateless tool surface between them. Less ambiguity about who is responsible for what.
The old contract let a server reach back through the client for a brain and a filesystem. The new one says no: the host owns those. MCP becomes plumbing — and plumbing is exactly what the agent stack has been short on.
Where your state actually goes now#
This is the part that decides your migration. Every capability the session used to carry has a new, explicit home:
| Was carried by the session | Now lives in |
|---|---|
| Long-running job progress | Task handles you persist (tasks/list is gone — you hold the IDs) |
| Filesystem scope (Roots) | Tool parameters, resource URIs, or server config |
| Server-initiated generation (Sampling) | A direct call to an LLM provider API |
| Per-connection context | Your own store, keyed by user or agent identity — not a session ID |
That last row is the mental model shift. You do not stop storing state; you re-key it from "this session" to "this identity," which is how a horizontally-scaled service should have been keyed anyway.
The decision, in one line#
If your server is a set of tools that take input and return output, migrate and enjoy the free scaling — it is nearly a no-op. If your server is a long-running, streaming, loop-shaped thing that leaned on Sampling or Roots, you have real work, and the honest move is to schedule it deliberately rather than rush it before the deadline. Either way, the migration mechanics are here, and the deprecated features keep working for at least twelve months — so the calendar pressure is a nudge, not a threat.
The one question that sorts every MCP server into its migration bucket: did you own your state, or did the wire? After July 28, there is only one right answer — and the servers that already owned it barely have to move.
