Cloudflare MCP Servers: Using Them and Hosting Your Own

“Cloudflare MCP server” means two different things. First, Cloudflare runs its own remote MCP servers that let an AI agent work with your Cloudflare account: one server that reaches the whole Cloudflare API through two code-running tools, and product servers for documentation, Workers bindings, Workers Builds, observability, Browser Run, Radar and more. You connect to them by URL and authorize in the browser. Second, Cloudflare’s Agents SDK is a way to host your own remote MCP server on Workers, with an OAuth library for sign-in. The hosting side has changed: the McpAgent class that many tutorials use is now deprecated, and new servers should start from the stateless createMcpHandler.

Cloudflare’s own servers

Cloudflare’s page on its own MCP servers↗ (opens in a new tab) lists them. Each is a Streamable HTTP endpoint at /mcp; older /sse addresses still answer as aliases but no longer serve the deprecated SSE transport, so a client forced to SSE must switch. The ones most people start with:

• Cloudflare API, https://mcp.cloudflare.com/mcp: the whole Cloudflare API, more than 2,500 endpoints across DNS, Workers, R2, Zero Trust and the rest.
• Documentation, https://docs.mcp.cloudflare.com/mcp: current reference information from Cloudflare’s docs.
• Workers Bindings, https://bindings.mcp.cloudflare.com/mcp: for building Workers with storage, AI and compute primitives such as KV, R2 and D1.
• Workers Builds, https://builds.mcp.cloudflare.com/mcp: insight into your Workers builds.
• Observability, https://observability.mcp.cloudflare.com/mcp: your Workers’ logs and analytics, for debugging.
• Browser Run, https://browser.mcp.cloudflare.com/mcp: fetch pages, convert them to Markdown and take screenshots.
• Others for specific products: Radar, Logpush, AI Gateway, AI Search, Audit Logs, DNS Analytics, Digital Experience Monitoring, Cloudflare One CASB, GraphQL analytics, and a server for the Agents SDK docs.

Two names have moved. The server listed as Browser Run lives in the repository folder browser-rendering, and AI Search is served from autorag.mcp.cloudflare.com, its older AutoRAG name. The URLs in the table are the ones to use.

The API server works through code

The API server does not register a tool per endpoint. The cloudflare/mcp repository↗ (opens in a new tab) explains that the model writes JavaScript instead: search queries the OpenAPI spec to find endpoints, execute calls them through a Cloudflare API client in a sandbox, and a docs tool searches the documentation. Cloudflare measures this at about 1,000 tokens of tool definitions, against more than a million for one native tool per endpoint. You can turn it off with ?codemode=false, which registers every endpoint as its own tool and costs far more context; MCP token usage explains why that matters. Results are capped at about 6,000 tokens by default.

Connecting to them

Any client with remote-server support connects by URL. On first use you are sent to Cloudflare to authorize and to choose the permissions the agent gets. In Claude Code:

claude mcp add --transport http cloudflare-api https://mcp.cloudflare.com/mcp
claude mcp add --transport http cloudflare-docs https://docs.mcp.cloudflare.com/mcp
claude mcp add --transport http cloudflare-observability https://observability.mcp.cloudflare.com/mcp

# then, inside Claude Code, sign in to each:
/mcp

In Cursor and other clients that use an mcpServers block, each server is an entry with a url. Cloudflare also bundles its servers with skills in the cloudflare/skills plugin, which Claude Code installs with /plugin marketplace add cloudflare/skills.

For CI and other jobs with no browser, the API server accepts a Cloudflare API token as a bearer token; user tokens and account tokens both work, and tokens with client IP address filtering are not supported yet. Pick permissions with care. The API server can change DNS records, deploy Workers and edit firewall rules, so grant the narrowest token the job needs, and prefer a product server such as Documentation or Observability when that is all the agent should touch. The wider checklist is in MCP security best practices.

Hosting your own MCP server on Workers

The second meaning is running your own server on Cloudflare. How to design and write an MCP server in general is covered in how to build an MCP server; this section is only what is specific to Workers.

