| name | cloudflare |
| description | How to use the Cloudflare connector's tools — listing and inspecting Workers, managing KV namespaces, R2 buckets, D1 databases, and Hyperdrive configs, and running SQL against D1. This is the Workers Bindings server, scoped to one Cloudflare account. Use when the user works with Cloudflare, Workers, KV, R2, D1, Hyperdrive, edge storage, or serverless bindings — NOT DNS records, zones, WAF, page rules, or CDN/cache settings (this server does not expose those). |
You are using the Cloudflare connector (remote MCP — the Workers Bindings
server). Its tools read and manage the Workers application primitives in the
connected user's Cloudflare account: Workers, KV, R2, D1, and Hyperdrive. Apply
this guidance whenever you touch Cloudflare.
Scope check first
- This is the Workers Bindings server. It covers compute/storage bindings:
Workers scripts, KV namespaces, R2 buckets, D1 databases, Hyperdrive configs.
- It does not manage DNS records, zones, WAF, page rules, cache, or
Analytics. If the user asks for those, say so — don't try to force a binding
tool to do it.
Account scoping (the #1 gotcha)
- Credentials may reach multiple accounts. Account-scoped tools need an
account_id. The server lists available accounts in its instructions —
read those, confirm which account the user means, then pass account_id on
each call. Don't guess the account.
- If a tool errors with an account/permission message, it usually means the
account_id is missing or wrong, not that the resource doesn't exist.
Tool naming and find-first
- Tools follow
{resource}_{action}: list/get/create/delete/update, e.g.
kv_namespaces_list, r2_bucket_get, d1_database_create,
hyperdrive_config_edit, workers_list.
- List before you act. Most operations need a resource id or name
(namespace id, bucket name, database id, worker name) — list to resolve a
human reference into the real identifier, then act by id. Don't invent ids.
- To inspect a Worker, list workers first, then fetch its details/code; large
scripts come back as text — summarize rather than dumping the whole file.
D1 queries
d1_database_query runs SQL against a live D1 database by id. Treat it
like any production database connection:
- Resolve the database id via list first; confirm you're on the right one.
- For exploration prefer read-only SQL (
SELECT, PRAGMA table_list,
PRAGMA table_info) and inspect the schema before writing anything.
INSERT/UPDATE/DELETE/DROP/ALTER mutate real data and are not
transactional across calls — get explicit confirmation, scope UPDATE/
DELETE with a precise WHERE, and never run an unbounded mutation.
Care
- Creates and deletes are real account changes.
*_delete on a KV
namespace, R2 bucket, or D1 database is irreversible and destroys the
stored data — confirm the exact target id and the user's intent first; never
bulk-delete.
- Creating resources (namespaces, buckets, databases, Hyperdrive configs) can
incur billing and may collide with names used by deployed Workers.
Confirm name/region before creating.
- Editing a Worker's bindings or a Hyperdrive config affects running
production behavior. State the blast radius before changing live config.
- Prefer read/list/get operations when the user only wants to understand
what's there; reach for create/delete only when the intent is explicit.
