herman.engineer
FR

WritingField notes

MCP Goes Stateless: What’s Actually in the 2026-07-28 Spec

The largest revision of the Model Context Protocol since launch, in plain terms: stateless core, extensions, new auth rules, and what you need to migrate.

4 min 3 sources
Editorial collage: a 1950s switchboard operator plugging in cables, a red paper circle beside the board like a signal lamp.
On this page OpeningSessions are goneMulti Round-Trip Requests replace server-initiated requestsInfrastructure finally gets a seatExtensions: the core gets smaller, on purposeAuthorization got harder to get wrongThe deprecation listSDK statusWhat to actually doSources

On July 28, the Model Context Protocol shipped its largest revision since launch1. If you build or run MCP servers, this one is not optional reading. The protocol you integrated in 2025 has structurally changed, and the old shapes are now on a twelve-month deprecation clock.

This is not an essay. It is a field note: what changed, why, and what you need to do about it.

Sessions are gone

The 2026-07-28 spec drops the stateful, bidirectional design for a stateless request/response core. Concretely:

The initialize/initialized handshake is removed. So is the Mcp-Session-Id header. Each request is now self-describing: it carries the protocol version (MCP-Protocol-Version: 2026-07-28), client identity, and capabilities in the _meta field (io.modelcontextprotocol/clientInfo).

Why it matters: any server instance behind an ordinary load balancer can answer any request. No sticky sessions, no shared session store, no warm-up round trips. MCP servers now scale like plain HTTP services, which is what most operators were painfully faking with session-affinity workarounds.

If your server kept per-session state, the guidance is explicit: mint an explicit handle from a tool and have the model pass it back as an argument. State becomes visible to the model instead of hidden in transport plumbing.

Multi Round-Trip Requests replace server-initiated requests

With no open stream, a server can no longer push a request back to the client mid-call. The replacement is Multi Round-Trip Requests (SEP-2322): a tool that needs more input returns resultType: "input_required" with the prompts it needs, and the client retries the original call with the answers in inputResponses. Confirmations and missing-parameter collection now work over a fully stateless transport.

Infrastructure finally gets a seat

Two changes are aimed squarely at the people running gateways rather than writing tools:

Header-based routing (SEP-2243). Requests must carry Mcp-Method and Mcp-Name headers, so rate limiters, WAFs, and gateways can route and authorize without parsing JSON bodies.

Cacheable lists (SEP-2549). tools/list, prompts/list, resources/list, and resources/read responses now carry ttlMs and cacheScope, so clients can stop re-fetching tool catalogs on every conversation.

Extensions: the core gets smaller, on purpose

The spec now has a formal extensions framework. Extensions are identified by reverse-DNS IDs, negotiated through an extensions map in capabilities, live in their own repositories with their own maintainers, and version independently of the core spec.

Three notable ones:

  • Tasks (io.modelcontextprotocol/tasks, SEP-2663) moved out of the experimental core. Long-running work is now polling-based (tasks/get, plus a new tasks/update), with change notifications consolidated into a single opt-in subscriptions/listen stream.
  • MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe.
  • Enterprise Managed Authorization for organizations that need centrally administered auth.

The direction is clear: a small, stable, boring core, with innovation pushed to the edges where it can move fast without breaking everyone.

Authorization got harder to get wrong

Several production-security fixes landed at once:

  • Authorization servers must return the iss parameter per RFC 9207, and clients must validate it (SEP-2468).
  • Clients declare application_type during registration, fixing the localhost-redirect mess for CLI and desktop apps (SEP-837).
  • Client credentials are bound to the authorization server that issued them and cannot be replayed across providers (SEP-2352).
  • Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents (CIMD).

The deprecation list

Written down, with a mandatory twelve-month support window (SEP-2577):

  • Roots, Sampling, and Logging are deprecated as core features.
  • The legacy HTTP+SSE transport is deprecated.

The spec also introduces a formal deprecation policy, so future removals come with predictable timelines instead of surprise breakage.

SDK status

All four Tier 1 SDKs (TypeScript, Python, Go, C#) support 2026-07-28 today, with migration docs for the breaking changes. The Rust SDK supports it in beta.

What to actually do

  1. If you run MCP servers behind session-affinity hacks, plan the move to the stateless core. This is the payoff release.
  2. If your tools relied on server-initiated requests, port them to the input_required retry pattern.
  3. If you use Roots, Sampling, Logging, or HTTP+SSE, you have twelve months. Start now, not in month eleven.
  4. If you do OAuth, check the iss validation and CIMD guidance before your next security review.
  5. Set ttlMs on your list responses. Your clients’ context windows and your egress bill will both thank you.

The full changelog is in the official announcement1 and the spec itself2. The 2026 roadmap post3 explains where this is heading next.

¶ Fin.

Written by Herman Geldenhuys in Montreal.

Sources

  1. blog.modelcontextprotocol.io, largest revision since launch
  2. modelcontextprotocol.io, spec itself
  3. blog.modelcontextprotocol.io, 2026 roadmap post

Keep reading