Clarion Street

MCP Goes Stateless — The 2026-07-28 Spec Release and the Coming Agent-Identity Battle

·6 min read

On July 28, 2026 the Model Context Protocol shipped its largest breaking change since it appeared in late 2024. It dropped the stateful initialize/initialized handshake and became a stateless request/response protocol. That’s the changelog headline. The same week, a new roadmap moved “agent identity and enterprise-ready security” from a horizon item to a named top-five priority. The stateless change is mostly plumbing. The identity work is where the real stakes are.

The stateless core

Before this release, an MCP client and server opened every conversation with a two-step initialize/initialized exchange and carried an Mcp-Session-Id header, which bound a session to a particular server instance. That model is gone. Each request now carries its own protocol version, client identity, and capabilities in a _meta field, and servers can optionally expose capabilities up front through a server/discover RPC.

The stated reason is reliability and scalability: any request can now land on any server instance behind a round-robin load balancer, with no shared storage or sticky sessions.

Headers, caches, and multi-round-trip requests

The release also makes the protocol friendlier to infrastructure and to LLM caches:

  • Method and tool names move into headers. Streamable HTTP POST requests now carry Mcp-Method and Mcp-Name, so gateways and WAFs can route and authorize on headers instead of parsing JSON bodies.
  • Tool catalogs become cacheable. List and read results (tools/list, prompts/list, resources/list, resources/read) now include ttlMs and cacheScope cache hints plus deterministic ordering, so clients can cache tool catalogs and keep LLM prompt caches stable.
  • Mid-call elicitation is now a retry, not a held-open stream. Server-initiated flows like sampling, elicitation, and roots/list are replaced by Multi Round-Trip Requests (MRTR). Instead of holding open a bidirectional stream, a server returns resultType: "input_required" with the questions it needs answered, and the client retries with the answers attached.

Authorization gets harder

The same release tightened the auth story. Authorization servers should return an iss parameter (RFC 9207) that clients must validate, which binds client credentials to the issuer that minted them. Dynamic Client Registration (DCR) is formally deprecated in favor of Client ID Metadata Documents (CIMD).

It also introduced a formal deprecation policy with a twelve-month minimum window. Roots, Sampling, and Logging, along with the legacy HTTP+SSE transport, are the first features to enter the Deprecated state under it.

Scale, self-reported

MCP’s blog reports “close to half-a-billion downloads a month” across the Tier 1 SDKs, with TypeScript and Python both “crossing the 1 billion total downloads threshold.” All four Tier 1 SDKs (TypeScript, Python, Go, and C#) ship the new spec version; the Rust SDK is in beta. Those numbers are first-party, from MCP’s own announcement, and not independently audited.

The roadmap: identity moves to the front

The same week, MCP published a roadmap organized into five priority areas, with “agent identity and enterprise-ready security” as a named top priority. That area covers: Demonstrating Proof-of-Possession (DPoP, RFC 9449); an opinionated path for agent identity and delegation through Workload Identity Federation (SEP-1933); the ID-JAG grant behind Enterprise-Managed Authorization (EMA); and RFC 8693 token exchange, coordinated with the IETF OAuth and WIMSE working groups.

MCP’s own framing is worth quoting, because it admits what’s changing: authorization today assumes a person approving access in a browser, but “more and more of the callers are agents running as cloud workloads with their own identity… built on existing standards rather than pasted API keys and long-lived tokens.”

The speed of the shift is the interesting part. In the March 2026 roadmap, WorkOS described DPoP and Workload Identity Federation as “on the horizon” and “not top-tier priorities this cycle,” with enterprise readiness the “least-defined” area. By August, agent identity was a named top-five priority with a forming working group. Roughly five months from horizon item to headline.

EMA stable, Ruby 1.0

Two adjacent milestones round out the month. Enterprise-Managed Authorization reached stable status, with Okta as the first identity provider; Anthropic (Claude, Claude Code, Cowork) and VS Code as clients; and Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase as early adopter servers, with Slack “coming soon.” The Ruby SDK hit 1.0, the first stable release of the mcp gem, passing 100% of server and client conformance scenarios and meeting every Tier 2 requirement.

The battle is bigger than MCP

Agent identity is being built in at least three places at once, so this isn’t MCP’s alone to win:

  • Uber describes the same two problems, that identity models don’t describe “agency” and that original provenance is dropped as a request hops across agents, and has built its own SPIFFE/SPIRE-based agent identity architecture.
  • The IETF is working on AI-agent identity independently under WIMSE, via an Internet-Draft ("WIMSE Applicability for AI Agents") that aims “to establish independent identities and credential management mechanisms for AI agents.”
  • Practitioners are split. A Hacker News thread on the roadmap runs from “the spec is overcomplicated” to “isn’t this reinventing SPIFFE?” to “code mode is better than MCP.”

So MCP’s identity layer is one contender among several, built alongside (and sometimes competing with) SPIFFE/SPIRE and the IETF’s work.

Read the fine print

  • The download figures are first-party and unaudited.
  • The roadmap is explicitly not a commitment; the page says it “reflects current thinking rather than firm commitments.”
  • The identity work is prospective, not shipped. The roadmap language is “finalize the specification for DPoP and focus on getting widespread adoption” and “define an opinionated path.”
  • EMA is early: one identity provider at launch, a handful of servers, and “coming soon” elsewhere. “Enterprise-ready” is directionally true, not universally deployed.
  • The stateless move is a breaking change, with “some migration cost, especially for developers that did depend on session identifiers.” MCP’s guidance is to use explicit, server-minted handles for stateful use cases.

Bottom line

MCP’s stateless rewrite is a real, shipping change that makes the protocol easier to run at scale and easier to cache. The more durable shift is the roadmap: agent identity has moved from the margins to the center, and MCP is betting on open standards (DPoP, workload identity, token exchange) rather than building something proprietary. Whether that bet wins is open, because the same problem is being solved elsewhere. The protocol is stateless now. What an agent is, and who can vouch for it, is still being decided.

Sources

  1. The 2026-07-28 Specification — MCP blog
  2. The New MCP Roadmap — MCP blog
  3. Enterprise-Managed Authorization reaches stable — MCP blog
  4. The Official Ruby SDK for MCP Reaches 1.0 — MCP blog
  5. MCP Development Roadmap — modelcontextprotocol.io
  6. MCP 2026-07-28 Specification Changelog — modelcontextprotocol.io
  7. MCP Specification Repository — GitHub
  8. Enterprise Managed Auth — Anthropic/Claude blog
  9. RFC 9449 — OAuth 2.0 Demonstrating Proof-of-Possession (DPoP)
  10. RFC 8693 — OAuth 2.0 Token Exchange
  11. WIMSE Applicability for AI Agents — IETF draft-ni-wimse-ai-agent-identity
  12. Solving the Identity Crisis for AI Agents — Uber Engineering
  13. MCP’s 2026 roadmap makes enterprise readiness a top priority — WorkOS
  14. New MCP Roadmap — Hacker News discussion