Skip to content

The next generation of MCP

Summary

Cloudflare announces the MCP 2026-07-28 specification: the Model Context Protocol becomes a fully stateless protocol. The mandatory initialize/initialized handshake, the Mcp-Session-Id header, and protocol-level sessions are removed from the core request path. Each request now self-describes (protocol version, client identity, capabilities), so a request can arrive, invoke a tool/prompt/resource, and return a result with no session to store or migrate. This eliminates the need for Cloudflare's McpAgent primitive: MCP servers can now run as ordinary HTTP workloads in a Worker, reserving Durable Objects for when the application itself needs state. The post also covers stateless elicitation via Multi Round-Trip Requests (MRTR), new MCP HTTP headers that let gateways route without parsing JSON, tightened authorization, and a formal feature-lifecycle/deprecation policy.

Key takeaways

  1. MCP is now stateless. Earlier transports began with an initialize/initialized exchange that assigned an Mcp-Session-Id; every subsequent request had to find state for that session. Autoscaling infra had to preserve active sessions, deployments had to drain/migrate them, and losing an instance forced reconnects or broke sessions. The new protocol removes the handshake, the session header, and sessions from the core path — optional server introspection is available via server/discover (Source: article §"MCP is now stateless"). This is the wiki's canonical instance of concepts/stateless-compute.

  2. McpAgent is no longer required; run in a plain Worker. Because there is no protocol session to hold, servers scale on request-scoped infrastructure like Workers. Durable Objects "remain the right primitive when an application itself needs state," but MCP itself no longer requires one to speak the protocol (Source: article §"MCP is now stateless"). Canonical statement that transport statefulness and application statefulness are separable — see concepts/serverless-compute

  3. concepts/scale-to-zero.

  4. Elicitation no longer needs an open stream (MRTR). Server-initiated requests like elicitation/create previously depended on an open stream, forcing servers to balance stream complexity, cost, and request timeouts. The new Multi Round-Trip Requests (MRTR) pattern lets a server return an input_required result describing what it needs; the client collects the answer and retries the operation with that input. The original operation completes without either side preserving a transport session. This is a breaking change but operationally much simpler (Source: article §"Elicitation no longer needs an open stream"). See multi-round-trip-request and the elicitation gate.

  5. HTTP infrastructure now understands MCP. The spec requires Mcp-Method and Mcp-Name headers on Streamable HTTP requests (e.g. Mcp-Method: tools/call, Mcp-Name: search) alongside MCP-Protocol-Version. A gateway, rate limiter, or WAF can now make routing and policy decisions from headers without parsing arbitrary JSON, apply per-method rules, and record tool-level metrics with existing HTTP primitives (Source: article §"HTTP infrastructure understands MCP"). Canonical instance of protocol-metadata-in-http-headers.

  6. Cache hints + deterministic ordering keep upstream prompt caches stable. The spec adds ttlMs and cacheScope hints to results from tools/list, prompts/list, resources/list, and resources/read. Tool catalogs are deterministically ordered, so clients can reuse them and keep upstream prompt caches stable across reconnects (Source: article §"HTTP infrastructure understands MCP"). See concepts/context-engineering.

  7. Authorization tightens. Preference order for client registration is now: pre-registered clients → Client ID Metadata Documents (CIMD) for dynamic registration → Dynamic Client Registration (DCR) as fallback. DCR is deprecated for new implementations and slated for removal after summer

  8. The spec adopts RFC 9207 issuer identification (iss in authorization responses, compared against the discovered issuer) to prevent cross-issuer response confusion, and RFC 8707 resource indicators — the client sends the canonical server URI as resource, and tokens must be issued for and accepted only by that audience. Workers OAuth Provider implements these on Workers (Source: article §"Authorization continues to evolve"). See audience-restricted-token.

  9. A formal feature lifecycle. Features are classified Active / Deprecated / Removed; a deprecated feature must remain available for at least 12 months before removal. Roots, Sampling, Logging, DCR, and the legacy HTTP+SSE transport are deprecated in this release with a defined migration window. New ideas move through an extensions framework (MCP Apps, Enterprise-Managed Authorization, Tasks) without immediately entering the core protocol (Source: article §"A lifecycle for a maturing standard"). Canonical instance of feature-lifecycle-deprecation-policy.

  10. createMcpHandler graduates into the official TypeScript SDK. Introduced in the Agents SDK (Nov 2025) on an experimental stateless mode, it now ships in the official MCP TypeScript SDK. Cloudflare also helped replatform the TypeScript SDK from Node.js to Web Standards (bundling, runtime shims, split packages), improving interop with Bun, Deno, and Workers and lowering deployment sizes (Source: article §"A new MCP with new SDKs"). See systems/mcp-typescript-sdk + systems/cloudflare-agents-sdk.

  11. Backward compatibility via one endpoint. The /mcp endpoint accepts both the new protocol and stateless requests from 2025 Streamable HTTP clients, so most clients reconnect with no config changes. Servers that truly depend on legacy sessions run a strict stateless route beside the sessionful route, migrate features, drain active sessions, then remove the legacy path during the deprecation window (Source: article §"A new MCP with new SDKs"). Canonical instance of patterns/shadow-migration.

  12. In production at scale. Sentry built its MCP on Cloudflare's SDK and went live on the new protocol before the 7-28 spec was finalized without breaking prod; Cloudflare's own Code Mode MCP server (for the entire Cloudflare API, Feb 2026) ran on the unofficial stateless mode (WebStandardsStreamableHTTPServerTransport) and scaled to thousands of requests/second, billions of tool calls (Source: article §"Next gen MCP is already in production" + §"A new MCP with new SDKs").

