Secure Cloudflare access for AI agents
Access the Cloudflare API — DNS, Workers, R2, Zero Trust — via the official Cloudflare MCP server
Through Cloudflare, agents can discover and call any endpoint across DNS, Workers, R2, and Zero Trust — every call runs through your policies and is logged for audit.
Server URL: https://mcp.cloudflare.com/mcp
Setup
- Navigate to Resources and click Add Resource
- Select Cloudflare from the catalog
- Choose Per-org dynamic registration, the only mode Cloudflare offers — picking the card installs the resource with all tools and scopes pre-configured, registering an OAuth client with Cloudflare as it goes
Each user connects their own Cloudflare account via OAuth when they first use a Cloudflare tool. Navigate to Connections to manage linked accounts.
Credential modes
Cloudflare uses Dynamic Client Registration (RFC 7591) only — the gateway registers a per-organization OAuth client with Cloudflare automatically on first install. SecureAuth-app and Bring-your-own-app modes are not available for this resource. See Credential modes for how this compares to other catalog resources.
Dynamic client registration
This is the mode card labeled Per-org dynamic registration on the Cloudflare configure page. The gateway registers its OAuth client with Cloudflare at install time — no client ID or secret to configure. Each user then connects their own Cloudflare account via a browser OAuth flow the first time they use a Cloudflare tool.
Available tools
Both tools take a single code field — a JavaScript async () => { ... } arrow function that the upstream runs in a sandboxed Dynamic Worker and whose return value becomes the tool result.
| Tool | Description |
|---|---|
search | Run JavaScript against the in-memory Cloudflare OpenAPI spec (all $refs resolved) to discover paths, methods, parameters, and request/response shapes |
execute | Run JavaScript against the Cloudflare API. The sandbox exposes cloudflare.request({method, path, query, body, contentType, rawBody}) and an injected accountId constant |
Cloudflare uses Codemode so two tools cover the entire 2,500+ endpoint API surface (~1k tokens of tool schema instead of the ~1M tokens a one-tool-per-endpoint MCP would need). Typical flow: call search to find the endpoint you want, then execute to call it.
Required scopes
offline_access— maintain access when the user is offline
Policy examples
- Read-only access. Deny
execute, ordered above anything that would allow it — including the seeded Allow all rule your org starts with. Callers can still discover endpoints throughsearchbut cannot mutate. - Constrain what
executemay run. Put the CEL condition on a deny rule that inspects the submitted code, not on an allow rule. A conditional allow whose condition doesn't match falls through to the next matching rule — usually Allow all — and the call is permitted anyway; a conditional deny that can't be evaluated fails closed and denies. See Policies for rule order and the seeded default.
Because
executeruns arbitrary JavaScript against the full Cloudflare API client, per-endpoint authorization at the gateway is coarse. For finer-grained control, combine gateway policies with scope-restricted Cloudflare API tokens or CEL conditions that inspect the request payload.
Next steps
- Create a policy — start from the read-only pattern in Policy examples above.
- Credential modes — see how DCR compares to the other modes catalog resources use.