Stateless MCP: What the 2026-07-28 Spec Breaks in Your Agents

Last Updated: September 21, 2026

The largest revision to the Model Context Protocol since launch shipped on 28 July 2026 under Agentic AI Foundation stewardship, and the thing people keep getting wrong about it is the blast radius. The wire format changed substantially. Your deployment mostly did not. All four Tier 1 SDKs — TypeScript, Python, Go, C# — shipped on launch day with down-level protocol support in both directions, which means a v2 client can drive a 2025-era server and a v2 server still answers the legacy handshake.

So the question is not "will it break". It is "what did I build on top of the session that the protocol no longer provides, and what does it cost to move that into my application layer". The gap between the cheapest and most expensive answer is roughly an order of magnitude.

What the spec actually deleted

Two SEPs carry almost all of the migration cost. SEP-2575 retired the initialize/initialized exchange and SEP-2567 retired the Mcp-Session-Id header. Protocol version, client identity and client capabilities now ride in _meta on every single request. If a client wants capabilities up front there is a new optional server/discover RPC, but it is a MAY, not a MUST, for clients.

Everything else in the release follows from that deletion. Method and tool names were promoted into the Mcp-Method and Mcp-Name HTTP headers (SEP-2243) so gateways can route and rate-limit without parsing bodies — and if the headers disagree with the JSON-RPC body, the server rejects the request with a -32020 header mismatch code rather than guessing. List responses from tools/list, prompts/list, resources/list and resources/read now carry ttlMs and cacheScope (SEP-2549), so clients can cache catalogs instead of holding an SSE connection open to watch for changes.

The clever bit is Multi Round-Trip Requests (SEP-2322). Server-initiated elicitation and sampling used to require a held-open bidirectional stream, which is precisely what you cannot have in a stateless world. Under MRTR the server returns resultType: "input_required" with an opaque requestState payload, the client gathers the answer and re-issues the original call with inputResponses attached. Any instance can pick up the retry. Supabase, which already ran statelessly and therefore could never support elicitation, cited MRTR as what unblocks confirmation prompts before destructive queries.

And there is a deprecation list: roots, sampling and logging are deprecated under SEP-2577, as is the legacy HTTP+SSE transport, all with a minimum twelve-month offramp. One smaller change bites clients that pattern-match on error codes: a missing resource now returns JSON-RPC -32602 instead of the MCP-custom -32002. That one is a five-minute fix and a four-hour outage if you find it in production.

Four patterns, four verdicts

Here is the grading that matters. These are the architectures teams actually shipped in 2025 and early 2026, and the honest verdict on each.

The sticky-session gateway is the happy case and it is also the most common one. If all you did was configure affinity at the load balancer and run a shared Redis session store, the revision is pure subtraction. GitHub upgraded its MCP server before the spec formally shipped and described exactly three changes: it removed Redis sessions (a database write on every initialize, a read on every call), stopped doing deep packet inspection because the values it needs for logging and secret scanning now arrive in guaranteed headers, and reworked URL elicitation so each step is a separate HTTP request. Cloudflare's servers now run each request on a fresh stateless instance with no protocol session and no protocol-specific Durable Object.

The session-pinned tool server is where most in-house builds land. The fix is not conceptually hard — mint an explicit handle from a tool (basketId, browserId) and let the model pass it back as an ordinary argument — and the maintainers argue this beats hidden transport state because the model can see the handle and compose it across tools. True, and also a prompt-engineering problem you did not have before. Models drop handles, invent handles, and pass last turn's handle after the object expired. Validate every handle server-side and return an error string that tells the model to re-fetch, because "invalid basketId" with no recovery hint sends an agent into a retry loop.

The long-lived streaming connection is the genuine rewrite. Your handler stops being a coroutine that awaits a user answer and becomes a state machine that resumes from a token. The TypeScript SDK docs are blunt about the consequence: inputResponses are per round and never accumulate, so a multi-step flow has to thread everything it has learned through requestState as a discriminated union of phases. If you have a five-step approval wizard, you are writing a five-state machine.

Statelessness is a scaling win, not a reliability win

This is the counter-position worth stating plainly, because a lot of the launch coverage blurred it. The stateless core solves an infrastructure problem: sticky routing, shared session stores, the 400 Session Not Found you get when a second request lands on a different pod, and the total loss of session state when a pod restarts. Google's engineering write-up lists exactly those four as the production bottlenecks that motivated the push to decouple the protocol from stateful transports. All real. All fixed.