The Agents SDK’s MCP handler APIs↗ (opens in a new tab) offer createMcpHandler from agents/mcp/server, built on the MCP TypeScript SDK v2 package @modelcontextprotocol/server. You pass it a factory that builds a fresh server, and it creates one server per request. Cloudflare says this follows the newer protocol model, where version, identity and capabilities travel with every request: nothing is kept in an MCP session, and data that must last goes in a Durable Object, D1, KV or R2 behind an authenticated handle.

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

function createServer() {
  const server = new McpServer({ name: "status-server", version: "1.0.0" });
  server.registerTool(
    "service_status",
    {
      description: "Return the status of one service",
      inputSchema: { service: z.string() },
    },
    async ({ service }) => ({
      content: [{ type: "text", text: service + ": operational" }],
    }),
  );
  return server;
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
} satisfies ExportedHandler;

Pass the factory itself, never one shared server instance. Run it locally with Wrangler, test it in the MCP Inspector, and deploy with npx wrangler@latest deploy; it answers at https://<name>.<account>.workers.dev/mcp. By default the handler serves /mcp and accepts localhost and workers.dev hosts; for a custom domain, list it in allowedHostnames.

McpAgent is deprecated

Many older tutorials build on McpAgent, a stateful server backed by a Durable Object. Cloudflare’s McpAgent reference↗ (opens in a new tab) now calls it deprecated and feature-frozen, kept only while existing servers migrate. Its remote server guide adds that the quick-deploy templates still use the deprecated path and should not be used for a new server; it points to the mcp-worker example instead. A server that relies on MCP session state, pushed requests or stream replay needs a staged migration, serving a stateless route beside the old one until clients move. experimental_createMcpHandler is deprecated as well.

Adding sign-in with the OAuth provider library

A public server with no sign-in is fine for read-only public data. For anything tied to a user, Cloudflare’s Workers OAuth Provider↗ (opens in a new tab), the npm package @cloudflare/workers-oauth-provider, adds OAuth 2.1 to the Worker. It wraps your Worker, sends requests for /mcp to your MCP handler once a valid token is present, and serves /authorize, /token and /register for the client. Your own handler does the actual login, whether that is Cloudflare Access, GitHub, Google, another provider, or your own user system.

• It needs a KV namespace bound as OAUTH_KV. Tokens, codes and secrets are stored only as hashes.
• In a tool, the verified token details, such as client and scopes, arrive at context.http.authInfo, and getMcpAuthContext() returns your application’s own properties, such as the user ID.
• Check permissions in the tool, or register a tool only for users allowed to call it. Cloudflare notes that an unregistered tool is one the model cannot even try.
• Never log or return the raw access token.

How the client side of that sign-in looks, with discovery, dynamic registration and PKCE, is in how MCP sign-in works.

When to host remotely

The general comparison is in remote vs local MCP servers. The Cloudflare-specific question is narrower: is a Worker the right home for your server? It usually is when:

• The server wraps an HTTP API, yours or a vendor’s, and needs nothing from a user’s machine.
• People will use it from Claude on the web, ChatGPT or a phone, which can only reach servers on the internet.
• You want one place to fix a bug or rotate a secret, instead of asking every user to update a local package.
• You already run on Cloudflare, so KV, D1 and Durable Objects are at hand for the state a stateless server keeps elsewhere.

It is the wrong home when the tools need local files, a terminal, or a private network the Worker cannot reach. Keep those local.

Where a task board fits

An agent with the Observability server can find the Worker that started throwing errors after a deploy, and with the Builds server it can see which build shipped it. With fenbs connected as another remote server at https://fenbs.ai/api/mcp, it can search the board, file a bug in To Do with the evidence in the note, and set a priority from 1 to 10; History records the change under the assistant’s name. If a person decides the agent may read Cloudflare but never change DNS or deploy, record that as a rule on the Decisions and rules page, which every connected assistant reads first, and back it with a read-only token. fenbs itself is a remote MCP server with OAuth sign-in and hand-issued tokens; clients that only speak stdio reach it through the npx -y fenbs-mcp bridge.