Model Context Protocol Releases 2026-07-28 Spec, Transitioning to a Fully Stateless Architecture

Model Context Protocol Releases 2026-07-28 Spec, Transitioning to a Fully Stateless Architecture The Model Context Protocol team and SDK maintainers have released the 2026-07-28 specification along with updated SDKs for TypeScript, Python, Go, and C#. The update transitions MCP into a fully stateless protocol, eliminating mandatory session handshakes, overhauling client elicitations, and refining authorization and HTTP metadata handling. Core requests no longer require an initialization handshake or Mcp-Session-Id header, enabling MCP servers to run statelessly on standard serverless infrastructure such as Cloudflare Workers. Server-driven elicitations shift from persistent streams to Multi Round-Trip Requests (MRTR), returning an input_required response that clients retry with supplied input. Streamable HTTP requests now require Mcp-Method and Mcp-Name headers, enabling proxies and WAFs to route and rate-limit without parsing JSON bodies. Authorization updates deprecate Dynamic Client Registration in favor of pre-registered clients and Client ID Metadata Documents, alongside adopting RFC 9207 issuer identification. Stateless Protocol and Simplified Deployment Earlier MCP transports relied on an initialize exchange, Mcp-Session-Id headers, and stateful session maintenance, creating deployment and autoscaling overhead. The 2026-07-28 specification removes required handshakes and protocol sessions from the core path, passing protocol versions, client identities, and capabilities in individual requests. MCP servers can now run as standard request-scoped HTTP workloads directly within Cloudflare Workers without requiring Durable Objects or the previous McpAgent primitive unless application-level state is specifically needed. Multi Round-Trip Requests and HTTP Metadata Interactive server requests that previously required persistent open streams—such as elicitation approvals—have been replaced with Multi Round-Trip Requests (MRTR). Servers return an input_required state describing necessary information, prompting the client to collect user input and retry the request statelessly. Additionally, requests now mandate Mcp-Method and Mcp-Name HTTP headers, allowing gateways, firewalls, and rate limiters to inspect operations without parsing JSON-RPC payloads, while response caching is enhanced via ttlMs and cacheScope hints. Authorization Hardening and Feature Lifecycle The specification strengthens security by prioritizing pre-registered clients and Client ID Metadata Documents (CIMD), while deprecating Dynamic Client Registration (DCR) ahead of its planned removal after summer 2027. It also adopts RFC 9207 issuer identification to prevent token confusion and enforces RFC 8707 resource targeting. A formal lifecycle framework now governs protocol features: deprecated features (including legacy HTTP+SSE transport, Roots, Sampling, and Logging) must remain available for at least 12 months, while newer concepts such as Tasks and MCP Apps are organized within an extensions framework.

MCP发布2026-07-28新规范：全面转向无状态架构并简化基础设施 模型上下文协议（MCP）正式发布2026-07-28新规范与各语言SDK更新。新版本彻底移除了核心链路上的有状态连接与握手要求，重构了交互模式与认证体系，允许开发者直接在Cloudflare Workers等Serverless无状态环境中轻松部署与扩展服务。 MCP核心协议完全转为无状态，去除了强制握手和Mcp-Session-Id标头，降低部署与伸缩复杂度。 引入多轮往返请求（MRTR）机制替代长连接流式传输，简化需要用户或上下文输入的交互流程。 在Streamable HTTP请求中引入Mcp-Method与Mcp-Name标头，便于网关和WAF进行无需解析JSON体的路由与管控。 更新授权方案：优先推荐预注册客户端与CIMD，弃用DCR，并采用RFC 9207规范发行者识别以防止混淆。 建立正式的功能生命周期管理机制，弃用特性需维持至少12个月迁移期，同时通过扩展框架支持长期任务与企业授权。 从有状态到完全无状态的协议演进 早期的MCP规范源于本地STDIO传输设计，迁移至远程Web时带来了维持会话、长连接、粘性路由及故障重连的运维负担。新规范移除了初始化握手及Mcp-Session-Id等核心状态追踪要求，每个请求独立携带版本与能力信息。开发者无需再为MCP本身的通信维系Cloudflare Durable Objects等有状态存储，使得MCP服务器可直接部署在普通的Cloudflare Worker中按需扩缩容。 交互与网络层优化：MRTR与HTTP标头 当服务器需要额外输入（如发布审批、用户确认）时，旧机制需依赖保持开启的流；新规范采用多轮往返请求（MRTR），返回input_required并由客户端收集输入后重试操作，无需在两次请求间保留连接会话。此外，HTTP请求现已强制包含Mcp-Method和Mcp-Name标头，让反向代理、限流器和WAF免于解析JSON正文即可按方法和工具执行策略，同时增加了缓存提示以稳定Prompt缓存。 鉴权加固与规范生命周期机制 在安全方面，MCP优先支持预注册客户端与客户端ID元数据文档（CIMD），计划在2027年夏季后彻底移除动态客户端注册（DCR），并采用RFC 9207防止发行者混淆。规范同时确立了“活跃、已弃用、已移除”的功能生命周期，确保弃用项至少维持12个月兼容窗口，如Roots、Sampling和旧版HTTP+SSE传输等现已进入弃用过渡期。 生态兼容与Cloudflare集成实践 Cloudflare Agents SDK已全面支持新规范，其推出的createMcpHandler现已成为官方MCP TypeScript SDK的一部分，支持在Node.js之外的标准运行时（如Bun、Deno、Workers）上运行。用户服务可保留无状态路由与会话路由并行过渡，Sentry与Linear等客户也在生产中验证了新规范在运维简化与多客户端互通方面的优势。

