Is MCP Stateless Now? What to Change in Your Own MCP Server

Yes. MCP is stateless at the protocol layer as of specification version 2026-07-28. The initialize handshake and Mcp-Session-Id are gone. Each request now carries the protocol version, client identity and capabilities it needs. A remote request can reach any healthy server instance without sticky routing.

That answer needs one qualification: stateless MCP does not mean stateless software. Your shopping basket, browser job, approval flow or paid order may still need durable state. The difference is that this state must be explicit, addressable and secured by your application instead of hiding inside an MCP transport session.

This guide owns the transport and migration question. For permissions and tenant isolation, use our separate enterprise MCP authorization architecture. For the deeper question of where protection must be enforced, read why MCP is not the complete security boundary.

What is the direct answer?

MCP 2026-07-28 is a stateless, self-contained request protocol. Protocol state is gone. Application state is still allowed and often necessary.

The official specification now lists “stateless, self-contained requests” and “per-request capability negotiation” as base protocol properties. On Streamable HTTP, every message is a new POST. The response is either one JSON object or a request-scoped SSE stream. The old standalone GET stream, protocol session, Mcp-Session-Id and resumable SSE mechanism are not part of this revision.

What changed in MCP 2026-07-28?

The official 2026-07-28 changelog is the best source for the complete breaking-change list. It also records the new resultType field, the end of stream resumability, JSON Schema 2020-12 support, new error codes and the deprecation of Roots, Sampling, Logging and the old HTTP+SSE transport.

Does stateless MCP mean the server cannot remember anything?

No. It means a later request cannot depend on invisible protocol-session memory.

Suppose a tool opens a browser and a later tool continues the same automation. The first response can return a random, opaque browser_id. The client passes that handle to the next call. The server resolves it in a Durable Object, database or another appropriate store after checking the caller and expiry. The workflow is stateful, but the MCP request is self-contained.

Choose the state mechanism by lifecycle:

• One request: keep state in local variables and return the final result.
• Several immediate round trips: return integrity-protected requestState with input_required. Bind it to the authenticated subject, original operation and expiry.
• Long-running work: use the MCP Tasks extension and a durable taskId.
• Business entities: return an application handle such as order_id, basket_id or document_id, then authorize every later use.
• Live change notifications: use subscriptions/listen. The open SSE response is request-scoped, not a revived protocol session.

Do not put secrets or writable business state into a readable bearer handle. Prefer an opaque identifier or an authenticated, encrypted state token with strict size, audience and expiry limits.

Do all MCP servers need a migration?

Every implementation should be audited, but the work differs.

A server can be operationally stateless and still speak a legacy protocol. Conversely, a server can speak the new stateless protocol while storing durable application state. Audit the wire behavior and the data lifecycle separately.

What should you change in your own MCP server?

1. Inventory hidden connection state. Search for session maps, sticky cookies, Mcp-Session-Id, transport objects reused across requests, per-connection tool lists and resumable SSE event stores. Classify each item as protocol state, transient request state or durable business state.
2. Implement modern version discovery. Servers must support server/discover. Return supported versions, capabilities, server info, instructions, ttlMs and cacheScope. Do not use self-reported server info as a security decision.
3. Validate per-request metadata. Require the protocol version and client metadata in _meta. On HTTP, require MCP-Protocol-Version and Mcp-Method, plus Mcp-Name for named calls. Reject header and body mismatches with HeaderMismatch instead of trusting whichever layer is more convenient.
4. Make results modern and cacheable. Add resultType: "complete" to ordinary results. Keep tools/list ordering deterministic. Set truthful ttlMs and cacheScope, especially when authorization changes the visible tool set.
5. Replace implicit state with explicit handles. Make handles unguessable, subject-bound, scoped and revocable. Make mutations idempotent. A retry after a broken stream must not charge, send or delete twice.
6. Support both eras deliberately. A dual-era server can serve modern requests statelessly and still answer legacy initialize traffic. Keep the compatibility path isolated, measured and covered by an expiry plan.
7. Test the architecture, not only the handler. Send consecutive calls to different instances behind real round-robin routing. Test missing and mismatched headers, unsupported versions, expired handles, replayed mutations, cancelled streams, retries and cross-tenant access.

