MCP 2026-07-28 Goes Stateless: What Every Agent Deployment Owes You Now

The Model Context Protocol finalized its 2026-07-28 specification today, and it is the most consequential protocol revision since authorization was added. Sessions are gone. The initialize handshake is gone. Mcp-Session-Id is gone. Every production MCP server now has a migration queued, whether its owners know it yet or not. The infrastructure story is simpler. The security story is not.

What actually changed in the protocol#

The original MCP required a multi-step handshake before any real work could happen: client sends initialize, server returns a session identifier, client echoes that identifier on every subsequent request. That design pinned clients to single server instances and forced every horizontal scaling decision through sticky sessions or a shared session store. The Register reported that Anthropic technical staff member David Soria Parra called it "the most substantial changes we have made to the specification, probably since adding authorization."

Under the new spec, every request is self-contained. Protocol version, client identity, and capabilities travel in the _meta parameter on each call. A new server/discover method replaces the handshake for capability negotiation. Routing information now appears in HTTP headers , Mcp-Method required on every request, Mcp-Name required for tools/call, resources/read, and prompts/get , so a gateway can route without parsing the JSON-RPC body. The tools/list response now carries ttlMs and cacheScope fields. 4sysops covered the full topology change in detail, including the explicit-handle pattern for state that genuinely needs to persist across calls.

Three features are formally deprecated: Roots, Sampling, and Logging. They remain functional for at least 12 months. Custom implementations, though, face significant rework. Parra acknowledged in the livestream: "If you built your own implementation, it's going to be a lot of uplift to make this correct."

The auth surface just grew, quietly#

Stateless is simpler to operate. It is not simpler to secure. Under the session model, an auth check run at initialize time covered every subsequent request in that session. Remove the session, and every request must carry its own verified credentials. Any migration that drops session auth without adding per-request auth validation has created a gap, not a simplification.

This matters because the baseline was already low. A survey cited by Microsoft's App Service team, conducted by Astrix Security, found that only 8.5% of MCP servers used OAuth. The November 2025 revision had already made OAuth 2.1 mandatory for HTTP-based MCP servers, with PKCE and RFC 8707 Resource Indicators required. Most deployments were not compliant before today's spec. The 2026-07-28 revision adds RFC 9207 iss parameter validation , a mitigation for mix-up attacks , and clarifies credential binding, refresh token handling, and scope accumulation during step-up authentication.

Six authorization-hardening SEPs ship alongside the core spec. That is the right direction. It does not help the 91.5% of servers that were not running the auth layer being hardened.

Why migration PRs deserve extra scrutiny#

The spec change is backward-incompatible in specific, predictable ways. Custom server implementations will produce migration PRs. Those PRs will touch auth middleware, session removal, header handling, and state management simultaneously. That combination is where security regressions reliably appear: a developer removes session tracking, strips the middleware that depended on it, and forgets that one of those middleware layers was validating token audience.

Stacklok's Enterprise Readiness Guide for this spec update noted that compatibility "requires both sides to share a supported protocol era, or for one side to implement deliberate fallback or translation." That fallback logic is another place where auth checks get added inconsistently across code paths.

The specific things worth checking in MCP migration PRs, drawn directly from the spec changes:

• Per-request iss validation per RFC 9207, not just at session establishment
• Token audience validation present on every tool-call path, not inherited from a session object that no longer exists
• Mcp-Method and Mcp-Name header validation on the server side (servers must reject requests where headers and body disagree)
• Removal of -32002 error code handling replaced with -32602 (custom error code matching will silently fail otherwise)
• Deprecated feature usage , Roots, Sampling, Logging , flagged for planned removal, not left as assumed-permanent

Hyrax's security agent covers auth drift at scan time: missing per-request validation, inconsistent error handling, and permission surface changes that appear when session-scoped checks move into middleware. That is exactly the class of issue these migrations will introduce.

What this means for AI coding tools#

Teams using Cursor, Claude Code, or Codex against remotely hosted MCP servers should establish which servers they own versus which they consume. Servers they own require the migration. Servers they consume will update on the vendor's schedule, and the client-side fallback behavior matters: new clients speaking 2026-07-28 fall back to the initialize handshake when connecting to servers on or before the 2025-11-25 spec, but that fallback has its own auth implications.

Beta SDKs for Python, TypeScript, Go, and C# are available now. Python v2 renames FastMCP to MCPServer. TypeScript v2 splits the monolithic SDK into focused packages and is ESM-only. Go ships 2026-07-28 support in v1.7.0-pre.1. If any internal library pins mcp>=1.27 without an upper bound, the stable v2 release will be a surprise.

The spec change is good engineering. The migration window is also a reliable source of auth regressions, and those regressions will arrive as otherwise-reasonable PRs from developers doing the right thing.

Hyrax is live at hyrax.dev.