DEV Community: Taha Echakiri

What Stateless MCP Simplifies and Leaves Exposed

Taha Echakiri — Sun, 13 Sep 2026 14:58:22 +0000

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-Name headers, 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.

Meta Put a Proxy in Front of ZippyDB. The Real Win Is Control of the Mesh

Taha Echakiri — Sun, 13 Sep 2026 05:47:03 +0000

TL;DR

Meta’s ZGateway is a stateless proxy tier placed between ZippyDB clients and the ZServer fleet. The immediate problem is a connection mesh that becomes fragile when a key-value store serves a client population of more than a million hosts: one client can touch tens of thousands of shards, and the resulting TLS connections consume resources on both sides. ZGateway bounds that relationship into two managed hops, then uses the shared vantage point to batch and coalesce requests, apply admission control, balance uneven hosts, cache hot reads, and route around regional pressure. Meta says the tier handles more than 1 billion operations per second, carries about 40% of ZippyDB traffic, and adds about 6% computational overhead to an average use case. Netics’ reading is that the proxy is not primarily a speed trick. It is a way to move policy, failure containment, and operational visibility out of a sprawling client fleet and into a tier the platform team can actually control.

Meta Engineering official image introducing ZGateway in front of ZippyDB. Source: Meta Engineering.

The architecture problem was the client fleet

Meta’s official account starts with an uncomfortable scale asymmetry. ZippyDB is the company’s most widely used key-value store, backing product metadata, counters, and configuration. Its clients can be more than a million hosts owned by hundreds of teams, and those clients cannot all be changed quickly or on one common schedule. That is not an ordinary database-client problem. It is a coordination problem disguised as a connection problem.

In the direct-access model, each client connects to the database hosts it needs. A single client can touch tens of thousands of distinct shards during a stable window. Those shards are spread across hundreds of thousands of database hosts. The result is a dense many-to-many mesh of TLS connections, with a typical client holding tens of thousands of outbound connections and a typical database host accepting tens of thousands of inbound connections.

The important detail is that most of those connections are idle much of the time, but they still consume memory, CPU, and file descriptors at both ends. As more client cohorts arrive, inbound pressure grows across the database fleet. A restart or deployment can make the situation worse by reducing connection reuse and triggering a wave of new connections. Meta says it traced host crashes caused by file-descriptor exhaustion and out-of-memory conditions to this pattern. In one incident described in the source, a routing bug caused every client to open a connection per shard; hosts crossed their file-descriptor limits and the fleet entered a reboot loop.

The part of the announcement worth carrying into smaller infrastructure discussions is the scaling boundary. A direct path can be perfectly sensible early in a system’s life. It becomes a liability when the client population grows faster than the team can coordinate client behavior. At that point, “just improve the library” is not a complete answer, because the library exists in too many binaries, owned by too many groups.

ZGateway turns a mesh into a managed boundary

ZGateway is Meta’s answer: a stateless proxy between clients and ZServer. Meta says it handles greater than 1 billion operations per second, carries about 40% of ZippyDB traffic, and is projected to pass 60%, while adding about 6% computational overhead to an average use case. It runs in regional tiers discovered through ServiceRouter and comes in two forms that share one pipeline: a pure proxy and a read-through cache. The engine is Meta’s thick C++ client, with one internal client per use case.

The request path makes the design concrete. A client uses a sticky connection to a regional gateway host. The gateway terminates TLS, authorizes the request against the use case’s ACLs, applies per-tenant admission control, validation, and shaping, resolves the shard, checks a local cache where applicable, and batches or coalesces work headed for the same shard. The embedded client sends the request to the correct replicas. Responses are demultiplexed back to callers, while per-use-case metrics, traces, and quota usage are recorded.

Not everything moves into the proxy. TLS remains in the Thrift/ServiceRouter stack. The shard locator keeps key-to-shard mapping. Replica selection and hedging remain in the embedded client. This boundary matters: ZGateway owns traffic management without pretending to be a replacement database client. That is a healthier pattern than adding a second, subtly divergent implementation of every client feature.

The connection count changes asymmetrically. Clients keep a sticky pool to regional gateway hosts, and ZServers accept connections only from the gateway fleet, whose size Meta controls. The source’s round-number model estimates an approximately 19x reduction in total persistent connections. But the multiplication factor is not the central result. Meta’s stronger claim is about scaling behavior: in the direct model, backend fan-in grows with the client population; behind ZGateway, it is approximately tied to regions and shard density per host. The unbounded variable becomes a bounded fleet-management problem.

Batching is a cross-client capability

A gateway can combine work that no individual client library can see. ZGateway’s shared batcher groups requests headed for the same destination, keyed by use case and physical shard, and merges them into one backend RPC. It also coalesces identical simultaneous reads, fetching a hot key once and distributing the result to callers. A client-side batcher can only see its own process; the gateway sees the stream across clients.

