How the stateless core actually works

So how does the new spec untie the knot? Three moves.

The handshake is gone

The initialize and notifications/initialized opening ritual has been deleted outright, and the Mcp-Session-Id HTTP header went with it. Everything the handshake used to exchange — protocol version, who the client is, what the client supports — now rides along with each request inside the _meta field. Servers, for their part, are encouraged to report their own identity in the _meta of every result they return.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

There's a new way to ask a server what it can do

A new server/discover method reports which protocol versions a server supports, what its capabilities are, and who it is. Note the asymmetry: servers must implement it, clients don't have to use it. A client can query it before doing anything else, or skip it and fire off a request — both are perfectly legal. That's a real break from the old initialize, which was a mandatory opening ritual. This is just an ordinary query.

The spec says it flatly: a connection is not a session

Worth noting: a long-lived connection like subscriptions/listen doesn't break statelessness either. It's still an ordinary request/response — the "response" just happens to be a notification stream that stays open. Its state belongs to that request, not to the connection underneath.

The key point: state didn't vanish, it moved into the open

Here's where people get it wrong. No sessions at the protocol layer doesn't mean your application has to be stateless.

If your server genuinely needs to remember things across calls, the official approach is to emit an explicit handle from a tool and let the model pass it back as an ordinary parameter on later calls.

The launch blog's argument is that this beats session state buried in the transport, precisely because the model can see it:

We've found this works better than hiding session state in the transport layer — the model can see the handle and thread it between tools itself.

Official MCP launch blog, 2026-07-28

There's a trade here worth naming. State management didn't go away; it moved from "the transport quietly handles it for you" to "you handle it explicitly in your application." You get transparency, debuggability, and horizontal scaling. You also get the bill.

MRTR: asking the user something now takes two round trips

If a server can no longer speak first, how does it ask the user a question mid-flight?

Picture the situation. A tool is halfway through and needs the user to confirm something: Supabase's MCP server is about to create a new project and needs to ask "this will incur charges — confirm?", or a SQL statement will delete data and needs a nod first.

The old way was for the server to send a request backwards down that always-open bidirectional stream — to ask a question (elicitation/create), borrow the client's model for a quick inference (sampling/createMessage), or ask where the file directories are (roots/list). All of it assumed the stream stayed open, and that stream is exactly what going stateless tears out.

The new way is MRTR (Multi Round-Trip Requests). Instead of sending a request, the server returns an unfinished result with its question packed inside; the client asks the user and resends the original request with the answer attached. Click through the five steps below:

Supabase's product lead says the pattern unlocked something they'd wanted for a while:

Asking the user has been on our roadmap for a while, but it was awkward because the Supabase MCP runs stateless. MRTR changes that. Our tools can now check with the user before acting — the cost of creating a project, say, or a query that will delete data.

Inian Parameshwaran, product lead, Supabase

Two costs

First, the whole original request gets resent. The server may have to redo the earlier work, unless it encodes its intermediate results into requestState too.

Second, requestState is a live grenade. It passes through the client's hands before coming back, and the spec is unusually firm about it:

The shared store the server no longer needs has become the cryptographic signing it now has to get right.

MRTR also has a limited scope: it works only on prompts/get, resources/read, and tools/call. On any other request, a server must not return input_required.

Gateways can finally read MCP (plus a security rule the launch blog skipped)

State is handled. That leaves the older problem: the gateways in between never knew what you were calling.

The new spec adds required HTTP headers to every POST. Mcp-Method rides on every request and names the method being called. Mcp-Name shows up only when a specific target is named — on tools/call, resources/read, and prompts/get — and identifies which tool, resource, or prompt. Together with the always-required MCP-Protocol-Version, those few lines are all a gateway, rate limiter, or firewall needs.

It sounds like pure convenience, but it comes with a hard validation rule the launch blog doesn't mention:

There's a companion feature called x-mcp-header: a server can mark a tool parameter as "mirror this into an HTTP header," named Mcp-Param-{name}, which makes routing by tenant and similar dimensions easy. It's optional for servers but mandatory for clients. Remember it — it comes back in the security section.

Tool lists are finally cacheable (and upstream prompt caches survive)

Statelessness brings one convenient side effect: list results no longer vary by connection, so they can be cached.

Results from five methods — tools/list, prompts/list, resources/list, resources/read, and resources/templates/list — must now carry two fields:

There's a lower-tier requirement that's worth far more money: servers should return tool lists in a deterministic order.

That one needs unpacking. The tool list gets spliced into the model's prompt, and prompt caching matches from the beginning, character by character. Change one character at the front and the entire cache behind it is invalidated and rebilled. If your tool list comes back in a different order each time, the upstream cache never hits.

A small "keep the order stable" rule, real money saved.

What got deleted, and what got a stay of execution

This is the part to check yourself against: which of your things will break. The changelog has 9 major changes, 12 minor ones, and 4 deprecations. The two lists below are the ones to watch.

Error codes moved too

Resource-not-found changed from -32002 to the standard -32602 (invalid params), aligning with the JSON-RPC spec. Three new codes were renumbered: -32020 header/body mismatch, -32021 missing required capability, -32022 unsupported protocol version. The spec also drew a boundary: -32000 through -32019 is a legacy zone that implementations claimed for themselves before there was a policy, so no new codes may be assigned there and new implementations shouldn't use them; -32020 through -32099 is reserved for the spec.

