Agentic AI Wiki
AI Blog / MCP 2026-07-28: Statelessness Was the Small Part
AI Blog

MCP 2026-07-28: Statelessness Was the Small Part

The 28 July specification retires the initialize handshake and the Mcp-Session-Id header, and every write-up so far has framed that as plumbing. It is not. Dropping the held-open connection forced Sampling, Roots and Logging onto a twelve-month deprecation clock — and those were the features that made an MCP client a peer rather than a caller. The protocol just settled what it is.

By Agentic AI Wiki 12 min read

Read the 28 July release notes and the headline is a transport change: MCP dropped the initialize handshake and the Mcp-Session-Id header, so any instance can answer any request. That is the enabling change, not the important one. Removing the held-open connection put Sampling, Roots and Logging on a twelve-month deprecation clock — the three features that made an MCP client a peer rather than a caller — and demoted Tasks to an extension. After eighteen months of ambiguity, the protocol has decided what it is: a tool-calling API for the web, not a bidirectional agent protocol.

What actually shipped

The 2026-07-28 revision was locked as a release candidate in May and validated for ten weeks by SDK maintainers and client implementers before publication — a long runway by this protocol's standards, and a reasonable signal of how much it moves.

ChangeWhat it meansWho notices
Stateless core initialize/initialized and Mcp-Session-Id retired; each request carries its protocol version, client identity and capabilities in _meta. Anyone running more than one server instance.
Multi Round-Trip Requests A tool needing mid-call input returns resultType: "input_required"; the client retries with inputResponses attached. Server authors who used server-initiated requests.
Header-based routing Mcp-Method and Mcp-Name headers, so gateways and WAFs route and meter without parsing the JSON body. Platform teams putting MCP behind existing infrastructure.
Cacheable list results ttlMs and cacheScope on tool, prompt and resource listings. Everyone, quietly and for free.
Authorization hardening Issuer (iss) returned per RFC 9207 and validated before code redemption; credentials bound to their issuer; Dynamic Client Registration deprecated for Client ID Metadata Documents. Anyone doing OAuth against a remote server.
Extensions framework Tasks left the core for io.modelcontextprotocol/tasks, poll-based, with tasks/update. Long-running-tool authors.
Deprecations Roots, Sampling and Logging deprecated with a twelve-month minimum window; legacy HTTP+SSE transport deprecated with a year's transition. Client authors, almost exclusively.

All four Tier 1 SDKs — TypeScript, Python, Go and C# — support the new revision at publication, with Rust in beta. That is a meaningfully different posture from earlier revisions, where the specification landed and the SDKs caught up over a quarter.

The stateless core, and what it is worth

MCP before and after the 2026-07-28 stateless core Before, an initialize handshake and an Mcp-Session-Id header pinned a client to one server instance, so a second instance could not serve the same conversation without a shared session store. After, every request carries its protocol version, client identity and capabilities in _meta and exposes Mcp-Method and Mcp-Name headers, so an ordinary HTTP router can send it to any instance and list results become cacheable. Before — stateful session Client initialize / initialized Mcp-Session-Id Sticky router must pin the session Instance A holds the session Instance B cannot serve it Shared session store After — 2026-07-28 stateless core Client no handshake _meta Mcp-Method Any HTTP router routes on headers Instance A any request, any time Instance B identically capable Edge cache ttlMs, cacheScope The server stopped being a session. It became a URL.
The server stopped being a session and became a URL — which is what makes ordinary web infrastructure work on it.

The operational payoff is immediate

A stateful MCP server behind a load balancer was a distributed-systems problem dressed as an integration. You needed sticky routing, or a shared session store, or both — and the failure mode was a redeploy silently breaking conversations mid-flight. Statelessness deletes that category. Instances become interchangeable, a rolling deploy stops being an event, and horizontal scaling stops requiring a design review. If you operate MCP servers at any scale, this release is a straightforward gift.

Two smaller changes compound it

Header-based routing matters more than it reads. Putting the method and tool name in Mcp-Method and Mcp-Name means an API gateway can rate-limit per tool, a WAF can block a dangerous method, and a router can shard by name — all without body inspection, which is exactly the layer at which enterprises already own policy. Cacheable list results are the same idea one level up: tools/list is issued constantly and changes rarely, so a ttlMs turns a per-conversation round trip into a CDN hit.

Mid-call input, without holding a connection

Multi Round-Trip Requests replace the server-initiated callback A tool call that needs mid-call input no longer holds a stream open. The server returns resultType input_required together with the questions it needs answered, the client resolves them however it likes, and the client retries the original call with inputResponses attached. Four ordinary request-response exchanges instead of one long-lived connection. One tool call, four independent request-response exchanges 1 Client calls tools/call no stream held open 2 Server answers input_required plus the questions 3 Client resolves ask the user, read a policy, use a default 4 Client retries inputResponses original call, answered Result served by any instance Every hop is idempotent, retryable, and free to land on a different server.
Four ordinary exchanges replace one long-lived connection — and every hop can land on a different instance.

Multi Round-Trip Requests are the mechanism that made the rest survivable. A tool that needs a confirmation or a missing parameter used to require the server to call back to the client mid-execution, which required the stream to stay open, which required the session. MRTR inverts the control flow: the server returns what it needs and stops, the client resolves it however it wants — asking a user, consulting a policy, filling a default — and re-sends the original call with the answers attached.

