The Model Context Protocol (MCP) just went stateless, and that change lets developers spin up tiny MCP servers on Cloudflare Workers’ free tier—provided each request stays under the platform’s 10 ms CPU limit.

Why the shift matters

Two recent moves opened the door. First, the MCP core shed its session-based design and now runs without handshakes; any request can be handled by any instance of the code. Second, Cloudflare retired the McpAgent class and now recommends plain request handlers for new servers. Together they eliminate the need for Durable Objects or other stateful storage, which were the main blockers for running MCP on the free plan.

What the free tier can actually do

We built a read-only MCP server that serves Markdown files from a static site. The server implements two tools—list_articles and get_article—using a simple switch statement to route the methods. No heavy calculations, just fetching static assets.

Cloudflare’s CPU accounting differs from total response time. CPU time counts only the cycles spent executing your JavaScript; time spent waiting on network calls or disk reads is excluded. That distinction matters because the free tier caps CPU at 10 ms per request, while total latency can be higher.

Our measurements on the free tier looked like this:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (largest file): 1-2 ms CPU

Even the biggest article used a fraction of the 10 ms budget. The apparent slowdown on the client side came from waiting for the file to be read, not from code execution.

Where the limit bites

The data points to a clear pattern:

  • Data-serving tools (simple reads, listings) comfortably stay under the limit.
  • Compute-heavy tools (parsing, rendering, hashing, or any algorithmic work) can quickly exhaust the 10 ms budget.

If a tool needs more than trivial processing, developers will have to move to a paid Workers plan. The $5 plan raises the limit to 30 seconds per request.

Who wins, who watches the clock

Small sites that already host Markdown files or an RSS feed can expose an MCP endpoint with a single new route and stay on the free plan. That means lower operating costs and fewer moving parts for hobbyists, documentation sites, or low-traffic blogs.

If a tool needs more than trivial processing, developers will have to move to a paid Workers plan.

What to test before you launch

  • Profile your tool: Run a few representative requests and check the CPU meter in Cloudflare’s dashboard.
  • Separate static and dynamic paths: Keep static file serving on the free tier, and route compute-intensive calls to a paid worker or another backend.
  • Watch for hidden latency: Network waits don’t count against CPU, but they still affect user experience. Consider edge caching for the files you serve.

Counter-point: the free plan isn’t limitless

While the stateless core removes the need for Durable Objects, the 10 ms cap remains a hard ceiling. Developers who underestimate the cost of even modest parsing (e.g., markdown to HTML conversion) may hit the limit unexpectedly. The free tier suits “serve-as-is” scenarios, not on-the-fly content generation.

What’s next for MCP on Cloudflare

If your site already has its content in a static bucket, adding an MCP endpoint could be as simple as a few lines of code and a single route. The protocol now aligns with the needs of small servers—a plain HTTP endpoint that can be hosted for free, as long as you stay under the 10 ms CPU ceiling.