# MCP Goes Stateless in Its Biggest Protocol Update Yet

Anthropic shipped MCP 2026-07-28: a stateless rewrite that eliminates sticky sessions, adds header-based routing, and formalizes extensions. AWS, Microsoft, and Cloudflare are already in production with the new spec.

By Neomanex. Updated 2026-10-07.

Anthropic shipped the 2026-07-28 MCP specification on July 28 — the largest revision since the protocol launched in November 2024 — and it fundamentally changes how MCP works: **the protocol is now stateless.** No more `initialize` handshakes, no more `Mcp-Session-Id` headers, no more sticky sessions at the load balancer. Every request now carries its own protocol version, client identity, and capabilities in `_meta`. Any request can land on any server instance behind a plain round-robin load balancer. This is the update that makes MCP production-grade enterprise infrastructure.

## What happened

The stateless core is the headline, but the 2026-07-28 spec ships six major changes at once:

- **No handshake or sessions.** The `initialize`/`initialized` exchange and `Mcp-Session-Id` header are retired. Each request is self-describing — clients that need server capabilities up front call the new `server/discover` RPC, but it's optional. MCP servers can now run on conventional Kubernetes deployments with standard load balancers and no shared Redis stores (Anthropic, 2026).
- **Multi Round-Trip Requests (MRTR).** Server-to-client interactions like elicitation and sampling no longer require a held-open SSE stream. The server returns `resultType: "input_required"` with an opaque `requestState` token, and the client retries the original call with the user's answers. Any server instance can pick up the retry (Anthropic, 2026).
- **Header-based routing.** Every Streamable HTTP request now surfaces `Mcp-Method` and `Mcp-Name` in standard headers. API gateways, rate limiters, and WAFs can route, throttle, and meter on headers alone — no JSON body parsing required (Anthropic, 2026).
- **Cacheable list results.** `tools/list`, `prompts/list`, and `resources/list` responses now carry `ttlMs` and `cacheScope` hints. Clients can cache tool catalogs without holding persistent connections open for change notifications (Anthropic, 2026).
- **Authorization hardening.** RFC 9207 issuer validation, client credential binding to the issuing authorization server, and a formal deprecation of Dynamic Client Registration (DCR) in favor of Client ID Metadata Documents (CIMD). The auth framework now aligns with production OAuth 2.0 and OpenID Connect patterns enterprise security teams already trust (Anthropic, 2026).
- **Formal extensions framework.** Capabilities like Tasks, MCP Apps, and Enterprise Managed Authorization (EMA) now live as governed extensions with their own reverse-DNS IDs and release cadences — independent of the core spec. This prevents the fragmentation that plagued earlier versions (Anthropic, 2026).

All four Tier 1 SDKs — TypeScript, Python, Go, and C# — shipped with 2026-07-28 support on launch day. The Rust SDK followed in beta.

The ecosystem moved fast. [AWS AgentCore Gateway](https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/) shipped day-one support with a single `UpdateGateway` configuration toggle — add `"2026-07-28"` to your gateway's `supportedVersions` and existing clients keep working unchanged (AWS, 2026). [Microsoft released .NET C# SDK v2.0](https://devblogs.microsoft.com/dotnet/announcing-v20-of-the-official-mcp-csharp-sdk/) targeting the new spec. [GitHub's MCP Server](https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/) shipped support five days ahead of the spec. Cloudflare, Google Cloud, Supabase, and FastMCP all announced day-zero support.

## Why it matters

MCP just solved the single biggest barrier to enterprise adoption: the session-bound architecture that made horizontal scaling a practical nightmare. Before 2026-07-28, every MCP interaction began with a handshake that pinned the client to a specific server instance. Scaling meant sticky sessions at the load balancer, shared session stores, or deep packet inspection — all of which sat uneasily with the ops teams who approve production deployments.

Now an MCP server is a standard HTTPS endpoint. It works behind any load balancer. It plays nicely with API gateways, CDNs, and service meshes. The protocol has grown up into something an enterprise platform team can actually operate.

The extensions framework is nearly as important as statelessness. By decoupling capabilities like Tasks and authorization from the core spec, MCP can now evolve without forcing coordinated breaking changes across the entire ecosystem. AWS contributed the Tasks extension; Cloudflare, Anthropic, and others are shipping their own. This is how HTTP grew — and it's the right model for a protocol with half a billion SDK downloads per month.

The deprecation policy matters too: Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated with a twelve-month minimum window. You plan upgrades instead of reacting to them.

## What changes for you

**If you run MCP servers in production:** You can drop sticky sessions and shared Redis stores. Migrate to the new SDKs — the stateless transport eliminates a whole class of operational complexity. The deprecation window gives you time, but the architectural win of going stateless is immediate.

**If you maintain an MCP client:** Audit for `Mcp-Session-Id` dependencies, `logging/setLevel` calls, and the literal `-32002` error code (now `-32602`). Check that your client declares the correct capabilities — a client that omits required ones is rejected with code `-32021` on the new path.

**If you're evaluating MCP for a new project:** Start on 2026-07-28. The Tier 1 SDKs are ready. AWS AgentCore Gateway supports dual-version mode — you can serve old and new clients simultaneously while you migrate. There's no reason to build new infrastructure on the session-bound 2025 spec.

**If you use AWS AgentCore Gateway:** One `UpdateGateway` call adds 2026-07-28 to your `supportedVersions`. Your existing clients, tool definitions, and auth configuration are unchanged.

## FAQ

**Is this backward compatible?** No — the 2026-07-28 spec is backward-incompatible by design. But it's opt-in: clients select the protocol version per request via the `MCP-Protocol-Version` header. Gateways can advertise multiple versions simultaneously, so existing clients keep working while you migrate. The protocol maintainers have stated this is intended to be the last revision that breaks compatibility.

**What's deprecated and when will it stop working?** Roots, Sampling, and Logging are deprecated, along with the legacy HTTP+SSE transport and Dynamic Client Registration (DCR). All remain functional for at least twelve months from the spec publication date. New implementations should not adopt them.

**Which SDKs support the new spec?** TypeScript, Python, Go, and C# (Tier 1) shipped with 2026-07-28 support on launch day. Rust SDK supports it in beta. Check the [MCP SDK documentation](https://modelcontextprotocol.io/docs/sdk) for the current tier list.

Canonical: https://neomanex.com/news/mcp-2026-07-28-stateless-enterprise