Architectural details

  • Stateless request shape. Each request carries MCP-Protocol-Version, client identity, and client capabilities. No initialize/initialized, no Mcp-Session-Id. Optional inspection via server/discover.
  • MRTR flow. tool call → input_required result (describes needed input) → client collects answer → client retries operation with input → operation completes. No open stream, no transport session between the two requests.
  • HTTP header surface. MCP-Protocol-Version: 2026-07-28, Mcp-Method: tools/call, Mcp-Name: search on Streamable HTTP; JSON-RPC body still carries the full request, but intermediaries no longer need to parse it.
  • List/read cache hints. ttlMs + cacheScope on tools/list, prompts/list, resources/list, resources/read; deterministic tool-catalog ordering.
  • Authorization stack. pre-registered → CIMD → DCR (deprecated); RFC 9207 iss check; RFC 8707 resource/audience-restricted tokens; implemented by Workers OAuth Provider.
  • Minimal server = McpServer + createMcpHandler(createServer) exported as a Worker fetch handler; registerTool(name, {description, inputSchema}, fn).
  • Deployment model. Stateless MCP server = ordinary HTTP workload on a Worker, close to users; Durable Objects only when the application needs coordinated state.

Operational numbers

Metric Value
New spec version 2026-07-28
Deprecated-feature minimum availability before removal ≥ 12 months
DCR removal target after summer 2027
Code Mode MCP server throughput thousands of requests/sec
Code Mode MCP server volume billions of tool calls served
SDKs updated at release TypeScript, Python, Go, C#
Deprecated features this release Roots, Sampling, Logging, DCR, legacy HTTP+SSE transport

Caveats

  • Elicitation via MRTR is a breaking change from the stream-based approach; servers that relied on server-initiated requests over an open stream must migrate.
  • Servers that genuinely depend on legacy protocol sessions, server-to-client requests, or standalone streams need a deliberate migration (dual route + drain), not a drop-in upgrade.
  • Numbers are vendor-supplied and partly qualitative (Sentry "didn't break prod"); throughput/volume figures are for Cloudflare's own Code Mode server, not a general benchmark.
  • This is a Cloudflare framing of an ecosystem-wide (Anthropic/AAIF) spec; protocol details are authoritative but the deployment lessons are Workers/Durable-Objects-centric.

Source

Last updated · 766 distilled / 2,225 read