{"slug": "mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix", "title": "MCP 2026-07-28 Stateless Spec: What Breaks, What to Fix", "summary": "The MCP 2026-07-28 specification, released July 28, introduces three breaking changes: removal of the initialize handshake (SEP-2575), removal of session IDs (SEP-2567), and a change in invalid parameters error code from -32002 to -32602. Claude added support in its August release notes, and the spec enables stateless serverless deployments, routing headers, caching, distributed tracing, and OAuth 2.1 integration.", "body_md": "The MCP 2026-07-28 specification dropped on July 28, and Claude added support for it in its [August release notes](https://platform.claude.com/docs/en/release-notes/overview). It’s the largest change to the Model Context Protocol since launch — and it ships three breaking changes. If you have a deployed MCP server, your to-do list just got items on it.\n\n## What Broke\n\nThe spec removes two things developers relied on and changes one error code that’s easy to miss:\n\n### 1. The Initialize Handshake Is Gone (SEP-2575)\n\nThe `initialize`\n\n/`initialized`\n\nexchange that every MCP session started with has been removed entirely. The client info, protocol version, and capabilities that used to be negotiated once at the start now travel in a `_meta`\n\nfield on every request. A new `server/discover`\n\nmethod handles capability negotiation when a client needs it up front. If your server reads from initialization state, it needs to read from `_meta`\n\ninstead.\n\n### 2. Session IDs Are Gone (SEP-2567)\n\nThe `Mcp-Session-Id`\n\nheader is removed. There are no protocol-level sessions anymore. Any state that needs to survive across multiple requests must be explicit — return an opaque handle from one tool call and pass it into the next one. If you’re relying on shared session stores for horizontal deployments, that infrastructure requirement is now gone from the protocol layer. Remove it from your server, too.\n\n### 3. Error Code Changed\n\nInvalid parameters errors changed from `-32002`\n\nto `-32602`\n\n. If you have hardcoded checks for `-32002`\n\n, they’ll silently stop matching. It’s the kind of bug that only surfaces under error conditions, which means it’ll be annoying to find in production. Fix it now.\n\nAlso deprecated in this release: `Roots`\n\n, `Sampling`\n\n, and `Logging`\n\nprimitives. Not removed yet, but they’re on their way out.\n\n## What You Get in Return\n\nRemoving sessions isn’t just simplification — it unlocks infrastructure capabilities that weren’t possible before.\n\n**Routing headers:** Every Streamable HTTP request now carries `Mcp-Method`\n\nand `Mcp-Name`\n\nheaders (SEP-2243). Your gateway, rate limiter, or WAF can route and meter traffic without opening the request body. This matters for teams running MCP at scale behind reverse proxies.\n\n**Caching:** List and resource read results now carry `ttlMs`\n\nand `cacheScope`\n\n(SEP-2549), modeled on HTTP Cache-Control. Clients know how long a `tools/list`\n\nresponse is valid and whether it’s safe to share across users. You no longer need a long-lived SSE stream just to avoid re-fetching the tool list on every request.\n\n**Distributed tracing:** W3C Trace Context — `traceparent`\n\n, `tracestate`\n\n, `baggage`\n\n— is now standardized in `_meta`\n\n(SEP-414). A trace that starts in your host application follows a tool call through the client SDK, the MCP server, and anything the server calls downstream, showing up as one span tree in your OpenTelemetry backend. Agent debugging got meaningfully better.\n\n**OAuth 2.1:** MCP servers are now formally OAuth 2.1 resource servers and must implement [OAuth 2.0 Protected Resource Metadata (RFC 9728)](https://www.rfc-editor.org/rfc/rfc9728). Enterprise identity — Okta, Microsoft Entra ID — connects natively. The new Enterprise-Managed Authorization (EMA) extension lets an organization’s IdP control which MCP servers employees can access, replacing per-server consent screens with a token relay. Okta, Asana, Atlassian, Canva, and others are shipping it now.\n\n## Serverless Works Now. Really.\n\nThe headline infrastructure implication of stateless MCP: you no longer need sticky sessions or shared session stores for horizontal deployments. Any request can land on any server instance. Cloud Run, Lambda, Azure Container Apps, Cloudflare Workers — all work behind a plain round-robin load balancer with no session gymnastics required.\n\nAWS updated AgentCore Gateway to support 2026-07-28 with a single `UpdateGateway`\n\nAPI call. Cloudflare released Agents SDK v0.20.0 with spec support. Google published a [guide on scaling AI agent infrastructure](https://developers.googleblog.com/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates/) with the stateless updates. The platform ecosystem moved fast on this one.\n\n## SDK Changes by Language\n\nThe [official SDKs have been updated](https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/). The breaking changes are in the Python and TypeScript packages:\n\n**Python v2:**`FastMCP`\n\nis renamed to`MCPServer`\n\n. The decorator API is unchanged.**TypeScript v2:** The monolithic SDK is split into`@modelcontextprotocol/server`\n\nand`@modelcontextprotocol/client`\n\n. It’s now ESM-only.**Go and C# SDKs:** Both updated; C# v2.0 announced on the .NET Blog.\n\nBackward compatibility is handled: a v2 server still answers the legacy initialize handshake, so clients on the 2025-11-25 spec continue connecting without changes. Upgrading your server doesn’t strand your users.\n\n## The “Just REST” Argument\n\nDeveloper reaction split between those calling this a scaling win and those saying [MCP just rediscovered REST](https://www.infoq.com/news/2026/08/mcp-stateless-gateway/). The critics aren’t wrong — stateless, routable headers, cacheable responses, OAuth resource servers. That’s REST vocabulary.\n\nHere’s the ByteIota take: it’s the right call regardless. MCP was designed for local stdio connections. As it scaled to remote, production, enterprise deployments, the session model became a liability. Redesigning the protocol to reflect the infrastructure reality it’s actually running on isn’t a retreat — it’s engineering judgment. If your criticism of MCP two years ago was that it was overengineered, this release vindicates you and still requires your migration work.\n\nPrioritize the OAuth 2.1 changes first. They’re a security requirement, not an optimization. Then tackle statelessness on a scheduled timeline. The spec is finalized; the [migration window is open](https://blog.modelcontextprotocol.io/posts/2026-07-28/).", "url": "https://wpnews.pro/news/mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix", "canonical_source": "https://byteiota.com/mcp-2026-07-28-stateless-spec/", "published_at": "2026-08-12 23:08:25+00:00", "updated_at": "2026-08-12 23:34:48.616944+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "ai-policy"], "entities": ["Claude", "Model Context Protocol", "AWS", "Cloudflare", "Okta", "Asana", "Atlassian", "Canva"], "alternates": {"html": "https://wpnews.pro/news/mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix", "markdown": "https://wpnews.pro/news/mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix.md", "text": "https://wpnews.pro/news/mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix.txt", "jsonld": "https://wpnews.pro/news/mcp-2026-07-28-stateless-spec-what-breaks-what-to-fix.jsonld"}}