MCP Goes Stateless: What the 2026-07-28 Spec Changes for Builders

On July 28, 2026, the Model Context Protocol shipped the biggest revision in its short history. The initialize handshake is gone. The Mcp-Session-Id header is gone. Every request now stands alone, and the protocol that began life as a chatty pipe between a desktop app and a subprocess has been rebuilt for fleets of stateless servers behind load balancers.

The 2026 MCP spec — formally the 2026-07-28 revision, announced on the official MCP blog — trades session plumbing for three big ideas: a stateless request/response core, Multi Round-Trip Requests (MRTR) for interactive flows, and HTTP headers that let gateways route MCP traffic without opening the JSON-RPC envelope. The tech press saw it coming. The week before release, TechCrunch previewed the changes under a headline calling MCP “AI’s most important protocol” that is “getting a little bit easier to use,” and The Register wrote that the protocol “prepares to break with its stateful past.”

This is the builder’s deep-dive. You get the reasoning behind statelessness, the full retired-and-deprecated list with its 12-month clock, an MRTR walkthrough, the auth upgrades, and a migration checklist for server authors and client users alike. If you want the protocol from first principles, start with our Model Context Protocol explainer — this piece assumes you have wired up a server or two.

Why the MCP spec had to break with sessions

When Anthropic open-sourced MCP in November 2024, the reference deployment was a desktop app spawning a subprocess and speaking JSON-RPC over stdio. One user, one machine, one process per server. In that world, session state was free. The server lived exactly as long as the conversation, and the initialize handshake — where client and server negotiated protocol versions and capabilities — cost nothing because you paid it once at spawn.

Then MCP won, and the growth story moved to remote servers behind HTTPS. That is where the stateful design started billing everyone. A protocol session that lives in one replica’s memory means your load balancer needs sticky routing, because a request landing on the wrong replica meets a server that has never heard of your Mcp-Session-Id. It means scale-to-zero is off the table: a server holding sessions cannot be a serverless function that vanishes between calls. It means zombie state, because a crashed client leaves its session in server memory until some timeout reaps it. And it means gateways stayed blind — an API gateway that wanted to route, rate-limit, or authorize MCP traffic had to parse JSON-RPC bodies to learn what a request was even doing.

Client-side, the pain showed up as reconnect misery. Restart your harness mid-session and the client had to re-handshake, re-negotiate capabilities, and re-list every server’s tools before the first useful request. Multiply that by the six or eight servers a working config accumulates, and by every client restart in a CI job, and you have the operational tax that AgentOps teams spent 2025 grumbling about.

The 2026-07-28 MCP spec’s answer is blunt: the protocol no longer has sessions. Whatever state an interaction needs now travels with the request.

Before, session state pinned every client to one replica. After, any replica can serve any request, and gateways route on headers.

What’s retired, what’s deprecated, and the 12-month clock

The revision sorts the old machinery into three buckets: retired outright, officially deprecated, and deprecated with a support window.

Feature	Status in the 2026-07-28 MCP spec	Where it goes
initialize handshake	Retired	Capability discovery via plain */list calls, now cacheable
Mcp-Session-Id header	Retired	State travels with requests (MRTR continuations, task handles)
Legacy HTTP+SSE transport	Officially deprecated	Streamable HTTP, single endpoint
Server-initiated elicitation and sampling	Replaced	Multi Round-Trip Requests (MRTR)
Roots	Deprecated, 12-month window	Client-supplied per-request context
Sampling capability	Deprecated, 12-month window	MRTR
Logging notifications	Deprecated, 12-month window	Server-side observability; task status for progress

Three details worth pinning down. First, the HTTP+SSE deprecation is a formality catching up with reality: Streamable HTTP superseded the old dual-endpoint transport back in the 2025-03-26 revision, and the 2026-07-28 release makes the funeral official. If you still operate an SSE-era endpoint, you are running a museum piece.

Second, the deprecations with a window — Roots, Sampling, and Logging — share a common ancestor: all three depended on a long-lived channel where servers could push things at clients. A stateless protocol has no such channel, so the primitives built on it go too. The window is 12 months from release, which puts the practical cutoff around late July 2027. Compliant SDKs will warn now and drop support then.

