MCP 2026-07-28 — Stateless Core Fixes Scale, Breaks Everything

The final MCP 2026-07-28 specification lands in ten days, and it is the largest protocol revision since launch. The release candidate locked on May 21. Beta SDKs for Python, TypeScript, Go, and C# shipped June 29. If your production MCP server still relies on session state, Roots, Sampling, or Logging, you have breaking changes to absorb — and the clock is running.

TL;DR

• Breaking: initialize/initialized handshake and Mcp-Session-Id header are gone. All Streamable HTTP requests now require Mcp-Method and Mcp-Name headers or they fail.
• Deprecated: Roots, Sampling, and Logging enter a 12-month deprecation cycle — functional after July 28, but building new servers on them is building on borrowed time.
• New attack surface: MCP Apps (SEP-1865) lets servers ship interactive HTML into IDE iframes. If your host doesn’t enforce strict sandboxing, you have a phishing and script-execution vector.
• Action: Test against the RC beta SDKs today. Waiting until July 28 is choosing to be surprised.

What Happened

Six Specification Enhancement Proposals dismantle MCP’s stateful architecture and replace it with a stateless core. SEP-2575 removes the initialize/initialized handshake. SEP-2567 deletes the Mcp-Session-Id header and protocol-level sessions entirely. Together, they eliminate the concept of server-side session state from the protocol.

This is not a cosmetic cleanup. Every MCP server that keyed state off a session ID — caching user context, tracking tool invocations, maintaining conversation flow — must migrate that state to explicit opaque handles passed as tool arguments. The protocol no longer manages it for you.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers on every request (SEP-2243). The rationale: load balancers, API gateways, and rate-limiters can route on the operation without deep packet inspection of the JSON body. Practical win for infrastructure teams. Immediate breakage for every client that doesn’t send them.

If your MCP integration relies on sticky sessions, shared session stores, or gateway-level session affinity, those patterns are dead after July 28. The protocol no longer provides session identifiers at any layer.

Why This Matters

The stateless redesign solves a real problem. Stateful MCP servers were a horizontal scaling nightmare. Sticky sessions meant you couldn’t load-balance MCP traffic across replicas without a shared session store. API gateways needed to inspect request bodies to route traffic intelligently. Running MCP behind Cloudflare or a standard ingress controller meant fighting the protocol instead of using it. That pain is gone now — and it’s the right call.

But the tradeoff is severe: every security boundary that the protocol enforced through session state now moves down to your implementation. The protocol used to track which client was talking to which server instance. Now you do. The protocol used to enforce initialization sequencing. Now you don’t get initialization at all.

MCP Apps is the new threat model nobody’s thinking about. SEP-1865 lets servers ship interactive HTML interfaces that hosts render in sandboxed iframes — directly inside your IDE. Think about that for a moment: a remote MCP server can now push rendered UI into the environment where your developers write code. The specification says hosts should enforce strict sandboxing and require servers to declare templates ahead of time. But “should” is doing a lot of work in that sentence. If your MCP host doesn’t implement sandboxing correctly — and yours likely doesn’t yet, because the feature is new — you have a phishing and script-execution vector sitting inside your development environment.

Security researchers, Akamai among them, flagged this ahead of the July 28 launch, and they’re right to. The protocol removes several classes of session-based vulnerabilities, but MCP Apps introduces a category of attack that didn’t exist before: server-rendered content executing in a trusted IDE context.

On May 20, 2026, the National Security Agency’s AI Security Center published its first formal cybersecurity guidance specifically for MCP: Model Context Protocol: Security Design Considerations for AI-Driven Automation. When defense agencies issue protocol-specific security guidance, you’re no longer dealing with a developer convenience layer. You’re dealing with infrastructure that sits in front of real data, real credentials, and real business logic.

The auth hardening in 2026-07-28 — six SEPs aligning MCP with mainstream OAuth 2.1 and OpenID Connect, including iss-parameter validation per RFC 9207 — points the same direction as the NSA guidance. The specification authors and the government security apparatus arrived at the same conclusion independently: treat every MCP server as a trust boundary.

Multi Round-Trip Requests (SEP-2322) replaces server-initiated calls like Sampling and Elicitation. A server returns an InputRequiredResult carrying inputRequests plus an opaque requestState; the client gathers answers and re-issues the original call with inputResponses. If you’re building new server-to-client interaction patterns, start here instead of deprecated Sampling.

Three features are deprecated, not removed. Roots, Sampling, and Logging enter the formal deprecation cycle under SEP-2577 and SEP-2596. The new lifecycle policy guarantees a minimum 12-month overlap between deprecation and removal. Methods, types, and capability flags keep functioning in 2026-07-28 and in every spec version published inside that 12-month window. But every new server built on these features is accumulating debt that comes due in mid-2027.

Tasks got a full redesign. If you shipped against the experimental Tasks feature from the 2025-11-25 spec, the lifecycle model changed completely. Tasks moved to an extension (SEP-2663) with a handle-based polling model: tools/call returns a handle, clients drive progress using tasks/get, tasks/update, and tasks/cancel. The old tasks/list method is gone. And the hit-and-run DoS vector — clients spawning resource-heavy tasks and disconnecting — now requires server-side resource quotas that the protocol no longer enforces for you.

Caching is now first-class. List and resource read results carry ttlMs and cacheScope (SEP-2549), modeled on HTTP Cache-Control. Clients know exactly how long a tools/list response is fresh and whether it’s safe to share across users. This is a quiet but significant infrastructure win — it means your MCP proxy layer can finally cache tool listings without guessing at staleness.

The Take

This isn’t a version bump you schedule for Q4. The stateless redesign is the right architectural decision — it kills the horizontal scaling problem that made MCP painful in production — but it moves the security responsibility squarely onto you. The protocol used to be a guardrail. Now it’s a wire format.

I’m most concerned about MCP Apps. Letting remote servers push rendered HTML into IDE iframes is powerful and dangerous in equal measure. The specification’s sandboxing requirements are solid on paper, but we’re about to discover how many MCP hosts implement them correctly on day one. My prediction: not many. If you operate an MCP host, auditing your iframe sandboxing before July 28 is not optional — it’s the highest-priority security task on your plate.

The beta SDKs are available now. Tier 1 SDKs (Python, TypeScript) are expected to ship full 2026-07-28 support before the final date. Test your servers against the RC today. The ten-day window between now and the spec going final is not a buffer — it’s the last chance to find out what breaks before your users do. Teams that wait until the spec is published to start migrating are choosing to ship broken MCP integrations to production.

Deprecation of Roots, Sampling, and Logging with a 12-month runway is generous. Use it. But don’t build anything new on them. Multi Round-Trip Requests (SEP-2322) is the replacement pattern, and it’s a better design — explicit, client-driven, stateless. Start there.