{"slug": "the-next-generation-of-mcp", "title": "The next generation of MCP", "summary": "The Model Context Protocol (MCP) 2026-07-28 specification, released last week with updated TypeScript, Python, Go, and C# SDKs, makes MCP a fully stateless protocol, removing the required handshake, Mcp-Session-Id header, and protocol sessions from the core request path. Cloudflare, which has supported MCP since March 2025 with its McpAgent primitive and 13 product-specific MCP servers, says this simplifies server deployment by allowing MCP servers to run in a Worker without stateful infrastructure, reducing operational complexity and cost.", "body_md": "# The next generation of MCP\n\nOver 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.\n\nBut 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.\n\nThe 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.\n\n## A new MCP\n\nAt 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\n\n[showcasing customers such as Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow launching their own MCP Servers along with](https://blog.cloudflare.com/mcp-demo-day/)\n\n__MCP Demo Day__[. A year ago, we released](https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/)\n\n__13 Cloudflare product-specific MCP servers__[, to help enterprises securely adopt MCP in their organisations.](https://blog.cloudflare.com/zero-trust-mcp-server-portals/)\n\n__MCP Server Portals__[ 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.\n\n`McpAgent`\n\ncombined 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.\n\nThis 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.\n\n## MCP is now stateless\n\nEarlier MCP transports began with an `initialize`\n\nand `initialized`\n\nexchange 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.\n\nThe new protocol removes the required handshake, the `Mcp-Session-Id`\n\nheader, 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`\n\n, but this is optional.\n\nThat 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.\n\nThis new specification thus also removes the need for `McpAgent`\n\n. 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.\n\n[ 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\n\n[from](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/)\n\n__migration path__`McpAgent`\n\nto the new `createMcpHandler`\n\n(see below) works with production traffic.## Elicitation no longer needs an open stream\n\nAn 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).\n\nPreviously, server-initiated requests such as `elicitation/create`\n\ndepended on an open stream. Deployment of such a server requires balancing the complexity around streams, cost, and request timeouts.\n\nThe new protocol reworks this with [ Multi Round-Trip Requests (MRTR)](https://modelcontextprotocol.io/specification/draft/basic/patterns/mrtr). A server can return an\n\n`input_required`\n\nresult 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.\n\n## HTTP infrastructure understands MCP\n\nMCP 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`\n\n, invoked a tool, or read a resource.\n\nThe new specification requires `Mcp-Method`\n\nand `Mcp-Name`\n\nheaders on Streamable HTTP requests. For example, a tool invocation can look like this:\n\n```\nPOST /mcp HTTP/1.1\nMCP-Protocol-Version: 2026-07-28\nMcp-Method: tools/call\nMcp-Name: search\nContent-Type: application/json\n\n{\n  \"jsonrpc\": \"2.0\",\n  \"id\": 1,\n  \"method\": \"tools/call\",\n  \"params\": {\n    \"name\": \"search\",\n    \"arguments\": { \"q\": \"otters\" }\n  }\n}\n```\n\nA 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.\n\nThe specification also adds `ttlMs`\n\nand `cacheScope`\n\nhints to results from `tools/list`\n\n, `prompts/list`\n\n, `resources/list`\n\n, and `resources/read`\n\n. Tool catalogs are deterministically ordered, allowing clients to reuse them while keeping upstream prompt caches stable across reconnects.\n\n## Authorization continues to evolve\n\nThe 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.\n\nThe specification also adopts [ RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207) issuer identification. An authorization server advertises\n\n`authorization_response_iss_parameter_supported: true`\n\nand 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`\n\nin 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:\n\n``` js\nimport { OAuthProvider } from \"@cloudflare/workers-oauth-provider\";\n\nexport default new OAuthProvider({\n  apiRoute: \"/mcp\",\n  apiHandler: mcpHandler,\n  defaultHandler: authorizationHandler,\n  authorizeEndpoint: \"/authorize\",\n  tokenEndpoint: \"/oauth/token\",\n  clientIdMetadataDocumentEnabled: true,\n  resourceMetadata: {\n    resource: \"https://mcp.example.com/mcp\",\n    authorization_servers: [\"https://mcp.example.com\"],\n    scopes_supported: [\"mcp:read\"],\n  },\n});\n```\n\n## A lifecycle for a maturing standard\n\nThe technical changes are only part of this release. MCP 2026-07-28 also introduces a formal feature lifecycle.\n\nFeatures 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.\n\nThis 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.\n\nNew 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\n\n[are already extensions, while](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization)\n\n__Enterprise-Managed Authorization__[have been moved over to provide a path for reliable, long-running work. Implementers can adopt those capabilities as and when needed.](https://modelcontextprotocol.io/extensions/tasks/overview)\n\n__Tasks__## A new MCP with new SDKs\n\nIn November 2025, we introduced `createMcpHandler`\n\nto 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.\n\nWe are happy to see `createMcpHandler`\n\ngraduate into [ the official MCP TypeScript SDK](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/server/src/server/createMcpHandler.ts#L604) with this release!\n\nIn 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.\n\nCustomers can migrate to the new specification whilst keeping backward compatibility with older specifications. The `/mcp`\n\nendpoint accepts both the new protocol and stateless requests from 2025 Streamable HTTP clients, so most clients can reconnect without configuration changes.\n\nFor 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)\n\n`WebStandardsStreamableHTTPServerTransport`\n\n. 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/):\n\n``` js\nimport { McpServer } from \"@modelcontextprotocol/server\";\nimport { createMcpHandler } from \"agents/mcp/server\";\nimport { z } from \"zod\";\n\nfunction createServer() {\n  const server = new McpServer({\n    name: \"hello-server\",\n    version: \"1.0.0\",\n  });\n\n  server.registerTool(\n    \"hello\",\n    {\n      description: \"Return a greeting\",\n      inputSchema: { name: z.string().optional() },\n    },\n    async ({ name }) => ({\n      content: [\n        {\n          type: \"text\",\n          text: `Hello, ${name ?? \"World\"}!`,\n        },\n      ],\n    }),\n  );\n\n  return server;\n}\n\nexport default {\n  fetch(request, env, ctx) {\n    return createMcpHandler(createServer)(request, env, ctx);\n  },\n}\n```\n\nServers 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.\n\nThe `createMcpHandler`\n\nAPI 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.\n\n## Next gen MCP is already in production\n\nDavid Cramer, co-founder and chief product officer at [ Sentry](https://sentry.io/), is a noted voice on both\n\n[and its](https://cra.mr/mcp-skills-and-agents/)\n\n__the promise of MCP__[. In his early real-world experience, the latest MCP spec delivers on that promise while addressing the early criticism.](https://cra.mr/mcp-is-not-good-yet/)\n\n__early opportunities for improvement__\"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.\"\n\n[ 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.\n\n“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.”\n\n[ Anthropic](https://www.anthropic.com/) created MCP and donated it to the\n\n[. 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.](https://aaif.io/)\n\n__Agentic AI Foundation__“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.\n\nSecurity 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.\n\n## Long live MCP\n\nThe 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\n\n[and connect to an MCP client in an](https://github.com/cloudflare/workers-oauth-provider)\n\n__Workers OAuth Provider__`Agent`\n\n. Use [when your application actually needs coordinated state, and serve new and legacy stateless clients from the same route while users migrate.](https://developers.cloudflare.com/durable-objects/)\n\n__Cloudflare Durable Objects__Install the latest [ Agents SDK](https://developers.cloudflare.com/agents/) and the MCP TypeScript server SDK, follow the\n\n[, or start with the](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/)\n\n__migration guide__`createMcpHandler`\n\n[. You can also connect to Cloudflare's](https://developers.cloudflare.com/agents/model-context-protocol/apis/handler-api/)\n\n__documentation__[, which already support the new specification.](https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/#product-specific-mcp-servers)\n\n__MCP servers__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.", "url": "https://wpnews.pro/news/the-next-generation-of-mcp", "canonical_source": "https://blog.cloudflare.com/mcp-v2/", "published_at": "2026-08-06 13:00:00+00:00", "updated_at": "2026-08-09 12:53:56.466357+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Model Context Protocol", "Cloudflare", "McpAgent", "Workers OAuth Provider", "Asana", "Atlassian", "Block", "Intercom"], "alternates": {"html": "https://wpnews.pro/news/the-next-generation-of-mcp", "markdown": "https://wpnews.pro/news/the-next-generation-of-mcp.md", "text": "https://wpnews.pro/news/the-next-generation-of-mcp.txt", "jsonld": "https://wpnews.pro/news/the-next-generation-of-mcp.jsonld"}}