Third, “retired” is stronger than “deprecated.” New-revision clients simply never send initialize, and servers should not expect it. Discovery happens through tools/list, resources/list, and prompts/list — which, as we will get to, are now cacheable, so the retirement does not mean more chatter. It means less.

MRTR: interactive flows without a session

The hardest design problem in going stateless was interactivity. The old spec had two server-initiated flows: elicitation, where a server pauses mid-operation to ask the user something (“which environment?”), and sampling, where a server asks the client’s model for a completion. Both required the server to send a request back up a persistent connection. No connection, no callback.

Multi Round-Trip Requests (MRTR) are the 2026-07-28 revision’s replacement: instead of calling the client back, a server answers a tool call with an intermediate response that says what it still needs and includes an opaque continuation token. The client gathers the missing input and re-submits the request with the token attached, as many rounds as it takes.

Here is the shape of one interactive call under MRTR, walked end to end:

1. The model calls deploy_service with env: prod. The client POSTs a normal tools/call request.
2. The server decides this needs human sign-off. Instead of a final result, it returns an input_required response: a description of the question to ask, plus a continuation token encoding where it left off.
3. The harness surfaces the question to you, exactly as elicitation used to. You answer.
4. The client re-sends the tools/call — same tool, continuation token attached, your answer included.
5. The server resumes from the token, finishes the deployment, and returns a final complete result.

// Round trip 1 — client calls the tool
{ "method": "tools/call",
  "params": { "name": "deploy_service", "arguments": { "env": "prod" } } }

// Server needs input: intermediate response with continuation state
{ "result": { "status": "input_required",
    "request": { "type": "confirmation",
                 "message": "Deploy to prod during business hours?" },
    "continuation": "eyJzdGVwIjoyLCJwbGFuIjoi..." } }

// Round trip 2 — client re-submits with the answer attached
{ "method": "tools/call",
  "params": { "name": "deploy_service",
    "continuation": "eyJzdGVwIjoyLCJwbGFuIjoi...",
    "input": { "confirmed": true } } }

// Final response
{ "result": { "status": "complete",
    "content": [ { "type": "text", "text": "Deployed r2411 to prod." } ] } }

Field names simplified for clarity — treat the spec text as canonical.

Sampling-style needs work the same way inverted: the intermediate response describes the completion the server wants, the client runs it against its own model, and the follow-up request carries the output back. The model, the user, and the tokens all stay on the client side, where the harness — not the server — enforces permissions.

The property that makes operators happy: because the continuation token carries the state, the round trips do not have to hit the same machine. Replica A can serve round trip one and replica B round trip two. Retries, timeouts, and load balancing collapse into ordinary HTTP semantics. From the user’s chair nothing changes — the harness still pauses and asks — but the plumbing underneath went from a bespoke bidirectional channel to plain request/response.

One logical operation, two round trips. The continuation token — not the server — remembers where things stood.

For server authors, the honest cost is restructuring: handlers that used to block on a callback become resumable steps that serialize their progress into the continuation. The updated SDKs do the token mechanics; the decomposition into steps is on you.

Header routing and cacheable lists: the gateway dividend

Two smaller changes in the 2026 MCP spec will matter enormously to anyone running MCP through infrastructure rather than straight to a server.

The first is header routing. Requests now carry Mcp-Method and Mcp-Name HTTP headers mirroring what is inside the JSON-RPC envelope — the method being invoked and the tool, resource, or prompt it targets. That sounds cosmetic until you operate a gateway. With the metadata at the HTTP layer, a gateway can route tools/call and tools/list to different backends, apply per-tool rate limits, enforce method-level ACLs, and emit clean metrics — all without parsing a single body. Every trick your API gateway already does becomes available to MCP traffic.