The Streamable HTTP specification defines the required request headers and mismatch behavior. The versioning and compatibility matrix is essential before choosing a hard cutover or dual-era rollout.

What did we change in Wavect's own MCP Worker?

We applied the same checklist to our Cloudflare Pages Function on 31 July 2026, then completed a direct cutover because we did not need to preserve legacy clients.

• Stateless in process and protocol: the handler keeps no in-memory session map and now accepts only self-contained 2026-07-28 requests.
• Durable business state is already explicit: commerce tools use quote IDs, order IDs, access tokens and idempotency keys instead of transport-session memory.
• Modern discovery is live: server/discover reports the supported version, capabilities, server info, instructions and cache metadata.
• The HTTP contract is enforced: requests require MCP-Protocol-Version, Mcp-Method, and Mcp-Name for tool calls, with header-body parity checks and explicit origin validation.
• Results use the 2026 shape: discovery, list and call results include resultType; deterministic list results also include truthful cache metadata.
• The legacy lifecycle is gone: initialize, ping and notifications/initialized return method-not-found responses instead of silently keeping an old contract alive.

This is why “we do not store MCP sessions” is not a sufficient migration check. Runtime topology, protocol version and response schema can be at different maturity levels. For our server, the business-state redesign was small. The wire contract, security checks and conformance suite were the real work.

"Stateless MCP removes hidden transport memory. It does not remove durable workflows. Make state explicit, authenticated and safe to retry."

How should a production rollout work?

1. Record current client versions, transports, session features and error rates.
2. Add conformance tests for the modern request and result shapes before changing production traffic.
3. Deploy a dual-era endpoint or a separate modern endpoint, depending on how tightly you control clients.
4. Route internal and canary clients to the modern path. Exercise different server instances on consecutive calls.
5. Observe unsupported-version errors, header mismatches, retries, latency, duplicate side effects and authorization failures.
6. Publish a client migration date and a rollback window. Do not delete legacy storage because one SDK test passed.
7. Remove sticky routing and session stores only after telemetry shows that legacy traffic and session-dependent features are gone.

Cloudflare now documents a stateless handler path and a staged migration for sessionful features in its MCP SDK v2 migration guide. Even if you use another runtime, the separation between protocol state and application state is a useful design model.

What should you ask an MCP development partner?

• Which protocol versions and client eras will the deployed server support?
• Which state is request-local, which is durable and which is still tied to a transport session?
• How are state handles bound to identity, tenant, operation and expiry?
• How are retries made idempotent for payments, writes and external side effects?
• Can the team prove two consecutive calls work on different server instances?
• How are required HTTP headers validated against the JSON body at the origin and gateway?
• What is cached, for how long, and can private tool lists reach a shared cache?
• Which deprecated features remain, and what is the replacement plan?
• What evidence closes the legacy path: telemetry, client inventory, rollback test and removal date?

If a proposal says only “upgrade the SDK,” it is incomplete. The commercial deliverable should include a state inventory, compatibility decision, threat model, migration tests, canary evidence and rollback plan.

Frequently asked questions

Is MCP fully stateless now?

The 2026-07-28 protocol core is stateless. Applications can still keep durable state through explicit handles, storage, Tasks and request state.

Is Streamable HTTP still used?

Yes. It remains the standard remote transport, but each message is now its own POST and the old GET stream and protocol-session behavior were removed.

Do I still send initialize?

Not for a modern 2026-07-28 request. Use per-request metadata, and optionally call server/discover. A dual-era server may still answer initialize for legacy clients.

Do I still need Redis or Durable Objects?

Not for MCP protocol sessions. You may still need durable storage for jobs, orders, browser instances, rate limits, locks or other application state.

Can I remove sticky sessions immediately?

Only after modern traffic works across different instances and telemetry confirms no supported client or feature still depends on the legacy session path.

Primary sources

• Model Context Protocol specification, 2026-07-28
• MCP 2026-07-28 key changes and deprecations
• MCP Streamable HTTP transport
• MCP server discovery specification
• MCP tools, caching and multi-round-trip results
• MCP Tasks extension
• GitHub MCP Server support for the stateless specification
• Cloudflare migration guide for stateless MCP handlers