serverless runtimes for hosting MCP servers
MCP has moved through three distinct transport eras, each carrying different hosting implications.
Stdio suited local development and testing, required no network infrastructure, and is largely irrelevant to production deployment decisions. Server-Sent Events held long-lived connections between client and server. SSE worked conceptually but fought standard serverless scaling in practice: load balancers route traffic across instances, and SSE required sticky sessions to maintain connection continuity. That tension was structural, not a configuration problem anyone could tune away.
Streamable HTTP, introduced in the 2025 specification, was the first transport designed explicitly for remote deployment. It unlocked production use at meaningful scale, but stateful session management at the application layer remained a constraint. An MCP server handling multiple concurrent clients still needed something, whether a Durable Object, a Redis-backed session store, or sticky routing, to maintain context across requests from the same session.
The July 2026 specification release candidate is the inflection point the ecosystem has been building toward. Six Session Evolution Proposals work in concert to remove the requirement for sticky sessions, shared session stores, and deep packet inspection at the gateway. Traffic can now route on an Mcp-Method header. Clients can cache tools/list responses for a server-specified TTL. A server that previously required coordinated session infrastructure can now, in the common case, run as a plain stateless function.
But what if your application logic is itself stateful, regardless of what the protocol requires? That question has real infrastructure consequences and gets less attention than it deserves.
The Tasks extension completes the stateless lifecycle. Rather than holding a connection open for the duration of a long-running tool call, a server responds to tools/call with a task handle. The client polls with tasks/get, tasks/update, and tasks/cancel. Long-running operations are decoupled from held connections entirely, removing one of the last structural arguments for stateful server runtimes at the protocol layer.
Two other changes in the July 2026 spec carry real infrastructure weight. Authorization alignment with OAuth 2.0 and OIDC was tightened; clients must now validate the iss parameter per RFC 9207, which touches any runtime's authentication middleware and token validation logic. W3C Trace Context propagation was also standardized in _meta via SEP-414, meaning distributed traces can now follow a tool call across client SDK, MCP server, and downstream services as a coherent span tree. Before this spec, correlating a broken agent loop meant pulling logs from three separate pipelines and hoping the timestamps were close enough to mean something. I have spent more time on that particular problem than I care to quantify, and the alignment in SEP-414 addresses it at the right layer.
The July 2026 stateless model dramatically expands the set of runtimes capable of hosting MCP cleanly. Cold-start latency, geographic distribution, and connection handling still separate them in practice, and those differences compound in agent workflows in ways they do not in conventional API deployments.
The Four Runtime Requirements That Actually Determine Whether a Deployment Works
The standard framework for evaluating serverless runtimes was built for web APIs. It is not wrong for that purpose. It was just never designed for a workload where the client is an agent running a multi-step plan rather than a human waiting on a page load. The criteria that matter shift accordingly.
Cold-start latency approaching zero. Agents invoke MCP tools synchronously in many workflows. A multi-second cold start does not merely add latency; it can exceed client timeouts and break the agent loop entirely. An April 2026 audit of remote MCP server endpoints found roughly half were completely unresponsive, with only a small fraction fully healthy, and cold-start timeouts were a leading cause. Container-based and isolate-based runtimes have structurally different cold-start profiles. For MCP specifically, that structural difference matters more than it does for most other workloads evaluated against serverless runtimes.
Persistent or resumable connection handling. Even under the stateless July 2026 specification, HTTP connections in agent workflows can be long-lived relative to a typical API call. The runtime must handle these without arbitrary termination. WebSocket support and hibernatable WebSocket patterns become relevant when stateful application logic runs alongside the MCP layer, which happens regularly in practice even when the protocol itself is stateless.
Geographic proximity to both agents and data. Agents calling MCP tools in a loop multiply round-trip costs. A 50ms overhead per tool call is unremarkable in isolation; across a multi-step agent plan with many tool invocations, it accumulates to hundreds of milliseconds. True edge distribution across dozens to hundreds of locations produces meaningfully different outcomes for global user bases than regional distribution across a handful of availability zones.
State management when the application requires it. The MCP protocol is now stateless, but many MCP server implementations are not. They wrap stateful APIs, maintain user context across a conversation, or coordinate multi-step workflows with intermediate results. The runtime's answer to where state lives, whether co-located storage, external key-value, or a managed database, affects both latency and operational complexity. External session stores introduce a network hop and an additional failure surface; co-located or in-process storage avoids both.
Secondary criteria include execution time limits, which the Tasks extension helps but does not entirely eliminate for long-running agentic tasks, ecosystem integration with existing data infrastructure, and pricing model transparency. The distinction between per-request, pre-allocated, and active-consumption pricing models matters more for agentic workloads than for typical APIs because agents spend a meaningful fraction of their time waiting on downstream calls rather than consuming compute. That idle time shows up differently on an invoice depending on the model, and the difference is not trivial at scale.
AWS Lambda: The Right Choice When Your MCP Server Lives Inside the AWS Ecosystem
Lambda's strongest case has always been ecosystem integration, and for MCP that advantage is concrete. Native IAM roles, VPC placement, and triggers from over 200 AWS services mean an MCP server wrapping AWS data sources, S3, DynamoDB, RDS, SQS, can stay within the same secure network perimeter with minimal additional configuration. AWS leaned into this explicitly: the Lambda Tool MCP Server, announced in May 2025, allows AI models to invoke existing Lambda functions as MCP tools without code changes. For teams whose MCP server is essentially a governed interface over existing AWS infrastructure, that composability is genuine.
The cold-start picture is more complicated. Lambda is container-based, not isolate-based. Lambda@Edge runs in a relatively small number of AWS regions, and cold starts there can exceed 100ms in baseline conditions, a meaningful penalty for latency-sensitive agent loops. SnapStart, which extended Python support in 2026, brings cold starts down significantly for compatible workloads. ARM64 and Graviton2 reduce compute costs. These are real improvements, but they require deliberate configuration and carry tradeoffs. You have to earn them; they are not structural characteristics of the runtime you get by default.
The cost implications shifted in August 2025, when AWS began charging for the INIT phase. Cold starts became a direct cost line item, not merely a latency concern. Research across substantial task samples found container re-initialization can consume a significant fraction of total task time. For workloads with bursty or unpredictable traffic patterns, the combination of cold-start latency and cold-start cost warrants modeling before committing to Lambda at scale.
The recommended production pattern for stateless MCP on Lambda uses Streamable HTTP in sessionless mode via AWS Lambda Web Adapter, which aligns with the current specification direction and avoids the session infrastructure overhead of earlier approaches. For inherently stateful MCP workloads, Amazon ECS with Fargate is the more appropriate AWS primitive; ECS Service Connect handles service-to-service communication, and the runtime model supports long-lived connections more naturally than Lambda's execution model does.
AWS AgentCore Runtime, as of May 2026, charges $0.0895 per vCPU-hour (active) and $0.00945 per GB-hour (peak memory). The active-consumption model is a meaningful improvement for agentic workloads over models that charge for idle wait time, and it reflects AWS's recognition that agents consume compute differently than synchronous API handlers do.
Lambda is defensible when the MCP server is tightly coupled to AWS services, when enterprise governance requires AWS-native IAM and audit trails, or when SnapStart and ARM64 pricing have been validated against the workload's actual traffic shape. The argument weakens when global latency, isolate-speed cold starts, or operational simplicity are the primary constraints.
Cloudflare Workers: How Edge-Native Architecture Maps onto MCP's Requirements
Workers' fundamental distinction from Lambda is architectural, not a feature difference. Workers use V8 isolates rather than container boot sequences. A single runtime instance runs many isolates simultaneously, each with fully isolated memory and no VM boot cycle. Cold starts are negligible not because Cloudflare has optimized a container boot path but because there is no container boot path. The April 2026 audit finding that roughly half of remote MCP endpoints were unresponsive in production is precisely the kind of failure that isolate architecture prevents structurally, rather than mitigates through configuration.
Geographic distribution follows from the architecture. Workers runs in more than 310 full-featured locations globally. This is not a tiered model where edge nodes forward requests to a smaller number of full-compute regions; each location runs the full runtime. For agent workflows where tool calls happen in tight loops, the difference between serving from a regional cluster and serving from a location tens of milliseconds from the client is not a benchmark curiosity. It accumulates across every step of a multi-step plan.
On MCP protocol alignment: Cloudflare released the McpAgent primitive in March 2025 for stateful MCP workflows. The July 2026 stateless specification removes the requirement for Durable Objects at the protocol layer; a plain Worker is now sufficient for spec-compliant MCP servers. Cloudflare's own MCP servers already support the 2026-07-28 specification, handling stateless requests from current Streamable HTTP clients with each request running on a fresh stateless server instance.
When the application itself needs state, Durable Objects remain the correct primitive. Co-located SQLite storage keeps state next to compute, eliminating the external Redis hop. Hibernatable WebSockets maintain connection continuity while the object sleeps, meaning a long-lived connection does not hold compute resources during idle periods. Durable Object instances can be provisioned per user, per session, or per resource, with no practical ceiling on instance count.
The broader ecosystem for AI agent workloads on Workers is cohesive in a way that is easy to underestimate until you have spent time stitching together services from multiple vendors. Workers AI provides inference over open-source models from Meta, Mistral, Google, and Qwen on the same network. Cloudflare Sandboxes enable isolated code execution for tool-use patterns that require it. Running MCP servers, inference, storage, and security posture on one network eliminates an entire category of latency and operational overhead as agentic architectures grow in complexity.
Cloudflare's MCP Demo Day in May 2025 featured production deployments from Asana, Atlassian, Block, Intercom, Linear, PayPal, Sentry, Stripe, and Webflow, among others. That roster reflects production viability and operational maturity, not just benchmark potential.
The pricing model starts with a free tier covering substantial daily request volume; the paid tier begins at a low monthly rate with no charge for idle time. For workloads with variable traffic, the consumption model avoids the pre-allocation decisions that make other serverless pricing harder to forecast when agents behave unpredictably, which is common.
What Stateful MCP Workloads Still Require and How to Think About Them
The distinction to hold clearly: MCP the protocol is stateless as of the July 2026 specification. MCP servers as applications are often not. Conflating the two leads to infrastructure decisions that look right on paper and fail in production, usually at the worst possible moment.
Inherently stateful MCP server behavior is common. Wrapping a database with session-level query context, maintaining user preferences across a conversation, coordinating a multi-step workflow with intermediate results held in memory: these are application architecture choices that persist regardless of what the protocol layer requires. Early MCP SDK limitations compounded this; there was no official support for external session persistence, and requests routed to the wrong instance silently lost session context. Teams that hit that ceiling had to build around it in ways that created technical debt they are still servicing.
The November 2025 specification added asynchronous operations and formal server identity verification, enabling long-running tasks to be initiated and retrieved without holding a connection. This directly informs how stateful logic should be structured: offload state to co-located or purpose-built storage rather than holding it in runtime memory or in a live connection.
On Workers, the pattern is Durable Objects with co-located SQLite for persistent state and Hibernatable WebSockets for connection continuity without resource cost during idle periods. On Lambda and ECS, the analogous pattern involves DynamoDB or ElastiCache, with the additional network hop and operational surface that implies. The difference is in the latency profile and the operational complexity required to sustain it at scale.
The Tasks extension in the July 2026 specification is the right model for long-running stateful operations. Returning a task handle immediately and letting the client poll avoids holding a connection and plays well with any serverless runtime's execution time constraints. Developers who design stateful MCP servers around the Tasks pattern rather than around held connections will encounter fewer scaling problems across any runtime they choose. The effort to restructure around that pattern early is consistently cheaper than restructuring it under production pressure.
The more useful design question is not "does the MCP protocol require state?" That question has been answered. It is "does my application require state, and if so, where does that state live relative to my compute?" Answering the second question correctly determines whether the stateless July 2026 protocol simplifies your infrastructure or merely moves the complexity one layer down.
How to Match Your MCP Server's Workload Profile to a Runtime
The decision is not about which runtime is abstractly superior. It is about alignment between a runtime's structural characteristics and a workload's actual shape. Misalignments surface at the worst possible time, when the workload is real and the traffic is not predictable.
Cloudflare Workers fits when the user base is global and round-trip latency to any single region would compound visibly across tool calls. When cold starts cannot be tolerated and traffic is unpredictable or bursty, isolate architecture removes a whole category of problem structurally rather than mitigating it through configuration. When operational simplicity matters, one platform for compute, state, and inference eliminates integration overhead that grows non-linearly as agentic architectures scale. For new builds targeting the July 2026 stateless specification, a plain Worker without Durable Objects is sufficient for protocol compliance, which makes Workers a low-friction starting point rather than an aspirational one.
AWS Lambda fits when the MCP server is tightly coupled to AWS-native data sources and keeping compute within the same network has clear security and latency benefits. Enterprise environments with existing IAM governance, compliance audit requirements, and significant AWS tooling investment will find Lambda's ecosystem integration worth the cold-start tradeoffs, particularly with SnapStart for eligible runtimes. Workloads that have validated their traffic shape against Lambda's pricing model and found it favorable have a reasonable case to stay there.
Container-based deployments, ECS, Fargate, and similar managed container services, fit when the MCP server has complex stateful requirements that exceed what serverless primitives can handle cleanly: long-held WebSocket connections at scale, custom networking configurations, or workloads in regulated industries where connection-level audit trails and fine-grained resource controls are non-negotiable. The operational overhead is real, but so are the capabilities that serverless runtimes abstract away, and some applications genuinely need those capabilities.
What the July 2026 specification has done is reduce the protocol-level constraints on runtime selection significantly. What remains are application-level concerns: where state lives, how far compute is from clients, and how the runtime behaves when a request arrives before it is warm. Agents are less forgiving of latency and failure than human users, which makes those concerns more consequential than they appear in a prototype. The runtime that looks adequate against a small test can become structurally constraining at production scale, and the cost of reversing that decision arrives precisely when you have the least capacity to absorb it.
