MCP Servers Go Stateless as 2026-07-28 Spec Rewrites the Protocol

A protocol rebuilt around the server

The Model Context Protocol was released on July 28, 2026, in its biggest revision since launch. The main change is aimed at the people who run MCP servers. The specification has been reworked so that MCP is fully stateless, and the TypeScript, Python, Go and C# SDKs were rewritten along with it. Cloudflare says this means an MCP server can now run inside a single Worker with no stateful infrastructure behind it.13 The project's own maintainers describe the release as a stateless core that scales on ordinary HTTP infrastructure. It also adds a formal extensions system, closer alignment with OAuth and OpenID Connect, and a written deprecation policy.11

The coverage agrees on what changed. It differs on how hard the transition will be. This article argues that the shift matters mostly for server operators, who get a large operational win now and a real but limited migration bill.

What actually changed on the wire

Under the old design, a client opened a connection with an initialize/initialized handshake. The server returned a session identifier, and every later request had to carry it. Two Specification Enhancement Proposals remove that model. SEP-2575 drops the handshake, and SEP-2567 removes the Mcp-Session-Id header and the protocol-level session tied to it.11 Each request now carries its own protocol version, client information and client capabilities in a _meta field. A new server/discover method lets a client ask what a server supports when it needs to know.1219

One detail varies between write-ups. Some describe server/discover as an optional convenience.18 Security firm Equixly is more precise: clients can choose whether to call it, but every server targeting the new revision must implement it.15 Anyone maintaining a server should treat it as mandatory.

The release also adds features that make MCP traffic look like ordinary web traffic. Streamable HTTP requests must now include Mcp-Method and Mcp-Name headers. Gateways, rate limiters and web application firewalls can route and meter calls without parsing the JSON body.7 Responses to list calls such as tools/list now carry a time-to-live and a cache scope, so clients can stop re-downloading tool catalogs every time they reconnect.7 Server-initiated requests are gone. Under Multi Round-Trip Requests, a server that needs user input returns an input_required result with an opaque state token, and the client calls the same tool again with the answers attached.18

Why statelessness is a server story

Sessions are why remote MCP deployments needed sticky routing and a shared session store. That is the infrastructure web-scale services usually try to avoid.7 Without sessions, any request can go to any instance behind a plain round-robin load balancer.14

Cloud vendors have each told this as a story about their own platform, which shows how much the change was about hosting. Microsoft's App Service team says that making MCP stateless used to be a workaround developers had to build themselves. Now it is simply how the protocol behaves, and scaling a server out looks much like scaling any normal web app.16 Google calls the release a turning point that moves MCP from a local integration layer to infrastructure for enterprise AI. It highlights serverless deployment and standard load balancing.12 Cloudflare notes that MCP no longer needs a Durable Object just to speak the protocol. That makes its McpAgent abstraction unnecessary for this purpose, though Durable Objects are still useful when an application itself needs state.13

Server vendors have moved quickly. Appwrite says its MCP server already follows the new specification, including the stateless core, header-based routing and Multi Round-Trip Requests.20 One developer writing on DEV Community argues that the deeper change is cultural: MCP has stopped behaving like its own transport protocol and started behaving like HTTP. CDNs, edge workers and header-based authorization now apply to agent tooling.18 That view looks right. The operational case for MCP now rests on decades of HTTP tooling rather than on custom infrastructure.

Stateless protocol, stateful applications

One point is easy to misread. Removing protocol sessions does not mean servers can't keep state. The changelog tells servers that need state across calls to create explicit handles and pass them as ordinary tool arguments.19 The model receives an identifier such as a basket or workflow ID from one tool call and sends it back on later calls.2 Microsoft's engineers stress this distinction, separating a stateless protocol from a stateful application.16

The trade-off is mostly positive. When state lives in tool arguments, it is visible and auditable instead of hidden in transport metadata.7 It also creates new security work, which is covered below.

Deprecations and the extensions framework

The release removes several older features from the core protocol. Roots, Sampling and Logging are deprecated, and each will stay available for at least twelve months.14 The suggested replacements: pass paths as tool parameters or server configuration instead of Roots, call LLM provider APIs directly instead of Sampling, and use stderr or OpenTelemetry instead of protocol-level logging.2 Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. The legacy HTTP+SSE transport also gets a one-year window.7 Under SEP-2596, the earliest date any deprecated feature can be removed is July 28, 2027.2

Meanwhile, Tasks, MCP Apps and Enterprise-Managed Authorization now sit in a formal extensions framework, so they can ship new capabilities without destabilizing the core.7 MCP Apps lets a server declare interactive HTML that the host renders in a sandboxed iframe. Tasks gives servers a durable task ID that clients poll for long-running jobs.2 For server authors, MCP is no longer limited to returning raw data to a model.

Where the coverage diverges: migration risk

Coverage differs most on how painful the cutover will be. One guide reports that clients speaking the new spec fall back to the handshake when they meet older servers, which would allow a gradual migration.14 An enterprise-focused guide is stricter. It says the versioning rules treat 2026-07-28 and later as modern and 2025-11-25 and earlier as legacy, and that a modern-only client fails against a legacy-only server. Its advice is to run servers that support both eras until every client is upgraded.4 Equixly agrees that the handshake and session header are removed outright rather than deprecated. Older clients keep working only if the server keeps the old code path alongside the new one.15

The best reading is that compatibility exists where implementers build it, not automatically. Cloudflare's approach is a good example: its /mcp endpoint accepts both new-protocol requests and stateless requests from 2025 Streamable HTTP clients, so most clients reconnect without configuration changes.13 Operators should not assume every client will negotiate down gracefully. The twelve-month grace period applies to deprecated features like Roots, Sampling and Logging. It does not apply to the removed handshake.15

Some guides still describe 2026-07-28 as an upcoming release candidate.8 Readers using older documentation should check which revision it describes. The release candidate was locked on May 21, 2026, and the final spec shipped on schedule.14

The security ledger

The stateless design solves operational problems but changes the attack surface. Equixly lists the new risks. Explicit state handles need protection. The requestState tokens used in multi-round-trip flows should be signed and given expiry times. Because streams can no longer be resumed, interrupted calls must be retried in ways that don't trigger duplicate side effects. Gateways should reject requests where the routing headers don't match the body. Cached listings carry a risk of stale or poisoned metadata.15

On authorization, the spec requires clients to validate the issuer parameter under RFC 9207 before redeeming a code. This closes a mix-up attack involving authorization servers, and client credentials are now bound to the issuer that created them.7 Enterprise-Managed Authorization lets IT administrators grant access to MCP servers centrally through an identity provider, instead of users clicking through separate OAuth prompts for each app.2

Why it matters now

The ecosystem is large enough for this to matter. Anthropic launched MCP in November 2024. Since December 2025 it has been governed by the Agentic AI Foundation under the Linux Foundation, and OpenAI, Google and Microsoft have all adopted it.3 Estimates of the server population vary widely because they measure different things. One guide counts more than 10,000 public MCP servers in production.8 A network-automation vendor counts 78 production-ready servers in its own infrastructure field alone.1 Neither figure is authoritative. Both point to a protocol that has moved past experiments.

The July revision is a deliberate clean break, and the maintainers say they don't expect to repeat it. They expect servers built on 2026-07-28 to adopt future revisions without rewriting transport or lifecycle code.11 If that holds, the current migration is a one-time cost, and MCP servers become what Microsoft's engineers describe: ordinary web workloads that happen to serve AI agents.16