TL;DR • Cloudflare argues that the MCP 2026-07-28 specification removes mandatory protocol sessions, making remote MCP servers easier to deploy on ordinary HTTP infrastructure —
Mcp-Method/Mcp-Nameheaders, cache hints, deterministic tool ordering, and tighter authorization (pre-registered clients over Dynamic Client Registration, RFC 9207/8707) all land in this revision. • Statelessness is a real trade-off, not a free win: server-to-client requests and standalone streams no longer live on the core path (the spec itself flags them for deliberate migration), MRTR relocates state rather than eliminating it, and the new headers put tool names in any request-logging proxy or CDN — metadata is data. • Cloudflare's enthusiasm is not neutral: it built its McpAgent primitive in March 2025 and argued Durable Objects were "uniquely positioned" to host MCP, and the new stateless spec makes plain Workers a credible default — a direction that happens to fit its platform. (MCP itself now belongs to the Agentic AI Foundation; the vendor-neutral framing makes the platform pitch even more worth discounting.) Companies still need to decide where their data, permissions, logs, and agent actions live.
What happened
Cloudflare is reacting to a major revision of the Model Context Protocol, published as the 2026-07-28 specification. The company says MCP no longer requires a stateful protocol session for normal interactions. Clients do not need to perform the old initialize exchange, servers no longer have to issue an Mcp-Session-Id, and each request carries the protocol version, client identity, and capabilities required to process it.
That removes several awkward requirements from remote deployments. Operators no longer need sticky routing to preserve sessions, session-aware scaling, stream draining during deployment, or replay logic for connections that disappear. A basic MCP server can receive an HTTP request, invoke a tool, prompt, or resource, return a result, and finish. Cloudflare's recommended implementation is createMcpHandler running inside a Worker, with Durable Objects reserved for applications that actually need coordinated state.
The specification also changes how interactive requests work. Instead of keeping an open stream while waiting for user input, a server can return an input_required result under a mechanism called Multi Round-Trip Requests; the client collects the missing information and retries. MCP adds Mcp-Method and Mcp-Name headers so gateways, rate limiters, firewalls, and observability systems can inspect requests without parsing JSON-RPC bodies, along with cache hints (ttlMs, cacheScope) and deterministic tool ordering for stable prompt caches. Authorization now favors pre-registered clients and Client ID Metadata Documents over Dynamic Client Registration, which is deprecated and slated for removal after summer 2027, with RFC 9207 issuer identification and the RFC 8707 resource parameter now required. Roots, Sampling, Logging, and the legacy HTTP+SSE transport enter a defined deprecation process with a twelve-month minimum.
Netics' take
The stateless change is a good engineering decision. Remote MCP inherited too much of its local STDIO heritage. A local process can keep a connection open because the client and server share a machine, a process supervisor, and usually a fairly simple failure domain. That assumption becomes expensive when the server runs behind a load balancer, autoscaling layer, reverse proxy, WAF, and several independent deployment zones.
For ordinary tool calls, session state was often protocol ceremony rather than useful application state. A request to search a CRM, read an issue, or create a draft does not inherently need a persistent MCP session. Removing the handshake and session identifier makes routing, retries, blue-green deployments, and horizontal scaling much less awkward. It also makes MCP look more like the infrastructure teams already know how to operate: HTTP requests, authentication, timeouts, logs, and rate limits.
But "MCP is now stateless" needs careful wording. The protocol path can be stateless. The business operation often cannot be. A deployment approval, payment refund, long-running report, or multi-step workflow still has state somewhere. With Multi Round-Trip Requests, that state moves into the application, the client, a task store, or an external workflow engine. It has not vanished. The new design makes the boundary explicit, which is useful, but it does not make an approval workflow safe by itself.
The trade-offs deserve more honesty than the announcement gives them. Statelessness is a real loss for some capabilities. The spec itself notes that servers which truly depend on legacy protocol sessions, server-to-client requests, or standalone streams need a more deliberate migration. That qualification matters more than the release notes suggest: if an agent needs to watch a long-running job, the server can no longer rely on an open stream — the client must poll, or you bolt on webhooks. MRTR does not eliminate state; it relocates it. The client now holds the conversation context across retries, and a serverless agent holding state is exactly as fragile as a server holding state. For a deployment-approval click, fine. For genuinely long-lived interactive sessions, it is a step backward in ergonomics.
Stateless MCP moves state from the protocol to the client, task store, or workflow engine.
Cloudflare's framing also deserves a discount. The company is right about the operational advantages, but it benefits directly from MCP becoming a request-scoped workload that fits Workers. Cloudflare built its McpAgent primitive in March 2025 and argued Durable Objects were "uniquely positioned to be the best place to host these new applications" — then the new spec makes a stateless MCP server an ordinary HTTP endpoint, shrinking the role of McpAgent-style wrappers, and the same company presents plain Workers as the simpler, cheaper default. That is a valid product strategy, not an independent architectural verdict. Read every protocol announcement the same way: ask who profits before you ask who is right.
A Cloudflare Worker may be the right choice for a public, low-latency integration with modest data residency requirements. It is not automatically the right choice for a French accounting firm, a Moroccan industrial company, or a Canadian business with strict contractual rules around customer data and subprocessors. Statelessness does not answer where requests are executed, where tool arguments are logged, how secrets are handled, or which jurisdiction can access the resulting data.
The sovereignty point is the part the Workers story buries. A stateless MCP server is an ordinary HTTP endpoint. You do not need Cloudflare, or any serverless platform, to benefit from this spec — you can run it in a Docker container on your own Proxmox node, behind your own reverse proxy, with your own WAF, and any AI client reaches it over HTTPS. For French and European companies with RGPD obligations and legitimate sovereignty concerns, that is the real headline: the protocol just got dramatically easier to self-host, which means agent infrastructure can live on European soil while still speaking the universal language. The stateless protocol belongs to everyone. The Workers pitch belongs to Cloudflare. Keep the two separate.
The authorization changes are more important than the marketing around easy hosting. MCP tools can read mailboxes, modify tickets, create infrastructure, query financial records, and trigger deployments. A clean OAuth flow does not solve excessive permissions. We want separate identities for separate agents, narrow audiences on tokens, explicit scopes, approval gates for destructive actions, and logs that show the human or system principal behind every tool call. "The agent has access to the API" is not governance. It is an incident waiting for a timeline.
The new HTTP headers are useful, too, but they should not be confused with deep observability. Mcp-Method and Mcp-Name let an edge gateway apply different rules to tools/list and tools/call, or rate-limit a sensitive tool without decoding arbitrary JSON. That is a practical improvement. But those headers also put tool names in any proxy or CDN log that records request headers along the path — metadata is data, and if agents call sensitive internal tools, that matters. The fix is not to hide the headers; it is to make sure the logging that matters happens in logs you control. We would still log the authenticated principal, server URI, tool name, request ID, outcome, latency, approval state, and policy decision. Headers can make enforcement easier. They do not replace a policy engine or an audit trail.
The deprecation policy is a welcome sign of maturity, especially for teams that cannot upgrade every integration in one afternoon. Still, companies should not treat the 12-month minimum as a reason to postpone design work. Legacy HTTP+SSE, dynamic registration, and session-dependent features will create migration debt. Run old and new routes side by side where necessary, test reconnection and retry behavior, and identify which operations depend on server-to-client requests or open streams before changing production traffic.
What this means for SMBs
- Use stateless MCP for simple request-response tools first. Search, read, classify, draft, and lookup operations are good candidates. Do not start with production deployment or payment automation.
- Keep application state outside the MCP transport. Store approvals, workflow progress, idempotency keys, and task status in a database or workflow system you control. A stateless endpoint still needs durable records for important actions.
- Treat every tool as an API with a security boundary. Define who can call it, what data it can access, which arguments are allowed, and whether a human must approve the action.
- Choose hosting based on sovereignty and operational reality, not only deployment convenience. A self-hosted MCP server on Docker or Proxmox, a private cloud deployment, or a hybrid design may be more appropriate than a public edge Worker for regulated or sensitive workloads.
- Put an API gateway or reverse proxy in front of remote MCP. Enforce TLS, OAuth audience validation, rate limits, request size limits, IP or network restrictions where appropriate, and separate policies for read and write tools.
- Plan the migration, but do not panic-migrate. Deprecated features have a 12-month minimum window; existing servers and clients keep working. Panic-migrating on a vendor announcement is how outages happen.
- Do not assume STDIO and remote HTTP are interchangeable. STDIO remains useful for local, tightly controlled integrations. Remote servers need stronger identity, secret management, monitoring, timeout handling, and failure recovery.
Bottom line
Cloudflare is right that stateless MCP removes unnecessary infrastructure from many remote integrations, and the new specification is a better foundation for ordinary HTTP workloads. It is wrong if the simplicity of the transport is allowed to stand in for security, sovereignty, or governance. We would start with narrow, read-only tools, run them where the company can control the data path, and add state and human approval only where the business operation requires it. Book a free 30-minute audit and we will help you decide whether MCP belongs on a Worker, in your private infrastructure, or nowhere near production yet.
Source: The next generation of MCP — blog.cloudflare.com. Commentary by Netics.
Original Netics diagram: stateless transport does not replace security strategy.
Explore Netics for practical infrastructure and AI operations guidance.
Originally published on the Netics blog.
Top comments (0)