None of them were why your agent picked the wrong tool. If your complaints are about tool selection degrading as the catalog grows, hallucinated arguments, multi-step plans losing the thread, or two agents racing on the same record, migrating to a stateless protocol changes nothing. That coordination problem lives above the transport. The new model arguably makes it more visible: state that used to hide in the transport now sits in tool arguments the model has to manage correctly.

The maintainers themselves flagged the actual reliability frontier in the roadmap published on 22 August 2026 — standardising the tool-result contract so a server author knows which form of output a client will show the model, and a progressive discovery effort so a server with a hundred tools does not force the model to pay for the entire surface before the user has asked anything. Those are the agent-reliability items. They are next, not now. If you want a broader read on where the coordination layer sits, our research notes and model coverage pages cover it separately.

It is a leap in serving scalable MCP servers.

— David Soria Parra, MCP Co-Inventor, Model Context Protocol

The auth hardening you cannot defer

Everything above can be sequenced. This part cannot, because it closes a class of issue rather than adding a feature.

The 2026-07-28 authorization text makes token audience binding normative. MCP clients MUST include the resource parameter per RFC 8707, MCP servers MUST validate that tokens presented to them were issued specifically for their use, and an MCP server calling an upstream API MUST NOT pass through the token it received from the MCP client — the upstream call needs a separate token from the upstream authorization server. Token passthrough is explicitly forbidden, not discouraged.

If you built an MCP server that fronts an internal API and forwards the caller's bearer token, that is the pattern being closed. It is also the pattern that shows up constantly in gateway builds, because it is the shortest path to "the tool works". The fix is a token exchange at the boundary and audience validation on the way in, and it takes longer than anyone budgets.

Two more that are cheaper but still mandatory for conformance. Authorization servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code (SEP-2468), closing an authorization-server mix-up hole; client credentials are now bound to the issuer that minted them (SEP-2352); and Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents. DCR keeps working for now. It will not keep working forever.

Note the sequencing trap: in the TypeScript SDK these auth requirements are implemented as SDK-level opt-ins rather than protocol-era gates, which means they apply on every era once enabled and, conversely, upgrading your wire format does not turn them on for you. Conformance is a checklist you tick, not a side effect of migrating.

A 30/60/90 sequence that does not require a flag day

Nothing forces a cutover. The spec's twelve-month deprecation floor and the SDKs' bidirectional down-level support mean you can run both eras from one endpoint for as long as your client population needs. That is the whole point of the compatibility window — use it.

Two notes from the SDK docs that are easy to miss. If you enable client-side 'auto' version negotiation, the probe costs an extra round trip against 2025-only servers, and an HTTP 401 or 403 on the probe is never treated as era evidence — it rejects with a typed auth failure instead of falling back, so gateways that answer 403 before authenticating will look like a negotiation bug. And on a 2026-era request, handler logs are suppressed unless the client opts in via the logLevel _meta key; absence means opt-out, not "no filter". Expect your first stateless deployment to look suspiciously quiet.

When to defer — and the one case where you should not

Defer if you run a single-tenant internal MCP server on one pod, your clients are all under your control, and your traffic does not justify horizontal scale. The stateless core buys you round-robin routing, serverless scale-to-zero and transparent failover. If none of those are constraints you currently have, you are paying migration cost for a benefit you will not observe. Do the auth work, pin your SDK, and revisit in two quarters.

Do not defer if any of the following is true: you run MCP servers behind a multi-instance load balancer and have been papering over it with sticky sessions; you forward client tokens to upstream APIs; you publish a public MCP server whose client population you do not control; or you are about to build a new server, in which case building it stateless is strictly cheaper than retrofitting. For new gateway and tool-server builds, stateless-first is now the obvious default — it is how we scope automation builds and integration engagements that involve MCP at all.

The ecosystem signal is unambiguous. Infrastructure providers shipped production implementations within days rather than months, AAIF launched the first official MCP Associate certification on 14 September 2026 aligned to this revision, and the roadmap's next priorities — DPoP, workload identity federation, agent identity and delegation — all assume the stateless core as baseline. Building new MCP surface against 2025-era assumptions now is choosing to migrate later at a higher price. For a second opinion on sequencing across your fleet, start here.