Can a Cloudflare MCP server delete production infrastructure?

Some can. The Workers Bindings server exposes r2_bucket_delete, d1_database_delete and kv_namespace_delete, and the unified API server fronts the whole Cloudflare API, so it can reach zone, DNS and Worker deletion. The read-only servers (Radar, Docs, Observability, analytics) cannot change anything. Access is bounded by the OAuth scopes or API-token permissions you grant.

Is deleting a D1 database or R2 bucket reversible?

No — the data is gone. A guard that later recreates the database or bucket restores the container, not its contents. That is why the honest control for these actions is a human checkpoint before the delete, not a promised rollback.

MCP field guide / Cloudflare

// mcp field guide · infrastructure

Cloudflare MCP servers

Cloudflare ships a family of MCP servers, and they sit at opposite ends of the risk spectrum. Some only read (Radar, Docs, analytics) — wrapping those in an approval gate is theater. Others (Workers Bindings, the unified API server) can delete an R2 bucket, a D1 database, or a whole zone. Here's which is which.

Maintainer: Cloudflare (official) Repo: cloudflare/mcp-server-cloudflare · *.mcp.cloudflare.com Auth: OAuth / scoped API token

GUARD FIT · READ-ONLY SERVERS

PASS-THROUGH

Radar, Docs, Observability, DNS/GraphQL analytics, Audit Logs, CASB detection — surface findings, change nothing. Gating them is friction.

GUARD FIT · WRITE / DEPLOY SERVERS

STRONG

Workers Bindings + the unified API server can delete buckets, databases, DNS records and zones — irreversible, agent-initiated infra changes.

Overall fit: STRONG for the write/deploy servers, weak for the observational ones — the family splits cleanly.

A family, not one server

Cloudflare's servers are hosted remotes on *.mcp.cloudflare.com, authenticated per-user via OAuth (or a scoped API token). Two tiers matter:¹²

Product-specific servers — one endpoint each: Workers Bindings, Workers Builds, Observability, Radar, Documentation, Browser Rendering, AI Gateway, Logpush, Audit Logs, DNS Analytics, and more.
The unified API server (mcp.cloudflare.com/mcp) — a single endpoint fronting essentially the entire Cloudflare API (~2,500 endpoints) via a search-then-execute pattern.

Tools by risk surface

Tier	Where / tools
read-only	Radar, Docs, Observability, DNS Analytics, GraphQL analytics, Audit Logs, CASB (detection); Workers Bindings read subset — `r2_buckets_list`, `d1_databases_list`, `kv_namespaces_list`, `hyperdrive_configs_list`, `*_get`
mutating	Workers Bindings — `r2_bucket_create`, `d1_database_create`, `kv_namespace_create/update`, `hyperdrive_config_create/edit`, `d1_database_query` (read OR write); Builds / Sandbox; unified API — create/update DNS, deploy Workers, edit config
destructive	Workers Bindings — `r2_bucket_delete`, `d1_database_delete`, `kv_namespace_delete`, `hyperdrive_config_delete`; unified API — delete zone / DNS records / Worker scripts (names resolved dynamically)

Two things to get right. (1) d1_database_query is the classic ambiguous tool — a SELECT or a DROP TABLE under the same name; risk lives in the SQL. (2) The unified API server is the sharpest edge: one endpoint that can reach the whole destructive surface, so classification must key off the resolved underlying operation, not the outer call. Specific delete-tool names there are resolved at runtime and we mark them UNVERIFIED rather than list guesses.

Real use cases

Provision an app. "Spin up a Worker with a D1 database and R2 bucket" → Workers Bindings creates the primitives and wires bindings.

Debug a deploy. "Why are my Workers 5xx-ing since the last deploy?" → Observability + Builds read logs/analytics.

Internet insights (read-only). "Top domains / traffic trend this week?" → Radar — pure analytics, no account writes.

Where a human-approval guard fits

Let the observational servers flow. Radar, Docs, Observability, analytics and Audit Logs don't change state — a guard should classify them read-only and pass them through (ChronoMCP's cascade does exactly this on readOnlyHint/annotations). An approval gate on a docs lookup is theater.

Gate the account/infra-mutating servers. Workers Bindings and the unified API server hold genuine delete power: r2_bucket_delete, d1_database_delete, kv_namespace_delete, a DROP slipping through d1_database_query, or a zone/DNS delete through the unified server. These map onto risk tiers — *_delete and zone/DNS deletion → destructive (require approval, report as irreversible); *_create/*_update/deploy → mutating (approve, compensable-by-delete with the honest caveat that delete-as-rollback loses any data written after create).

The irreversibility line: a deleted D1 database or R2 bucket's data is gone — recreating the container doesn't bring the contents back. Access scoping (a read-only API token) is a real first line of defense; a guard adds the finer, per-call human checkpoint on the destructive verbs. Compensation is not undo, at infra scale.

Gate the deletes, pass the analytics

ChronoMCP holds *_delete and destructive SQL for a human while Radar/Docs/Observability flow straight through.

Read the quickstart → More MCP profiles

Sources

Cloudflare — official MCP servers repo (server list, Workers Bindings tool source): github.com/cloudflare/mcp-server-cloudflare
Cloudflare docs — servers-for-Cloudflare catalog (endpoints): developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare
Launch announcement: blog.cloudflare.com/thirteen-new-mcp-servers-from-cloudflare

Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Cloudflare. Verified tool names are from Workers Bindings source; the unified server resolves tools dynamically (destructive reach documented, exact names not enumerated). Capabilities reflect sources current as of Aug 2026 — check the source links.