MCP Goes Stateless: What the 2026 Spec Changes

The Model Context Protocol is about to ship its largest revision since launch. The 2026-07-28 specification — release candidate locked on May 21, final version due July 28, 2026 — makes the protocol's core stateless, promotes interactive UIs and long-running tasks to official extensions, and introduces a formal deprecation policy. If you maintain an MCP server, the changes are good news operationally, but they come with a migration checklist.

Stateless core: the handshake is gone

The headline change: the new revision removes the initialize/initialized handshake and the Mcp-Session-Id header from the core protocol. Every request now carries what the server needs, so a server no longer has to remember who is talking to it between calls.

That sounds like plumbing, but it fixes the single biggest deployment complaint about MCP. Session state meant sticky routing: a fleet of MCP servers behind a load balancer had to pin each client to one instance. Stateless servers can sit behind a plain round-robin balancer, scale horizontally like any other HTTP service, and restart without breaking clients mid-session. For anyone running remote MCP servers in production, this removes an entire class of infrastructure workarounds.

Apps, Tasks and cacheable listings

Three additions matter most for server authors:

• MCP Apps (SEP-1865). Servers can ship interactive HTML interfaces that clients render in sandboxed iframes. A database tool can now return an actual query builder, not a wall of text. This was the most requested capability in the ecosystem and is now an official extension.
• Tasks becomes an extension. Long-running work — think index builds or batch jobs — gets a standardized lifecycle instead of ad-hoc polling conventions.
• Caching metadata (SEP-2549). List results and resources can declare ttlMs and cacheScope, so clients stop re-fetching tool listings on every turn. For servers with large tool catalogs, this is a straightforward latency and token win.

There is also governance maturity: SEP-2596 introduces a formal deprecation policy with minimum 12-month windows. Combined with the enterprise-managed authorization extension that went stable on June 18, 2026 — with Anthropic, Microsoft and Okta adopting it — the protocol is visibly settling into infrastructure-grade process.

Your migration checklist

Beta SDKs for the new revision shipped on June 29, 2026, and Tier 1 SDKs get a 10-week validation window once the final spec publishes. A pragmatic order of operations:

1. Audit session assumptions. Search your server for anything keyed on Mcp-Session-Id or populated during initialize. That state either moves into the request, the auth token, or an external store.
2. Upgrade to the beta SDK in a branch. The TypeScript and Python SDKs track the RC; most servers compile with minor changes since the SDKs absorb the handshake removal.
3. Declare cache metadata. If your tool list is static, advertise it — clients will reward you with fewer round trips.
4. Evaluate Apps only where UI earns it. An iframe form is a better picker than a 40-row text table, but every app surface is also an attack surface; the sandbox exists for a reason.
5. Do not rush deletions. Existing session-based servers keep working through the deprecation window. Target the stateless model for new deployments first.

Why this matters beyond MCP

Protocols reveal their trajectory in unglamorous details. Removing state, formal deprecation windows, enterprise auth with named adopters — these are the moves of a project preparing to be boring, dependable infrastructure rather than a fast-moving spec. For teams that bet on MCP early, the 2026-07-28 revision is validation: the protocol is optimizing for operators now, not just for demos.