Over the last year and a half, the [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) has become the universal standard for how agents interact with external services. But one of the main criticisms of MCP was that the protocol required a stateful connection between Client and Server. This evolved from MCP’s origins and the [first STDIO transport, designed for local applications](https://modelcontextprotocol.info/blog/transport-future/). When MCP Servers went remote, it translated the stateful connection that worked so well locally and transposed it onto web infrastructure. Building a well-behaved MCP Server meant managing request routing to sticky sessions, holding open streams, message replay, and generally more overhead and complexity than a traditional web server. This changes now. The latest MCP [2026-07-28 specification](https://blog.modelcontextprotocol.io/posts/2026-07-28) was released last week, together with updated TypeScript, Python, Go, and C# SDKs. MCP is now a fully stateless protocol. The specification, interaction model and SDKs have all been rewritten to leverage this new protocol and simplify usage. This means that MCP servers can now run in just a Worker, no stateful infrastructure needed, and customers benefit from the operational simplicity and reduced cost of less moving parts. At Cloudflare, our journey with MCP goes back to the very beginning. In March 2025, we released our McpAgent primitive for [building MCP servers with Cloudflare Agents SDK](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/). Two months later, we ran an [MCP Demo Day](https://blog.cloudflare.com/mcp-demo-day/) showcasing customers such as Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow launching their own MCP Servers along with [13 Cloudflare product-specific MCP servers](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/). A year ago, we released [MCP Server Portals](https://blog.cloudflare.com/zero-trust-mcp-server-portals/), to help enterprises securely adopt MCP in their organisations. [Cloudflare Durable Objects](https://developers.cloudflare.com/durable-objects/) were uniquely positioned to be the best place to host these new applications. They are stateful servers that combine compute, persistent transactional storage (via embedded SQLite), and real-time coordination. They scale up on demand, hibernate when not in use, and keep the stateful connection needed by MCP for Agent-to-Human interaction. `McpAgent` combined with the [Workers OAuth Provider](https://github.com/cloudflare/workers-oauth-provider) package was the best place to host remote MCP servers. However, it became apparent that MCP could be simpler, more efficient, and easier to host, while keeping all capabilities we have grown to love. This release of the MCP 2026-07-28 specification has been months of work by the whole MCP team and the SDK maintainers. In this post, we will outline the protocol changes that matter most for developers, share testimonials from customers running it in production, and explain how to start building with the new specification. Earlier MCP transports began with an `initialize` and `initialized` exchange that would start a session. A server could assign an Mcp-Session-Id header, and every subsequent request had to find the state associated with that session. In practice this meant that autoscaling infrastructure had to preserve active sessions, deployments had to drain or migrate them, and losing an active instance could force clients to reconnect or lead to broken sessions. Serverless platforms could run MCP servers, but only by adding coordination for a protocol session that most interactions never even needed. The new protocol removes the required handshake, the `Mcp-Session-Id` header, and protocol sessions from the core request path. Each request carries the protocol version, client identity, and client capabilities it needs. A client that wants to inspect a server before making another request can call `server/discover`, but this is optional. That simple detail changes how an MCP server can be deployed. A request can arrive at a server, invoke a tool, prompt, or resource, and simply return the result. There is no protocol session to store. This removes a huge part of MCP complexity, while preserving all the functionality that’s expected from it, making MCP servers easier to deploy, scale, and maintain over time. This new specification thus also removes the need for `McpAgent`. While Durable Objects remain the right primitive when an application itself needs state, MCP itself no longer requires a Durable Object to speak the protocol. Servers can scale faster on request scoped infrastructure such as Cloudflare Workers. [Cloudflare's Agents SDK has supported the new specification since day one](https://developers.cloudflare.com/changelog/post/2026-07-27-agents-sdk-v0.20.0-mcp-sdk-v2/). Customers and partners have used the release candidate on Cloudflare before the specification was finalized, giving us confidence that the [migration path](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/) from `McpAgent` to the new `createMcpHandler` (see below) works with production traffic. An MCP server sometimes needs more information before it can finish a request. For example, a deployment tool may need approval before releasing to production. A design tool may need the user to choose colors. A billing tool may need confirmation before issuing a refund. MCP calls this interaction an [elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation). Previously, server-initiated requests such as `elicitation/create` depended on an open stream. Deployment of such a server requires balancing the complexity around streams, cost, and request timeouts. The new protocol reworks this with [Multi Round-Trip Requests (MRTR)](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr). A server can return an `input_required` result that describes what it needs. The client collects the answer and retries the operation with that input. The original operation can then complete, without either side preserving a transport session between those requests. This is a breaking change from the old way of doing elicitations. However, it is operationally much simpler to implement, and we believe that it will allow more developers to make use of this capability to build rich agentic applications. MCP requests are JSON-RPC messages sent over HTTP, but information about the request previously lived only inside the JSON body. A gateway had to parse that body to learn whether a request called `tools/list`, invoked a tool, or read a resource. The new specification requires `Mcp-Method` and `Mcp-Name` headers on Streamable HTTP requests. For example, a tool invocation can look like this: A gateway, rate limiter, or Web Application Firewall can now make decisions from headers without parsing arbitrary JSON. Operators can apply different rules to different methods or record tool-level metrics using the same HTTP primitives they already use elsewhere. The specification also adds `ttlMs` and `cacheScope` hints to results from `tools/list`, `prompts/list`, `resources/list`, and `resources/read`. Tool catalogs are deterministically ordered, allowing clients to reuse them while keeping upstream prompt caches stable across reconnects. The new specification also tightens MCP authorization. MCP now prefers pre-registered clients when the server and client already have a relationship, then [Client ID Metadata Documents](<https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents)>) (CIMD) for dynamic registrations, with Dynamic Client Registration (DCR) as a fallback. DCR is deprecated for new implementations and is slated for removal after summer 2027. The specification also adopts [RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207) issuer identification. An authorization server advertises `authorization_response_iss_parameter_supported: true` and includes iss in successful authorization responses. The client compares it with the issuer discovered before starting the authorization flow. This prevents an authorization response from one issuer from being confused with a response from another. There are several less visible changes that close gaps in production deployments. MCP clients now send the canonical server URI as the RFC 8707 `resource` in authorization and token requests. Tokens must be issued for, and accepted only by, that audience. [Workers OAuth Provider](https://github.com/cloudflare/workers-oauth-provider) implements all these requirements for MCP servers on Workers. Just wrap your handler functions like so: The technical changes are only part of this release. MCP 2026-07-28 also introduces a formal feature lifecycle. Features are classified as Active, Deprecated, or Removed. A deprecated feature must remain available for at least 12 months before it can be removed. Roots, Sampling, Logging, Dynamic Client Registration, and the legacy HTTP+SSE transport are deprecated in this release, but existing implementations have a defined migration window. This policy gives teams a minimum amount of time to plan upgrades rather than react to sudden removals. It also gives the core protocol room to stabilize. New ideas can move faster through the new extensions framework without immediately becoming part of the core protocol. [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview) and [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) are already extensions, while [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview) have been moved over to provide a path for reliable, long-running work. Implementers can adopt those capabilities as and when needed. In November 2025, we introduced `createMcpHandler` to our Agents SDK, built on an experimental stateless mode in the MCP TypeScript SDK. This let MCP servers that only made use of tools, prompts, and resources be deployed to a Cloudflare Worker for lower complexity, cost and easier deployments. We are happy to see `createMcpHandler` graduate into [the official MCP TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/server/src/server/createMcpHandler.ts#L604) with this release! In early 2026, we also worked with MCP maintainers on replatforming the MCP TypeScript SDK from Node.js to Web Standards, helping to improve interoperability with alternative JavaScript runtimes like Bun, Deno, and Cloudflare Workers. We contributed bundling, runtime shims, and split packages in the TypeScript SDK, lowering deployment sizes and benefitting the whole ecosystem. Customers can migrate to the new specification whilst keeping backward compatibility with older specifications. The `/mcp` endpoint accepts both the new protocol and stateless requests from 2025 Streamable HTTP clients, so most clients can reconnect without configuration changes. For example, in February we released our Code Mode [MCP Server for the entire Cloudflare API](https://blog.cloudflare.com/code-mode-mcp/) using this unofficial stateless mode and the (catchy) `WebStandardsStreamableHTTPServerTransport`. Since then, it has scaled up to thousands of requests per second and served billions of tool calls. Here is the shape of a minimal server using the official SDK and the [Cloudflare Agents SDK](https://developers.cloudflare.com/agents/): Servers that truly depend on legacy protocol sessions, server-to-client requests, or standalone streams need a more deliberate migration. They can run a strict stateless route beside the existing sessionful route, move features over, allow active sessions to drain, and then remove the legacy path during the deprecation period. Our [MCP SDK v2 migration guide](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/) covers that process. For MCP clients the process is even easier: just upgrade your version of agents, and it will just work. The `createMcpHandler` API began in the Agents SDK, and will continue to live there. We will also continue to wrap the upstream handler to provide a Worker-focused interface with functional defaults and richer interaction patterns than the lower level MCP TypeScript SDK. David Cramer, co-founder and chief product officer at [Sentry](https://sentry.io/), is a noted voice on both [the promise of MCP](https://cra.mr/mcp-skills-and-agents/) and its [early opportunities for improvement](https://cra.mr/mcp-is-not-good-yet/). In his early real-world experience, the latest MCP spec delivers on that promise while addressing the early criticism. "We built Sentry's MCP on Cloudflare's SDK. Big fans,” Cramer told us. “We went live with this new one before the 7-28 spec was even finalized, and it didn't break prod. Big fans of that, too. 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](https://linear.app/) builds a fast, modern issue tracking and project management tool. They’ve adopted MCP to let agents access Linear data in a simple and secure way. “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. Linear's stance has always been to make your Linear data accessible wherever you need it and the shared spec makes that possible without building hundreds of integrations.” [Anthropic](https://www.anthropic.com/) created MCP and donated it to the [Agentic AI Foundation](https://aaif.io/). For the team that started the protocol, the new spec is a measure of how far it has come, and of how much the community now carries it forward. “We donated MCP to the Agentic AI Foundation so it could become open, vendor-neutral infrastructure for the whole ecosystem. MCP is now foundational for agentic software. It’s the layer applications build on to connect with the tools and data people rely on every day and this is the most significant advance to the protocol since launch. Clients gain meaningful performance with minimal engineering work. 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. We can't wait to see what developers build on MCP." said David Soria Parra, Co-creator and Lead Maintainer of MCP, and Member of Technical Staff at Anthropic. The new MCP specification is available for both clients and servers on Cloudflare today. You can run a stateless MCP server in a [Cloudflare Worker](https://developers.cloudflare.com/workers/), secured with [Workers OAuth Provider](https://github.com/cloudflare/workers-oauth-provider) and connect to an MCP client in an `Agent`. Use [Cloudflare Durable Objects](https://developers.cloudflare.com/durable-objects/) when your application actually needs coordinated state, and serve new and legacy stateless clients from the same route while users migrate. Install the latest [Agents SDK](https://developers.cloudflare.com/agents/) and the MCP TypeScript server SDK, follow the [migration guide](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/), or start with the `createMcpHandler` [documentation](https://developers.cloudflare.com/agents/model-context-protocol/apis/handler-api/). You can also connect to Cloudflare's [MCP servers](https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/#product-specific-mcp-servers), which already support the new specification. MCP no longer needs stateful infrastructure to do useful, interactive work. Servers can run as an ordinary HTTP workload on Workers, close to users, with the scale, security, and observability primitives developers use for the rest of the web.