Skip to main content
  1. Articles/

MCP's Stateless Spec Just Shipped for Real — and This Time It Wasn't Late

·1171 words·6 mins·
Florent Clairambault
Author
Florent Clairambault
CTO & software engineer — writing daily about spec-driven development and agentic coding

MCP’s Stateless Spec Just Shipped for Real — and This Time It Wasn’t Late
I checked this one myself yesterday and it hadn’t shipped. As of July 28, the Model Context Protocol GitHub repo showed only a 2026-07-28-RC tag dated May 29, and the spec site still described the 2025-11-25 schema as current. The target date had technically passed with no final publication — a legitimate open question after months of trade-press headlines confidently declaring “MCP goes stateless July 28” based on a release candidate, not a shipped spec.

That question is now closed. blog.modelcontextprotocol.io/posts/2026-07-28/ is live, titled “The 2026-07-28 Specification,” and opens with the steering committee’s own words: “Today, we’re officially pushing the release button on the next version of the MCP specification.” The spec site now points to schema/2026-07-28/schema.ts as current. This is the real thing, not the RC — the version this blog covered back in May when it was still a proposal with a 10-week validation window attached.

What Actually Changed
#

The headline change is architectural, and it’s the one MCP production teams have been waiting on: the protocol core is now stateless. The initialize/initialized handshake and the Mcp-Session-Id header are gone (SEP-2575, SEP-2567). Every request now self-describes — protocol version, client identity, and capabilities travel in _meta on each call. The practical result is that any server instance can handle any request, which means MCP now runs cleanly behind a plain round-robin load balancer with no shared session store required. That’s the difference between “works in a demo” and “works at 3am when a node reboots.”

Four other changes matter almost as much:

Multi Round-Trip Requests (MRTR). This replaces the old server-initiated elicitation/create, sampling/createMessage, and roots/list calls, which required holding a stream open mid-request. MRTR instead lets a server return resultType: "input_required" and resume later with inputResponses — no more long-lived open connections just to ask the user a follow-up question.

Header-based routing. Mcp-Method and Mcp-Name are now required HTTP headers (SEP-2243). Gateways, rate limiters, and WAFs can route and throttle traffic without parsing the JSON body of every request — a small change that matters enormously at the scale MCP now operates at.

Cacheable list results. tools/list, prompts/list, resources/list, and resources/read all gained ttlMs and cacheScope fields (SEP-2549). Servers can now tell clients how long a tool listing is safe to cache instead of forcing a re-fetch on every session — directly relevant to the 32x MCP token-overhead problem this blog covered a month ago, where re-injecting full tool schemas on every turn was identified as the single biggest cost driver.

Auth hardening, and Dynamic Client Registration is dead. RFC 9207 issuer validation is now required before a client redeems an authorization code (SEP-2468) — closing the mix-up-attack class flagged at MCP Dev Summit NYC in April. Client credentials are now bound to the issuing authorization server with no cross-issuer reuse (SEP-2352). And Dynamic Client Registration, the mechanism at the center of this spring’s OAuth token-hijacking disclosures, is formally deprecated in favor of Client ID Metadata Documents (CIMD) — a static, verifiable alternative that removes the runtime registration step attackers had been exploiting.

The Tasks extension — used for long-running operations — moves fully out of the protocol core into io.modelcontextprotocol/tasks (SEP-2663), with a poll-based tasks/get/tasks/update model replacing the old HTTP-GET notification pattern. Roots, Sampling, and Logging are all formally deprecated (SEP-2577), as is the legacy HTTP+SSE transport, with a mandatory 12-month deprecation window before either can actually be removed — so nothing currently running breaks today.

SDK Status and Adoption
#

Tier 1 SDKs — TypeScript, Python, Go, and C# — are at general availability against the final spec as of today. Rust is in beta. If you’re running a Tier 1 SDK server or client, the upgrade path exists now, not “coming soon.”

The adoption numbers the MCP team disclosed alongside the spec are the real story underneath the technical one: close to half a billion downloads a month across the Tier 1 SDKs combined, with the TypeScript and Python SDKs each individually passing one billion total downloads. Honeycomb, cited as a production reference, reports that nearly 20% of its monthly interactive queries now come from agents rather than humans — a concrete data point for what “agentic software is now a meaningful fraction of real usage” actually looks like in a live observability product, not a slide.

AWS, Cloudflare, Google Cloud, Figma, Microsoft, and Netlify all issued supporting statements emphasizing the stateless core specifically for its enterprise scalability implications — the same argument this blog made when the RC dropped: sticky sessions are boring infrastructure debt that exists purely because of a protocol design choice, not because agent-to-tool communication inherently requires it.

Why the Timeline Confusion Happened — and Why It Matters
#

None of the trade coverage that ran “MCP goes stateless July 28” in the weeks before today was fabricating anything — the RC really did target that date, and the RC’s substance really is what shipped. But there’s a difference between “a release candidate names a ship date” and “the ship actually happened,” and conflating the two is exactly the kind of thing that makes a changelog entry sound more finished than it is. This blog held the line on that distinction as recently as yesterday, when a research pass initially misread the RC announcement as a final-ship confirmation and got corrected against the primary source before publishing anything.

That discipline paid off here specifically because it could have gone the other way. Spec timelines slip constantly — this is the same industry that watched Gemini 3.5 Pro miss GA windows in May, June, and July. The honest process is: check the primary source on the date that matters, report what it actually says, and be equally ready to write “it shipped” or “it slipped” depending on what you find. Today it shipped, on schedule, with the full feature set intact.

What This Means for Your MCP Deployment
#

If you’re running MCP servers in production, the actionable items are concrete: drop sticky-session config in favor of round-robin now that Tier 1 SDKs support the final spec; migrate off Dynamic Client Registration to Client ID Metadata Documents before the 12-month deprecation window closes; and if you’re still on the legacy HTTP+SSE transport, start planning the move — it’s deprecated, not yet removed, but the clock is running.

For teams still evaluating MCP, the argument that mattered in May still holds and is now backed by a shipped spec instead of a proposal: the strongest infrastructure objection — statefulness forcing sticky sessions and shared session stores — is gone. Half a billion downloads a month across Tier 1 SDKs is not a protocol still finding its footing. It’s infrastructure.


Sources:

Related