MCP Goes Stateless: The 2026-07-28 Spec Explained

TL;DR: MCP's biggest protocol revision since Anthropic introduced it in November 2024¹ becomes final on July 28, 2026 — two weeks from today². The headline change is that MCP moves to a stateless protocol core, removing the session handshake that pinned a client to one server instance, so a remote MCP server can now scale behind a plain round-robin load balancer². Alongside it, the Enterprise-Managed Authorization (EMA) extension went stable on June 18, 2026, replacing per-server OAuth consent prompts with a single enterprise login already supported by seven MCP servers³. Beta SDKs for Python, TypeScript, Go, and C# shipped June 29, 2026 so teams can test the new revision now, and the MCP maintainers are explicit that nothing already running breaks on July 28 — adoption is opt-in⁴. Akamai's security researchers are nonetheless flagging new implementation-dependent risks in the stateless model, MCP Apps, and the Tasks extension⁵.

What You'll Learn

• What "stateless" actually means for MCP and why it lets servers scale without sticky sessions
• How Enterprise-Managed Authorization replaces per-server OAuth consent prompts
• What the two new official extensions — MCP Apps and Tasks — add to the protocol
• Which six authorization changes affect your OAuth clients and servers
• What Akamai's security researchers are flagging as new attack surface
• What to actually do before the spec locks on July 28

Why This Matters Now

MCP has gone from a local, single-user integration format to what SecurityWeek now calls "the de facto standard" for connecting AI agents to business tools, in under two years⁵¹. The current spec version, 2025-11-25, was itself named for MCP's first anniversary. The next version, 2026-07-28, is the largest revision since launch, and it has moved through a clear, dated sequence that's worth tracking because it tells you how much runway is left:

As of today, that's a two-week window left in the validation period the MCP team asked SDK maintainers and client implementers to use before the text locks²⁴.

What "Stateless" Actually Means

Under the current spec, calling a tool over Streamable HTTP starts with an initialize handshake. The server responds with an Mcp-Session-Id header that every later request must carry, which pins that client to whichever server instance issued it². That's why production MCP deployments have needed sticky routing and a shared session store.

2026-07-28 removes both the handshake (SEP-2575) and the session header (SEP-2567)². Protocol version, client info, and capabilities now travel in a _meta field on every request instead of being exchanged once at connection time, and a new server/discover method lets a client fetch server capabilities up front. The practical result: any server instance can answer any request, so a remote MCP server that needed sticky sessions, a shared session store, and deep packet inspection at the gateway can run behind an ordinary round-robin load balancer instead².

Removing protocol-level sessions doesn't mean an application has to be stateless. The MCP maintainers describe an explicit-handle pattern: a server mints an identifier (a basket_id, a browser_id) from a tool call, and the model passes that same identifier back as an ordinary argument on later calls, making the state visible to the model instead of hidden in transport metadata².

Server-to-client requests — like an elicitation prompt mid-call — get rebuilt around the same stateless model. Multi Round-Trip Requests (SEP-2322) replace a held-open server-sent-events stream: the server returns an InputRequiredResult with the fields it needs, the client collects answers, and re-issues the original call with inputResponses plus an echoed requestState token that any server instance can pick up². Three smaller but practical changes ride along: Streamable HTTP now requires Mcp-Method and Mcp-Name headers so gateways and rate limiters can route without inspecting the request body (SEP-2243); list/resource results now carry ttlMs and cacheScope fields modeled on HTTP Cache-Control, so clients know exactly how long a cached tools/list response stays fresh (SEP-2549); and W3C Trace Context propagation in _meta is now formally documented (SEP-414), so a distributed trace can follow a tool call across the client, server, and whatever it calls downstream².

Enterprise-Managed Authorization: Ending Consent-Prompt Fatigue

The standard MCP authorization model is user-scoped: every employee authorizes every server, one OAuth consent screen at a time. In a large enterprise deployment, that means manual onboarding per tool, no central audit trail, and no way to stop someone from connecting a personal account to a work server³.