This is a better design for reasons beyond statelessness. The retry is idempotent, the pending question is a value you can persist rather than a callback you must keep alive, and an agent that goes away for ten minutes before answering costs the server nothing. It is also more work for client authors, who now own a state machine they previously got for free.

The deprecation list is the actual news

Sampling let a server ask the client to run a model completion on its behalf. Roots let a client tell a server which parts of its filesystem were in scope. Logging let a server stream structured log messages back. All three are now on a twelve-month clock, and all three depended on the connection being bidirectional and alive.

What those three had in common

They were the features that made an MCP client something other than an HTTP caller. Sampling in particular was the interesting one: a server that can request inference is a participant in the agent loop rather than a resource it reaches into. Losing it draws a hard line — the model stays entirely on the client's side, the server is a thing you call, and the interesting agent behaviour lives in exactly one place.

The honest reading

They also never got implemented widely. Sampling in particular was supported by a small minority of clients, which meant server authors could not rely on it, which meant fewer used it, which meant fewer clients bothered. Cutting features that the ecosystem declined to adopt is a healthier outcome than carrying them as a permanent asterisk — and a twelve-month window is a serious deprecation rather than a break. But it is worth naming what was decided rather than letting it read as housekeeping: the spec has given up on the client as a peer.

Tasks moving out is the same decision in a different register

Long-running work is now an extension — io.modelcontextprotocol/tasks, poll-based, with tasks/update — rather than a core concern. Polling is the right shape for a stateless protocol and the wrong shape for anything wanting push, which is consistent, and the extensions framework at least gives the pattern a defined home instead of leaving it experimental in the core.

The auth change nobody is writing about

Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents, and for enterprise deployments this is the line item with the longest tail. DCR let a client register itself with an authorization server at runtime, which was convenient and which security teams disliked precisely because of that convenience. CIMD replaces runtime registration with a document at a URL the client controls, so the authorization server resolves the client's identity rather than accepting a self-assertion.

Alongside it: authorization servers must return the issuer per RFC 9207, clients must validate that issuer before redeeming a code, and credentials bind to the issuer that produced them. Together these close mix-up attacks, in which a client is fooled into redeeming a code at the wrong authorization server. If you have an MCP integration in front of a compliance review, this is the paragraph worth quoting — see MCP auth & OAuth 2.1 for the shape of the flow this hardens.

What breaks, and who pays

Migration cost of the 2026-07-28 changes by deployment shape A four-by-five grid showing how much work each change creates for a local stdio server, a single-instance HTTP server, a load-balanced HTTP fleet, and a client or host application. The stateless core is close to free for stdio and a windfall for a fleet; the deprecation of Sampling, Roots and Logging lands almost entirely on client authors. Who pays for what Stateless core Tasks to an extension Sampling, Roots, Logging deprecated DCR out, CIMD in HTTP+SSE retired Local stdio server Barely affected Rarely used Drop it if you leaned on it No auth layer Not your transport Single HTTP server Delete the session bookkeeping Adopt the extension Twelve-month clock Publish client metadata docs One-year runway HTTP fleet The whole reason this shipped Polling suits you better anyway Rarely implemented Real work, and the security win Retire the legacy endpoint Client / host app Send identity on every request Poll, do not wait You lose the peer features Validate iss before redeeming Drop SSE support Where the change actually lands Some work Little or nothing to do
The cost lands unevenly — near zero for a local stdio server, a windfall for a fleet, and a genuine rewrite only where server-initiated calls were used.

If you run a local stdio server, most of this is not addressed to you: no session bookkeeping to delete, no auth layer, no transport to migrate. If you operate an HTTP fleet, the stateless core is the reason this revision exists and the CIMD migration is the real work. If you wrote a client, you inherit both the new per-request identity plumbing and the loss of the peer features — and you are the one who has to tell users that a server capability they relied on is going away.

The genuine rewrite is narrower than the noise suggests: it is servers that used server-initiated requests, which now need the MRTR pattern. Everything else is deletion, a config change, or a twelve-month calendar entry.

What to do this quarter

Pin the revision explicitly rather than negotiating whatever the SDK defaults to, because two revisions will be live across your dependencies for the next year. Grep your servers for Sampling, Roots and Logging and price the replacements now while the window is long. Start the CIMD work before the DCR path stops being accepted, since it touches an authorization server you probably do not own. And if you have been deferring a horizontally-scaled MCP deployment because sessions made it awkward, that reason has expired.

FAQ

Does the 2026-07-28 revision break my existing MCP server?

Not immediately. The legacy HTTP+SSE transport and the deprecated features carry deprecation windows of a year or more. What breaks now is only code that depended on protocol-level sessions — the initialize exchange and the Mcp-Session-Id header are gone from the new revision.

Why remove sessions at all?

Because a session forces every server instance to share state, which means sticky routing, a shared store, or both. Stateless requests can be answered by any instance behind ordinary HTTP infrastructure — load balancers, gateways, CDNs — which is what makes MCP scale like the rest of the web.

What replaces Sampling?

Nothing, by design. Inference moves entirely to the client side; a server that wants a model completion is expected to call a model itself rather than borrow the client's. You have a twelve-month minimum window to migrate.

Is Dynamic Client Registration gone today?

It is formally deprecated in favour of Client ID Metadata Documents, not removed. Treat it as a migration to plan this year rather than an outage to fix this week — but start early, because it usually involves an authorization server owned by another team.

Which SDKs support it?

All four Tier 1 SDKs — TypeScript, Python, Go and C# — shipped support with the specification, and the Rust SDK supports it in beta.

Further reading

On this wiki:

Sources: