A stateless reset for Model Context Protocol

Model Context Protocol (MCP) has spent the last eighteen months becoming the de facto standard for connecting agents to external services. Its main weakness, though, has been the stateful connection required between client and server — a design carried over from the original STDIO transport built for local applications. Remote MCP servers have had to manage sticky sessions, open streams, message replay, and the operational overhead that comes with all of it. The new 2026-07-28 specification, released last week alongside updated TypeScript, Python, Go, and C# SDKs, removes that entire class of complexity. MCP is now fully stateless.

This changes where and how MCP servers can run. No stateful infrastructure is required; a plain Worker can host a server. The specification, interaction model, and SDKs have all been rewritten around the new protocol.

What the protocol change means in practice

Older transports opened with an initialize/initialized handshake to establish a session, with servers able to assign an Mcp-Session-Id header for subsequent requests. Autoscaling infrastructure had to preserve those sessions, deployments had to drain or migrate them, and losing an instance meant broken connections. Serverless platforms could run MCP servers, but only by coordinating protocol sessions that most interactions never used.

The new specification removes the required handshake, the Mcp-Session-Id header, and protocol sessions from the core request path. Each request carries its own protocol version, client identity, and client capabilities. A client can optionally call server/discover to inspect a server before making another request, but no session bookkeeping is required.

A request now arrives at a server, invokes a tool, prompt, or resource, and returns a result. All existing functionality survives, minus the stateful overhead.

Elicitation without open streams

MCP servers sometimes need extra input before completing a request — a deployment tool awaiting approval, a design tool asking for colors, a billing tool confirming a refund. Previously, these server-initiated elicitations depended on an open transport stream, forcing careful balancing of stream complexity, cost, and request timeouts.

The new protocol handles this through Multi Round-Trip Requests (MRTR). A server returns an input_required result describing what it needs; the client gathers the input and retries the original operation. No transport session persists between those requests. It is a breaking change from the old style of elicitation, but substantially simpler to implement.

The reworked protocol also makes MCP readable by standard HTTP infrastructure. The specification now requires Mcp-Method and Mcp-Name headers on Streamable HTTP requests. A gateway, rate limiter, or WAF can classify requests (a tools/list call versus a tool invocation, for instance) without parsing the JSON body, applying method-specific rules and metrics using ordinary HTTP primitives.

Caching also improves: ttlMs and cacheScope hints accompany results from tools/list, prompts/list, resources/list, and resources/read. Tool catalogs have deterministic ordering, so clients can reuse listings while keeping upstream prompt caches stable across reconnects.

Tighter authorization, clearer lifecycle

Authorization has been tightened. MCP prefers pre-registered clients where a relationship exists, uses Client ID Metadata Documents (CIMD) for dynamic registrations, and falls back to Dynamic Client Registration (DCR), which is deprecated for new implementations and slated for removal after summer 2027.

The spec also adopts RFC 9207 issuer identification. An authorization server advertises authorization_response_iss_parameter_supported: true and includes iss in successful responses; the client verifies it against the issuer discovered before the flow started, preventing response confusion between issuers. Clients send the canonical server URI as the RFC 8707 resource in authorization and token requests, and tokens are bound to that audience.

MCP 2026-07-28 also formalizes a feature lifecycle. Features are classified Active, Deprecated, or Removed, with deprecated features guaranteed at least 12 months of availability before removal. Roots, Sampling, Logging, Dynamic Client Registration, and the legacy HTTP+SSE transport are deprecated but have a defined runway. New capabilities move through an extensions framework rather than immediately entering the core protocol; MCP Apps, Enterprise-Managed Authorization, and Tasks are already living there.

A path from McpAgent to Worker

Cloudflare’s involvement with MCP dates to March 2025 and the McpAgent primitive for Agents SDK, followed by Durable Objects as the natural hosting choice for stateful MCP servers. With state removed from the protocol core, McpAgent is no longer required for MCP itself. Durable Objects still make sense when an application genuinely needs state, but MCP servers can now scale on request-scoped infrastructure like Workers.

The Cloudflare Agents SDK has supported the new specification since day one, and production customers have been running against the release candidate. The createMcpHandler function — introduced in the Agents SDK in November 2025 on top of experimental stateless support in the MCP TypeScript SDK — has now graduated into the official MCP TypeScript SDK with this release.

Cloudflare also worked with MCP maintainers in early 2026 to replatform the TypeScript SDK from Node.js to Web Standards, improving interoperability across Bun, Deno, and Workers. Bundling, runtime shims, and split packages contributed by the team reduced deployment sizes. The Code Mode MCP Server for the Cloudflare API, launched in February on this unofficial stateless mode, has since served billions of tool calls at thousands of requests per second.

Migration is supported with backward compatibility. The /mcp endpoint accepts both the new protocol and stateless requests from 2025 Streamable HTTP clients, so most clients reconnect without configuration changes. Servers dependent on legacy sessions should operate a strict stateless route beside the existing sessionful route, migrate features, drain active sessions, and then remove the legacy path within the deprecation window. Clients get the simpler end of the deal: upgrading the agents version is sufficient.

The protocol grows up

The latest MCP specification is seeing early production use, and the teams behind those deployments say the update addresses the sharpest criticisms of the original protocol. Sentry went live with the new spec before it was finalized, relying on Cloudflare's SDK for its MCP server implementation.

"We went live with this new one before the 7-28 spec was even finalized, and it didn't break prod," said David Cramer, co-founder and chief product officer at Sentry. "This new spec cleans up a bunch of the nonsense around auth and tools, which is exactly what I wanted. Agents only get useful once the plumbing stops being the whole story."

Linear, which builds an issue tracking and project management tool, also sees the revision as a turning point. The company adopted MCP to give agents secure access to Linear data regardless of which AI client a user brings.

"MCP is a clear example of why open standards matter," said Tom Moor, Head of Engineering at Linear. "The latest iteration of the spec is a great improvement that makes hosting an MCP server easier, more reliable, and at the same time adds much needed functionality. I still think MCP is massively underestimated — we built our server once on the standard and it works with whatever AI client our users want to bring."

For Anthropic, which created MCP and donated it to the Agentic AI Foundation, the new spec marks the protocol's maturation into vendor-neutral infrastructure. David Soria Parra, Co-creator and Lead Maintainer of MCP and Member of Technical Staff at Anthropic, emphasized that the update delivers meaningful performance gains with minimal engineering effort on the client side.

"This is the most significant advance to the protocol since launch," Parra said. "Security follows the same proven standards that protect the rest of the internet. Maintainers and contributors from across the community, drawing on real production experience at enterprise scale, made that possible."

Stateless servers, production-ready

The updated specification removes the need for stateful infrastructure in typical MCP workloads. Servers can now run as ordinary HTTP applications on Cloudflare Workers, with authentication handled through the Workers OAuth Provider and client connectivity managed via an Agent. Developers who need coordinated state can still reach for Cloudflare Durable Objects, and the same route can serve both new and legacy stateless clients during migration.

Getting started requires the latest Agents SDK and the MCP TypeScript server SDK. Cloudflare publishes a migration guide for existing servers, along with createMcpHandler API documentation. Cloudflare's own product-specific MCP servers already support the new specification.

With stateful infrastructure no longer a prerequisite, MCP servers can be deployed as ordinary Workers — close to users, with the same scale, security, and observability tooling used across the rest of the web.