Enterprise-Managed Authorization (EMA) went stable on June 18, 2026 to fix that³. It makes the organization's identity provider the authority for MCP server access: a client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP during single sign-on and exchanges it for an access token from the MCP server's authorization server, so the user is never redirected through a per-server consent screen³. Admins enable a server once for the org; users inherit access automatically, scoped to whatever groups and roles they already hold.

One important boundary: EMA governs connection-level access — whether a user's client can reach a server, and at what scope — not what the agent does once it's inside a system. The extension doesn't inspect MCP traffic after the token is issued and isn't runtime authorization for individual tool calls, so organizations still need separate controls for what an agent does once it's connected⁶.

Adoption at launch:

Okta's Aaron Parecki, Director of Identity Standards, framed it as a governance shift: "By embedding the Cross App Access protocol into MCP as the Enterprise-Managed Authorization extension, we turn identity into a centralized governance plane and give security teams strict compliance control and users a seamless, secure experience."³ Linear's Tom Moor, Head of Engineering, put the user-facing effect more simply: "Logging in once and automatically having all your MCP connectors automatically setup is pretty magical."³

If you're already running an MCP server with OAuth 2.1 and RFC 8707 resource indicators, EMA is the enterprise layer on top of that per-user flow, not a replacement for it — you'll likely support both.

Two New Extensions: MCP Apps and Tasks

2026-07-28 also formalizes an Extensions framework (SEP-2133): capabilities get reverse-DNS identifiers, live in their own ext-* repositories with delegated maintainers, and version independently of the core spec, with a dedicated track for moving from experimental to official². Two extensions ship as part of this release:

MCP Apps (SEP-1865) lets a server ship an interactive HTML interface that the host renders inside a sandboxed iframe. Tools declare their UI templates ahead of time so a host can prefetch, cache, and security-review them before anything runs, and every UI-initiated action still goes through the same JSON-RPC audit and consent path as a direct tool call².

Tasks graduates from an experimental core feature in 2025-11-25 to a full extension. A server can answer tools/call with a task handle, and the client drives it forward with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed — the client just advertises support — and tasks/list is gone entirely because it can't be scoped safely without protocol-level sessions². Anyone who built against the experimental 2025-11-25 Tasks API needs to migrate to this new lifecycle.

Authorization Hardening: Six Changes to Know

Beyond EMA, six SEPs tighten the core authorization spec to line up more closely with how OAuth 2.0 and OpenID Connect actually get deployed²⁴:

• iss validation (SEP-2468) — clients must now validate the issuer parameter on authorization responses per RFC 9207, mitigating mix-up attacks that are more common in MCP's single-client, many-server pattern.
• application_type declaration (SEP-837) — clients declare their OpenID Connect application type during Dynamic Client Registration, fixing the common failure where an authorization server defaulted a desktop or CLI client to "web" and rejected its localhost redirect URI.
• Credential binding (SEP-2352) — clients bind registered credentials to the issuing authorization server and re-register when a resource migrates between authorization servers.
• Refresh token requests (SEP-2207) — the spec now documents how to request refresh tokens from OpenID Connect-style authorization servers.
• Scope accumulation during step-up (SEP-2350) and the .well-known discovery suffix (SEP-2351) — two smaller clarifications tightened up alongside the rest.

Separately, the error code for a missing resource changes from the MCP-custom -32002 to the JSON-RPC standard -32602 Invalid Params (SEP-2164) — worth a grep across any client that matches on the literal old value⁴.

Three existing primitives — Roots, Sampling, and Logging — are formally deprecated (SEP-2577), replaced respectively by tool parameters, resource URIs, or server configuration; direct LLM provider API integration; and stderr/OpenTelemetry. These are annotation-only deprecations: the methods keep working in this release and in every spec version published within twelve months of it, under a new feature lifecycle policy that requires a minimum 12-month gap between deprecation and removal².

What Akamai's Security Researchers Are Flagging

