Cloudflare CLI Workflows
Use Cloudflare CLIs before MCP. The default order is:
cf technical preview for zones, DNS, Registrar, Accounts, and generated API-backed commands.
wrangler for Workers, Pages, KV, R2, D1, Queues, and local development.
flarectl as a legacy fallback for zones, DNS, firewall access rules, page rules, and cache purge.
cli4 as a generic Cloudflare API v4 fallback.
- Legacy MCP only when the user explicitly enables it locally.
Authentication
Prefer environment variables:
CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID
CLOUDFLARE_ZONE_ID
cf also supports cf auth login, cf auth whoami, and project context in .cfrc. Keep tokens least-privilege and use read-only tokens for inspection whenever possible.
Before recommending a persistent global install, check existing install lanes:
type -a cf wrangler flarectl cli4
which -a cf wrangler flarectl cli4
Prefer one-off execution:
pnpm dlx cf --help
pnpm dlx wrangler --help
Zones and DNS
Use cf for zone and DNS work:
pnpm dlx cf zones list --fields id,name,status --ndjson
pnpm dlx cf dns records list --zone example.com --fields id,type,name,content,proxied --ndjson
pnpm dlx cf dns records create --zone example.com --dryRun --body '{"type":"CNAME","name":"www","content":"project.pages.dev","proxied":true}'
pnpm dlx cf dns records update --zone example.com --dryRun --body '{"type":"TXT","name":"@","content":"verification-string"}'
pnpm dlx cf dns records delete --zone example.com --dryRun --body '{"id":"record-id"}'
Always dry-run creates, updates, deletes, imports, batches, and scan-review operations before applying them. Confirm the exact zone, record ID, record content, and proxied state before making changes.
Use flarectl only when it is already installed and a simple DNS/firewall/page rule operation is clearer there:
flarectl --json zone list
flarectl --json dns list --zone example.com
flarectl --json dns create --zone example.com --name www --type CNAME --content project.pages.dev --proxy
Use cli4 only for API paths not exposed by cf or wrangler:
cli4 /zones/:example.com/dns_records
cli4 --post name=www type=CNAME content=project.pages.dev proxied=true /zones/:example.com/dns_records
Workers, Pages, and Storage
Use wrangler for project-oriented development and deployments:
pnpm dlx wrangler deploy
pnpm dlx wrangler pages deploy ./dist --project-name my-project
pnpm dlx wrangler kv namespace list
pnpm dlx wrangler r2 bucket list
pnpm dlx wrangler d1 list
pnpm dlx wrangler d1 execute <database> --command 'select 1'
Use cf for generated account-level commands or resource APIs that Wrangler does not expose:
pnpm dlx cf agent-context workers
pnpm dlx cf workers routes list --zone example.com --fields id,pattern,script --ndjson
Proactive Assistance
Suggest Cloudflare actions when the user:
- Mentions a domain, DNS record, zone, parked domain, or nameserver change.
- Builds static HTML, a landing page, or a docs site that could deploy to Pages.
- Works on Worker code, KV, R2, D1, Queues, or Vectorize.
- Needs to inspect Cloudflare account resources before changing deployment or DNS.
When the user mentions a specific domain, first inspect whether it exists as a Cloudflare zone, then list the relevant DNS records before proposing changes.
When deploying static content:
- Prepare the local static files.
- Deploy with
pnpm dlx wrangler pages deploy.
- Inspect or add DNS with
pnpm dlx cf dns records ....
- Dry-run DNS mutations before applying them.
- Verify the custom domain and deployment after propagation.
Safety
- Never expose API tokens in code, output, or committed files.
- Confirm before deleting zones, Workers, Pages projects, KV namespaces, R2 buckets, D1 databases, DNS records, or routes.
- Prefer
--fields and --ndjson to keep responses small and structured.
- Prefer
--body for complex cf payloads so the exact request can be reviewed.
- Treat the legacy MCP server as opt-in compatibility tooling, not the default path.
References