MCP goes stateless: what the 2026-07-28 spec changes

MCP goes stateless: what the 2026-07-28 spec changes

The Model Context Protocol's 2026-07-28 revision went final today, and the maintainers aren't underselling it: it's the largest change to the spec since MCP launched. The GitHub release marks it as the stable tag, closing out a release candidate that was locked back in late May. If you run or build against MCP servers, the two things worth knowing are what changed and how fast you actually need to move.

The headline change: no more sessions

Every MCP connection used to start with an initialize / notifications/initialized handshake, and the resulting session lived behind an Mcp-Session-Id header that pinned a client to one server instance. That's gone. The new revision removes protocol-level sessions entirely, so a server can sit behind an ordinary round-robin load balancer instead of needing sticky routing or a shared session store — the same shape most other HTTP services already run in.

Client info and capabilities that used to travel once, at connection setup, now ride along in _meta fields on each request. Every call is self-contained; nothing about the protocol layer remembers you from the last one.

What replaces state: explicit handles

Plenty of real MCP servers used the session to hold per-client state across tool calls — a shopping basket, an open browser tab, a half-finished multi-step operation. Stateless doesn't mean state disappears; it means the protocol stops hiding it. The recommended pattern, per the release notes, is an explicit handle: a tool call returns an identifier — a basket_id, a browser_id — and the model passes that handle back as an ordinary argument on later calls. State becomes something the model can see and reason about instead of transport plumbing it never touched. Servers with real session logic have actual migration work to do here; simple, stateless tool servers mostly don't notice the change.

The other three pieces

Sessions weren't the only thing in this revision:

• Extensions framework. Optional capabilities now get formal governance — reverse-DNS identifiers, independent versioning, their own repos with delegated maintainers, and a Standards Track inside the Specification Enhancement Proposal process. Instead of the core spec growing forever, features graduate into extensions that can move on their own schedule.
• MCP Apps. Now a standing extension rather than an experiment: servers can ship interactive HTML interfaces that hosts render inside a sandboxed iframe. This is the tracker's mcp-apps entry made official — worth watching, since if it lands broadly it starts to blur MCP's tool layer into frontend-protocol territory that AG-UI and OpenAI's Apps SDK also occupy.
• Tasks, redesigned. The Tasks extension is rebuilt for the stateless model: clients drive the lifecycle explicitly with tasks/get, tasks/update, and tasks/cancel instead of relying on an implicit session to track a long-running job.

Authorization gets stricter, not different

The auth side didn't get a new model, but six Specification Enhancement Proposals tighten how the existing OAuth 2.0 / OpenID Connect alignment behaves: iss parameter validation per RFC 9207, an application_type declaration during Dynamic Client Registration, and stricter issuer binding. If your server already does standards-compliant OAuth, this is hardening, not a rewrite.

A deprecation clock, finally

Up to now, MCP had no formal policy for retiring anything. This revision adds one: features move through Active → Deprecated → Removed, with a minimum 12-month window before a deprecated feature can actually go away. Roots, Sampling, and Logging are the first three marked deprecated under the new policy — they still work, but they're now on notice.

What actually breaks today: nothing

This is the part worth being precise about, because "biggest revision since launch" reads scarier than the rollout is. Publishing the spec on July 28 doesn't flip a switch — existing clients and servers keep working exactly as they did yesterday. The SDK side backs this up: Python, TypeScript, Go, and C# — the four Tier 1 SDKs — all shipped beta packages supporting the new spec, but as opt-in major versions. TypeScript's v1 line gets a minimum six more months of support; Python v1 gets critical bug fixes and security patches. Stable installs keep resolving to v1 by default. Moving your own server onto v2 is a breaking change you take on your own schedule, not one forced on you by the calendar.

One caveat: that safety net only covers the four Tier 1 languages. Community SDKs outside that list have no guaranteed timeline for 2026-07-28 support, so if you're building on one of those, wait for its maintainer to publish a migration date before you plan around it.

Where this leaves you

If you maintain a simple MCP server — a handful of stateless tools, no per-client memory — this revision mostly doesn't touch you; update the SDK when it's convenient. If your server leans on session state for anything nontrivial, the explicit-handle pattern is the thing to design toward before you touch v2, since it changes where that state lives, not just how it's transported. And if you're on Roots, Sampling, or Logging, the 12-month clock is real but not urgent — plenty of runway to migrate off deliberately rather than in a scramble.

MCP earned the benefit of the doubt here: it's the protocol every major agent vendor converged on and the Linux Foundation's Agentic AI Foundation now stewards, and a stateless core is a normal, boring evolution for a protocol that outgrew its original assumptions. Track the current status on the protocol tracker.