Independent security research is treating this as a net improvement with new, different risks rather than a straightforward hardening. Akamai's analysis, reported by SecurityWeek, credits the stateless core with ending session hijacking and preventing unsolicited server-initiated prompts, while noting that "critical security boundaries are now entirely dependent on how developers implement them," per Maxim Zavodchik, Akamai's senior director of threat research⁵.

The specific concerns Akamai raises⁵:

• Predictable state handles. Since explicit handles (like basket_id) replace protocol-managed sessions, a predictable identifier could let an attacker hijack an active workflow, read another agent's data, or trigger unauthorized cross-tenant actions.
• Header-based data leakage and Desync attacks. The new mandatory Mcp-Method and Mcp-Name headers introduce protocol-confusion risk, and if developers accidentally map sensitive values — API keys, tokens, PII — into headers, those values become visible to every load balancer, proxy, and logging system in the path.
• MCP Apps and stored XSS. Server-rendered UI in a sandboxed iframe still inherits classic web application risks, including stored cross-site scripting.
• Tasks as a denial-of-service vector. Spawning a task is cheap for the client but can be expensive for the server to run; Akamai warns an attacker can trigger a resource-heavy task and disconnect immediately, without ever waiting for a result.

Akamai's overall framing: "The changes are not simply incremental improvements. They fundamentally reshape where security responsibilities reside" — from the protocol itself toward the developers and platform operators building on top of it⁵. That's a good reason to treat July 28 as a prompt to review MCP server implementations, not just SDK versions.

What to Do Before July 28

The MCP maintainers are explicit on one point: nothing already running breaks on July 28, and nothing is forced to change that day either — it's the date the normative spec text publishes, not a cutover⁴. Serving 2026-07-28 is an explicit, opt-in choice in the TypeScript and Go SDKs; clients that speak the new revision automatically fall back to the initialize handshake when they reach an older 2025-11-25 server, so old servers and new clients keep interoperating⁴.

With two weeks left before the text locks, the practical checklist looks like this:

1. Install a beta SDK in a branch and run real traffic against it — Python (mcp[cli]==2.0.0b1, with FastMCP renamed to MCPServer), TypeScript (new scoped packages like @modelcontextprotocol/server, plus a v1-to-v2 codemod), Go (v1.7.0-pre.1, opt in via StreamableHTTPOptions.Stateless = true), or C# (2.0.0-preview.1 of ModelContextProtocol)⁴.
2. Pin versions if you depend on the MCP packages. If you publish a library depending on the Python mcp package, add an upper bound now (for example mcp>=1.27,<2) so the stable v2 release doesn't surprise downstream users⁴.
3. Grep your client for the literal -32002 error code and update it to expect -32602 instead⁴.
4. If you're behind a gateway or load balancer, test the stateless path and confirm your routing doesn't depend on anything the protocol no longer provides⁴.
5. If you ship to enterprise customers, evaluate Enterprise-Managed Authorization and Okta's Cross App Access now — seven servers already support it, and it addresses the consent-prompt friction that's slowed enterprise MCP rollouts³.
6. File what breaks. The MCP team has said the next four weeks of feedback (from late June) shape what ships stable — issues go to the SDK-specific repository you're testing against⁴.

Bottom Line

MCP's 2026-07-28 release is a genuine architectural shift — removing protocol-level sessions is the kind of change that needed a clean break, and the maintainers built governance (a formal deprecation policy, an extensions track) specifically so it doesn't need repeating. Enterprise-Managed Authorization solves a real friction point for enterprise MCP rollouts, and having Anthropic, Visual Studio Code, and Okta behind it from the start gives it real momentum toward becoming a default rather than staying an opt-in extension. None of this is a fire drill: existing servers keep working, and adoption of the new revision is opt-in on your own schedule. The more useful posture is the one Akamai is describing: treat this as a prompt to review your own MCP server's implementation choices, not just a version bump to schedule. The spec text itself locks in two weeks, but SecurityWeek reports the fuller security-adaptation runway at up to twelve months⁵ — either way, Akamai's researchers see this release shifting security responsibility onto whoever builds on top of it. If you're building MCP clients or servers, or you're new to what MCP actually is, this is the moment to read the changelog before it locks.