The second is cacheable list results. Responses to the */list discovery calls can now carry a ttlMs value, and clients are expected to honor it: cache the tool list, skip the re-fetch, refresh when the TTL lapses. This kills the reconnect-and-relist tax that made client restarts expensive, and it means a thousand-seat deployment stops hammering servers with identical discovery calls every morning. It also produces a useful side effect nobody advertised: your cached tool list is a stable artifact you can snapshot and diff, which turns out to be handy for catching servers that quietly change their tool descriptions — more on that in our hardening guide.

Auth hardening: RFC 9207 and Client ID Metadata Documents

Remote MCP means OAuth, and the 2026-07-28 revision tightens two long-standing soft spots.

The first is issuer validation per RFC 9207. Authorization responses now carry an iss parameter identifying which authorization server actually answered, and MCP clients must validate it. This closes the classic mix-up attack, where a client talking to multiple authorization servers can be tricked into delivering an authorization code to the wrong one. Small change, real attack class, overdue.

The second is bigger: Client ID Metadata Documents (CIMD) replace Dynamic Client Registration. Under DCR, every client had to register itself with every server it met — a registration dance that scaled badly and produced piles of weak, unverifiable client identities. Under CIMD, the client’s ID is an HTTPS URL pointing at a hosted metadata document describing the client — its name, redirect URIs, keys. Servers fetch and cache it. Identity gets anchored to a domain that can be verified, allowlisted, and revoked, instead of to whatever a registration endpoint was told at 2 a.m.

The timing is not accidental. The revision landed weeks after the US government published a dedicated Cybersecurity Information Sheet on MCP security in June 2026, and auth was among the protocol’s most-criticized surfaces in security reviews all year — the same surfaces we cataloged in our guide to securing AI agents.

Know the limits, though. These upgrades answer who is this client and which server issued this token. They say nothing about whether a well-authenticated server’s content deserves the model’s trust. Tool poisoning, rug pulls, and injection through resources are untouched by OAuth — that defense lives in your deployment practices, and we map it to the government guidance in our production MCP hardening guide.

Tasks, formalized

Long-running work got a proper home. The tasks extension — floated on the project’s roadmap through late 2025 and tracked on the official development roadmap — is formalized in the 2026-07-28 revision. The shape is what you would hope: a client starts a task, receives a durable handle, polls for status, and fetches results whenever they are ready, with cancellation along the way.

Tasks are the answer to the obvious objection to statelessness — “my server runs 40-minute jobs.” It still can. The job’s identity lives in a task handle the client holds, not in a session the server babysits, so the server fleet behind the endpoint can scale, restart, and reshuffle while the task runs. Tasks also absorb a chunk of what Logging notifications used to do: progress reporting attaches to the task, not to a push channel.

Migrating to the 2026-07-28 MCP spec

The updated SDKs shipped alongside the revision — TypeScript, Python, Go, and C#, with Rust in beta — and they do most of the mechanical lifting. The checklist depends on which side of the protocol you live on.

If you author servers

1. Bump the SDK and run your test suite. A simple stateless tool server — most of them — migrates with little more than this.
2. Delete session assumptions. Anything keyed on Mcp-Session-Id or stashed in per-connection memory must move into request payloads, continuation tokens, or external storage.
3. Restructure interactive flows as MRTR. Every elicitation or sampling callback becomes a resumable step returning an intermediate response.
4. Move long jobs to tasks. If a tool call can outlive an HTTP timeout, it should return a task handle.
5. Set ttlMs on list results. Even a conservative TTL takes real load off discovery endpoints.
6. Adopt the auth upgrades: issuer validation on your authorization flows, CIMD acceptance instead of DCR.
7. Retire legacy HTTP+SSE endpoints on an announced schedule; they are now officially deprecated.
8. Plan the off-ramp for Roots, Sampling, and Logging before the window closes in mid-2027.

If you run clients

Client users have less to do, but not nothing. Inventory which of your tools speak MCP — for most power users that is several entries in the agent harness field map, plus a desktop app or two from the best agentic AI tools roster. Update each client as post-revision releases land, then re-test the servers you actually depend on. Expect deprecation warnings from servers still using Sampling or Logging, and treat a server that never migrates as a signal about its maintenance. Old servers keep working through the transition; abandoned ones will announce themselves by mid-2027.

