Software

MCP went stateless. Your server still has state.

Thu Aug 06 2026 · 6 min read · 1 views

View as a Web Story

Software#ai agents#developer tools#mcp#model context protocol#api design#http

Illustration for a guide to migrating an MCP server to the stateless 2026-07-28 specification

The Model Context Protocol shipped a new revision on 28 July 2026. The headline everywhere is the same: MCP is stateless now. That part is true.

It is also the easiest part of the migration. The same revision drops the handshake, the session header, stream resumability, and the whole pattern of servers calling back to clients. If you run a server, sessions are not what will take your week.

Key Takeaways

  • The 2026-07-28 revision drops protocol-level sessions and the session header, so list endpoints no longer vary per connection.
  • The initialize handshake is gone. Every request now carries its own protocol version and client capabilities instead.
  • Sampling and elicitation callbacks give way to Multi Round-Trip Requests, and stream resumability is gone.

What the revision actually changes

Two changes carry the "stateless" headline.

The first drops sessions and the session header from the HTTP transport. List endpoints no longer vary per connection. A server that needs state across calls now mints a handle and passes it as a plain tool argument (SEP-2567).

The second drops the initialize handshake. Every request now carries its own version and client capabilities in a metadata field. A version mismatch returns an error instead (SEP-2575).

One new call arrives with it. server/discover is a call every server must add, and it advertises the versions, capabilities, and identity that server supports. Clients may call it first to pick a version, or use it as a probe for older setups.

Why the protocol wanted this

Statelessness means the transport keeps no memory between requests. Any machine can then serve any request.

The reason is plain web plumbing. A server built for thousands of staff sits behind a load balancer that sends each request wherever there is room. If the protocol assumes one machine recalls the chat, the balancer fights the protocol instead of helping it (Google's engineering write-up).

Two new headers make that routing cheap. Mcp-Method is the header that names the method being called, and Mcp-Name names the tool or resource. A gateway can now route, meter, or check a request without reading the body (SEP-2243).

That is a real win for anyone running agentic ai at scale, and it is why the change was worth making.

The sessions are the small part

Read past the first two entries and the shape of the work changes. Statelessness is a local refactor. The rest of the revision changes how a server talks to a client at all.

Server-initiated calls are gone. A server used to call back to the client mid-request to sample, elicit, or list roots. Now it returns a result that says input is required, and the client retries the first request with the answers attached. MRTR is the name for that pattern, short for Multi Round-Trip Requests (SEP-2322).

Stream resumability is gone too. Event IDs are removed, so a broken stream loses the request in flight. The client must send it again with a new ID.

The GET endpoint and the old subscribe calls give way to one long-lived stream. Clients opt in to the change types they care about.

Ping and the log-level call are simply gone. Log level now rides along with each request.

Removed or replaced What to use instead
Mcp-Session-Id and protocol sessions Server-minted handles passed as tool arguments
initialize / notifications/initialized Per-request _meta, plus server/discover
sampling/createMessage, elicitation/create, roots/list callbacks InputRequiredResult and a client retry (MRTR)
Last-EventID resumability Reissue the request with a new ID
HTTP GET endpoint, resources/subscribe subscriptions/listen
ping, logging/setLevel Removed; log level via _meta

Where your state actually goes

The protocol is stateless. Your application is not, and nobody claimed otherwise.

State that used to hide inside a session now has to live somewhere you picked on purpose. That might be Redis for task tracking, or a saved payload carried through a multi-step flow.

This is the same trade every web API made years ago. Stated plainly, it is more code and fewer mysteries. The bug to watch for in this migration is the server that keeps a map in memory keyed by client. It works fine on one machine and breaks the moment you run two.

Consider the elicitation case. There is no completion signal any more, because the client learns the outcome by retrying. A server that needs to match up an exchange across retries must store its own ID in the request state.

Deprecations worth reading before you build

Three features are now marked for removal: Roots, Sampling, and Logging (SEP-2577). They keep working for now, and the spec set a minimum window of twelve months.

The suggested swaps are simple. Pass folders as tool parameters instead of Roots. Call a model provider directly instead of Sampling. Log to standard error, or use OpenTelemetry, instead of Logging.

The old HTTP+SSE transport is marked for removal as well, and the old OAuth sign-up flow gives way to Client ID Metadata Documents. One developer security detail hides in those changes. Clients must file saved credentials by issuer, and sign up again when the auth server changes.

What to do this week

If you run a server, the order matters. Add the two new headers and the discover call first, because that work is mechanical.

Then find every place you leaned on session identity, and swap in a handle you mint yourself. Then hunt for server-initiated calls. Those need the MRTR rewrite, and they are the only change that alters your control flow.

Beta SDKs exist for Python, TypeScript, Go, and C#, and TypeScript ships codemods for the renames. The codemods will not do the MRTR work for you.

Frequently Asked Questions

Does stateless MCP mean my server cannot keep state?

No. It means the transport no longer keeps it for you. App state is still fine. It just has to be explicit, such as a handle you mint and hand back as a tool argument.

What replaced the initialize handshake?

Per-request metadata, plus the new discover call. Every request carries its own version and capabilities, and discover advertises what a server supports.

Is the Mcp-Session-Id header still allowed?

It is gone from the HTTP transport. List endpoints no longer vary per connection, which is what made session pinning needed in the first place.

What is the hardest part of this migration?

The MRTR rewrite. Sampling, elicitation, and roots callbacks all become a result plus a client retry, which changes control flow rather than just wire format.

Do I have to migrate immediately?

Not immediately. Features marked for removal carry a window of at least twelve months. Items such as sessions and the handshake are already gone in this revision.

The honest summary

Stateless MCP is a good change, and the load-balancer case for it is sound. It is also the friendliest headline available for a revision that cut far more than sessions.

Read the changelog rather than the coverage. The line that costs you a week is entry seven, not entry two.

FAQ

Does stateless MCP mean my server cannot keep state?

No. It means the transport no longer keeps it for you. App state is still fine. It just has to be explicit, such as a handle you mint and hand back as a tool argument.

What replaced the initialize handshake?

Per-request metadata, plus the new discover call. Every request carries its own version and capabilities, and discover advertises what a server supports.

Is the Mcp-Session-Id header still allowed?

It is gone from the HTTP transport. List endpoints no longer vary per connection, which is what made session pinning needed in the first place.

What is the hardest part of this migration?

The MRTR rewrite. Sampling, elicitation, and roots callbacks all become a result plus a client retry, which changes control flow rather than just wire format.

Do I have to migrate immediately?

Not immediately. Features marked for removal carry a window of at least twelve months. Items such as sessions and the handshake are already gone in this revision.

Comments

Loading…

Sign in to join the conversation.

Related posts

Abstract editorial graphic representing a Chrome browser security update accelerated by AI-driven vulnerability triage

Chrome Security Update AI: 1,072 Bugs, Then 1,442

In late July 2026, Google published a number that was supposed to reassure Chrome's roughly three billion users: across the Chrome 149 and 150 release cycles, its security team fixed 1,072

Sun Aug 02 2026 · 7 min read · 2 views

Software

We use cookies for ads and analytics.what this means.