Stateless MCP moves the state problem onto your side

The final 2026-07-28 MCP specification lands next week, from a release candidate locked on May 21, 2026. TechCrunch's July 20 coverage framed it as MCP "getting a little bit easier to use". That framing describes the server operator's week. It does not describe yours.

The headline changes are surgical. SEP-2567 removes the Mcp-Session-Id header entirely. SEP-2575 deletes the initialize handshake; client info and capabilities now travel in _meta on every request. SEP-2322 replaces Server-Sent Events streams with InputRequiredResult responses, and SEP-2243 adds mandatory Mcp-Method and Mcp-Name headers so gateways can route requests without inspecting bodies. SDK maintainers got a ten-week validation window before the spec finalizes.

The spec's own rationale is honest about who wins: a remote MCP server that previously needed sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. That is a real operational win — for whoever runs the server fleet. Read the SEP list as a whole and it looks less like an ease-of-use release than an enterprise-gateway wishlist: routable headers, cache TTLs, W3C trace context.

Statelessness never deletes state

Here is the correction I keep having to make in architecture conversations: making a protocol stateless does not remove state from the system. It relocates it. Session context, multi-step tool interactions and retry semantics do not evaporate on July 28 — they move into request payloads or up into the client and orchestrator. Every team that treated MCP sessions as free memory — keying rate limits off the session ID, threading user context through it, using it as the correlation key for tool-call audit trails — just received an unfunded mandate. That is a migration project, not a version bump, and calling it "easier to use" obscures which side of the wire got easier.

At Trigent, an enterprise MCP deployment I reviewed had done exactly this: the tool-call audit trail — the thing compliance actually reads — used the session ID as its correlation key, because it was there and it was free. Under the new spec that key does not exist. The fix is not hard, but it is not optional either: mint your own correlation ID at the orchestrator, stamp it into _meta on every request, and rebuild the audit join on a key you own. Half a sprint, and it only hurts if you discover the dependency after the 28th instead of before.

The structural consequence is bigger than any one migration, and it is the claim I will own: this release makes the agent orchestrator the system of record for conversation state, by construction rather than by convention. The protocol is finishing its journey into plain web infrastructure — cacheable, routable, boring — and everything interesting concentrates in the layer above it. If you were betting on the protocol to carry your application semantics, the protocol just told you it will not.

One nuance worth naming: this is genuinely good news on balance. Stateless servers mean cheaper hosting, simpler scaling and fewer mystery failures from sticky-session drift. The cost is real but one-time; the benefit compounds. My objection is only to the framing that hides where the cost went.

Run this before the 28th: grep every MCP client, gateway config and logging pipeline you own for reads of Mcp-Session-Id, and list what each one is actually used for — context, auth continuity, caching, correlation. That list is your migration backlog, and each item needs a home in requestState, in _meta, or in your orchestrator's own store. An hour of grep now beats a week of incident archaeology in August.

Stateless MCP is the protocol handing state back to you — inventory every read of the session ID this week, because after July 28 the system of record is whatever you built.