Product note: Migration season means touching every client you run — and if you drive Claude Code, Codex, OpenCode, and Antigravity side by side, that is four config stores, four update cycles, and a pile of provider accounts. Automater Lite’s Toolbelt keeps the sprawl coherent: provider account management (OAuth and API keys) in one place, cross-CLI skills sync, and a batch tool updater so every harness lands on post-revision builds. Free on automater.ai.

Adoption, SDKs, and what stays the same

This revision did not ship into a vacuum. The launch post lists adopters including Amazon Bedrock AgentCore, Anthropic, AWS, Cloudflare, Figma, Google Cloud, Microsoft Foundry, Netlify, Supabase, and Xero — the strongest signal yet that MCP’s stewards can move the spec without fracturing the ecosystem. When the platforms terminating most of the world’s MCP traffic adopt a breaking revision in step, the network effects work for the migration instead of against it.

Just as important is what did not change. The wire format is still JSON-RPC 2.0. The three primitives — tools, resources, prompts — are intact, schemas and descriptions included. stdio remains the right transport for local, single-user servers, where the subprocess pipe never had the scaling problem the revision solves. Streamable HTTP remains the remote transport; it just carries self-contained requests now. If you learned MCP from our explainer, your mental model of hosts, clients, and servers survives — the revision changed how state moves, not what the protocol is for.

As of August 2026, the builder’s read is straightforward. TechCrunch’s framing — “a little bit easier to use” — is accurate for client users and undersells it for operators, who just watched session affinity, zombie state, and blind gateways leave the protocol in one release. The work this quarter: bump SDKs, restructure anything interactive around MRTR, and put a calendar reminder on the 12-month clock. The protocol grew up; the least you can do is update.

FAQ: the 2026 MCP spec

What changed in the 2026-07-28 MCP spec?

The revision makes MCP stateless: the initialize handshake and Mcp-Session-Id header are retired, Multi Round-Trip Requests (MRTR) replace server-initiated elicitation and sampling, Mcp-Method and Mcp-Name headers enable gateway routing, list results become cacheable via ttlMs, and OAuth gains RFC 9207 issuer validation plus Client ID Metadata Documents.

Do MCP servers still use sessions?

No. The 2026-07-28 revision removes protocol-level sessions entirely, so servers hold no per-client state between requests. Interactive flows carry their own state through MRTR continuation tokens, and long-running work moves to the tasks extension. Local stdio servers still run as persistent processes, but the protocol no longer negotiates sessions over them.

What are Multi Round-Trip Requests (MRTR)?

MRTR is the 2026 MCP spec’s replacement for server-initiated elicitation and sampling. Instead of calling the client back over a persistent channel, a server returns an intermediate response describing what it needs plus a continuation token; the client gathers the input and re-submits. State travels in the payload, not the server.

When do Roots, Sampling, and Logging stop working?

They are deprecated with a 12-month support window from the July 28, 2026 release, so expect compliant clients and SDKs to drop them around late July 2027. Migrate sampling-style flows to MRTR now, and read continued reliance on deprecated primitives as a maintenance red flag for any server you depend on.

Do I need to migrate my MCP server immediately?

No, but start now. Legacy HTTP+SSE is officially deprecated, and the deprecated primitives get 12 months. A stateless tool server usually migrates with an SDK upgrade; interactive servers need real MRTR rework. Servers that never migrate will read as abandoned once the window closes in mid-2027.

Sources

• MCP specification release, 2026-07-28 — blog.modelcontextprotocol.io
• MCP roadmap — blog.modelcontextprotocol.io
• Model Context Protocol development roadmap — modelcontextprotocol.io
• TechCrunch: AI’s most important protocol is getting a little bit easier to use (July 20, 2026)
• The Register: Model Context Protocol prepares to break with its stateful past (July 23, 2026)
• Model Context Protocol specification and documentation — modelcontextprotocol.io
• US government Cybersecurity Information Sheet: MCP security (June 2026, PDF)