If your client code hardcodes -32002, this one's on you — but don't overcorrect. The spec also requires clients to keep accepting -32002 from older servers; you just stop sending it yourself.

The deprecation policy is itself new here

Deprecation used to run on unwritten understanding. Now it's in writing: three feature states and one minimum window.

The 12 months runs from the release of the revision that marked the feature deprecated, not from when the proposal was finalized. Two things come with it. There's a single "pending removal" page, so you don't have to piece the picture together from old changelogs. And first-tier SDKs are required to surface deprecations idiomatically in their next release — TypeScript's @deprecated, C#'s [Obsolete], Java's @Deprecated, Go's Deprecated: comments — with a downgrade process for SDKs that don't.

Extensions became an official channel

With the core slimmed down, where do new capabilities go?

Adding anything to MCP used to mean stuffing it into the core protocol — Tasks lived there as an "experimental feature." This revision establishes a formal extension framework: the core stays lean, new capabilities ship as extensions, and clients and servers declare which extensions they support in their capabilities.

Tasks was contributed by AWS and is one of the first official extensions; AWS says the new spec and its stateless core are already available in Amazon Bedrock AgentCore. The mechanism deserves a closer look. When a server decides a request will run long, it returns a task ID instead of a final result, and that ID is a durable handle — the client can disconnect, restart, and keep polling with the same ID. Tasks have five states:

The three dark ones are terminal — once reached, they don't change. If the task needs to ask the user something, it moves to input_required and the client answers with the new tasks/update. No second connection, no server-initiated messages.

Four places where authorization got tighter

Deletions and additions covered. One more area the spec singles out: over the past year, implementers spent more time on authorization than anything else. Four things changed.

If you've ever wondered why your CLI client's OAuth flow throws a redirect_uri error, this is probably why.

Official MCP launch blog, on the application_type change

Third-party security analysis: the burden shifts to developers

All of the above is the official account. Before the spec formally shipped, a third party studied the new design as an attack surface: Akamai published an analysis in June, and SecurityWeek reported its conclusions.

Their read: the new spec genuinely removes several classes of vulnerability, while opening a few new attack surfaces — ones that depend heavily on how developers implement them.

With the protocol moving to a stateless model and introducing rich UI applications and asynchronous tasks, the critical security boundaries now depend entirely on how developers implement them.

Maxim Zavodchik, senior director of threat research, Akamai, via SecurityWeek

Their bottom line is that these changes amount to more than incremental improvement. The revision fundamentally reshapes where security responsibility lands: decisions the protocol used to enforce are increasingly handed to MCP server developers and platform operators.

The report adds an equally important qualifier: the MCP protocol itself has not become more fragile. What grew is the attack surface of the MCP servers built on the new spec.

So do I need to act now

After all those breaking changes, the practical question. The answer runs opposite to the "biggest breaking update ever" impression.

There are three concrete compatibility paths.

One, new clients yield to old servers automatically. A client speaking 2026-07-28 that meets a server capable only of 2025-11-25 or older falls back to the original initialize handshake, and the two keep talking. Going the other way, an old server that receives a request with no protocol-version header can treat it as 2025-03-26.

Two, major SDK versions are a separate matter. Python and TypeScript both shipped v2, each a breaking major release, and when you upgrade is your call — nothing to do with July 28. The TypeScript SDK's v1.x will keep getting bug and security fixes for at least 6 months after v2 goes final, and Python's v1.x branch continues receiving critical bug fixes and security patches.

Three, upgrading the SDK doesn't necessarily change what you say on the wire — and the four SDKs behave differently, which is easy to trip over:

All four first-tier SDKs (TypeScript, Python, Go, C#) supported the new spec on day one; the Rust SDK has beta support. What actually needs work falls into the categories below — run down the list:

The new spec deleted the opening handshake and the session ID together. Every request now carries its own protocol version, client identity, and supported capabilities, and the server forgets everything once it's done. The load balancer (the dispatcher that hands requests out across machines) no longer has to remember who belongs where — round-robin works.

No sessions at the protocol layer, but your application can still remember things — the bookkeeping just moved. The server emits a handle from a tool, in the open, and the model passes it back as an ordinary parameter on the next call.

State management didn't go away. It moved from "the transport quietly handles it for you" to "you handle it explicitly in your application."

Servers can't speak first anymore, so how do they ask the user something mid-flight? The new spec's answer is MRTR (Multi Round-Trip Requests): the server returns a half-finished "I'm missing something" result, the client asks the user, and the whole original request gets resent with the answer attached.

Two costs. The whole original request gets resent, so the server may redo earlier work. And the handle passes through the client's hands before returning, which is why the spec classifies it as input an attacker can freely modify: anything touching authorization or permissions must carry a signature nobody can forge, and anything that fails verification gets rejected. The shared store you saved becomes cryptographic signing you have to get right.

The change list runs to 9 major items, 12 minor ones, and 4 deprecations. These two lists are the ones to check yourself against.