Field notes · No. 035

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.

Herman Geldenhuys August 10, 2026 4 min read
Poster for “MCP Goes Stateless: What's Actually in the 2026-07-28 Spec”

On July 28, the Model Context Protocol shipped its largest revision since launch. 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 announcement and the spec itself. The 2026 roadmap post explains where this is heading next.

¶ Fin.

Herman Geldenhuys is an engineering leader who writes from Montreal, Quebec, about the un-heroic side of leading teams through the AI moment.

Sources & further reading

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

Also on the bill