The shared view amortizes fixed RPC costs such as serialization, shard lookup, authorization, and system calls. Larger backend requests mean lower QPS and CPU pressure, while a linger window smooths small bursts. The source also notes a budget effect: when a use case is billed by the QPS it sends, batching stretches its rate-limit budget and can reduce throttling without requiring a change on the caller side.

Netics’ qualification is that batching is not automatically safe. Requests are held in memory until a linger window, size limit, or request-count cap triggers a flush. Oversized or newly migrated batches fall back to individual sends. Idle eviction removes batch-map entries that have exceeded a TTL, while an in-flight cap rejects new executions when slow backend work starts piling up. Those are not incidental implementation details. They are the difference between a useful queue and an OOM amplifier.

The same logic appears in the cache tier. A per-key fill lock prevents a thundering herd from turning one cold miss into many backend reads. A change-data-capture stream invalidates or refills affected entries within an explicit bounded-staleness contract. The source is careful about that contract, and operators should be equally careful: cache value comes from a defined freshness boundary, not from the word “cache” alone.

Netics visual: the proxy’s structural value is fan-in control, not merely one fewer network conversation.

One tier creates several control loops

Once traffic is concentrated, policy can become central rather than copied into a million clients. Migration to ZGateway is controlled through client-side configuration flags scoped by service and shard prefix. A percentage knob ramps eligible traffic, a region filter limits the blast radius, and a global kill switch provides immediate rollback. That is a strong operational detail because it keeps the rollout reversible without requiring a new client binary.

Shared infrastructure also needs tenant isolation. Meta describes Discriminant Load Shedding, where each request enters a per-tenant bucket split by priority and buckets drain round-robin. A noisy tenant fills its own bucket and sheds excess while other buckets continue to drain. CPU concurrency uses an additive-increase/multiplicative-decrease loop to regulate work, and a memory handler provides another OOM guard.

The reported overload test is unusually useful because it illustrates discrimination rather than aggregate success. Above 90% CPU, across roughly 1,350 active tenant buckets, only 6 noisy neighbours were shedding. Roughly 1,344 other buckets executed 99.9% of their requests with zero rejections; goodput stayed near 97–98%, and the machinery consumed about 8% of CPU. This is a source-reported controlled result, not a universal guarantee. Its design lesson is portable: shared capacity should reject the tenant causing the pressure before it rejects everyone.

Statelessness also makes load balancing possible. Any regional gateway host can serve a request, so a control-plane balancer can account for a tier that mixes hosts of roughly 26 to roughly 126 cores. Weighted consistent hashing adjusts ServiceRouter distribution, with damping, clamping, recentering, and throttled changes to limit reshuffling. The source says the balancer is becoming adaptive because a fixed policy does not fit steady drift, task churn, bimodal load, hot outliers, and regional skew equally well.

Resilience moves beyond the local region

ZGateway initially kept failover inside a region. That is good for latency, but it can leave healthy neighbouring capacity idle when one regional tier is under pressure. Meta describes three controlled mechanisms: global routing with a cross-region table, mega-regions grouping nearby regions, and rings that specify which regions back one another up and in what proportion. Each can be enabled per tier and region behind a percentage knob.

The detection signal matters as much as the route. A regional CPU average can smooth over the hot conditions that need an early response, so Meta says failover uses a sharper measure tuned to fire before a region tips into overload. This is a useful reminder for any active-active design: having a second region is not the same as having a trustworthy decision rule for using it.

Netics fact-sheet visual: load shedding, routing and failover require explicit guardrails.

Transactions exposed the other side of centralisation. When customers moved to a thin client, transaction bookkeeping—read sets, scanned ranges, and pending writes—had to move from the thick client into the gateway. Meta first had two parallel implementations, then consolidated onto one behind a flag, in nine phases up to the highest-volume regions, reaching 100% of transaction traffic with no reliability regression. The operational message is clear: centralising a capability is valuable only if there is one correctness path to maintain.

The Netics reading: copy the boundary, not the fleet

The official post points toward agent-operated heuristics, co-location, and a multi-process gateway. Those directions are logical extensions of the same architecture: the tier sees more telemetry, makes more decisions, and can be placed or split according to the workload. They also introduce new failure modes. A control loop needs an owner, a policy boundary, a safe default, and a rollback path. A multi-process design needs explicit fault isolation rather than a diagram that merely looks modular.

Smaller teams should not read Meta’s numbers as an instruction to deploy a proxy in front of every database. The extra hop and another production tier are real costs. The decision becomes attractive when client diversity, connection pressure, uneven tenancy, or migration coordination has outgrown client-local fixes. Start by measuring fan-in, idle connection cost, restart behaviour, hot-key pressure, and the time required to change a client policy. Then decide whether a gateway solves a demonstrated control problem.

The same discipline appears in Netics’ approach to mapping the permissions and ownership boundaries around automation: inventory the moving parts, centralise only what can be governed, and keep an escape hatch. For architecture reviews and infrastructure control-plane decisions, visit Netics Labs.

Originally published on the Netics blog.