Cloudflare MCP Skill

Interact with Cloudflare services via MCP: Workers, KV, R2, D1, Hyperdrive, Observability, Builds, Audit, Container Sandbox.

File-based Pipeline (Pass Paths Only)

When integrating troubleshooting/changes into multi-step workflows, persist all evidence and artifacts to disk, passing only paths between agents/sub-agents.

Recommended directory structure (within project): runs/<workflow>/active/<run_id>/

• Input: 01-input/goal.md (symptoms/objectives), 01-input/context.json (account/worker/resource/time_range, etc.)
• Evidence: 02-analysis/observability.md, 02-analysis/audit.md, 02-analysis/screenshots/
• Plan: 03-plans/change-plan.md (write operation plan; must write here and await confirmation first)
• Output: 05-final/report.md (conclusion + evidence chain + tool call summary + next steps)
• Logs: logs/events.jsonl (summary of each tool call)

Permission Tiers (Core Principles)

Tool Reference

Diagnose Tier (Read-only)

Observability

Builds

Browser Rendering (Page Capture)

Audit Logs

Change Tier (Write Operations)

Account

Builds (Settings)

KV

R2

D1

Hyperdrive

Workers

Super Admin Tier (Container Sandbox)

Container Notes: No persistent state, short lifespan, only for temporary tasks (running tests/reproducing issues/parsing data).

Security Rules (Must Follow)

Read Operations

1. Define scope first: account / worker / resource ID
2. No account? Run accounts_list first
3. Conclusions must have evidence chain: logs/screenshots/audit records

Write Operations (Three-step Flow)

1. Plan: Read current state first (list/get)
2. Confirm: Output precise change (name/ID/impact scope), await user confirmation
3. Execute: create/delete/update
4. Verify: audit logs + observability confirm no new errors

Prohibited Actions

• ❌ Execute create/delete/update without confirmation
• ❌ Delete production resources (unless user explicitly says "delete production xxx")
• ❌ Use Super Admin privileges in non-isolated environments
• ❌ Use container sandbox as persistent environment

Operation Workflows

Troubleshooting Flow (Typical)

1. Clarify symptoms → worker name/time range/error type
2. query_worker_observability to pull logs/metrics
3. If build-related → workers_builds_get_build_logs
4. If page-related → get_url_screenshot to reproduce
5. Trace changes → auditlogs_by_account_id
6. Summarize: root cause + evidence + fix recommendations

Resource Management Flow

1. accounts_list → set_active_account
2. List resources (kv_namespaces_list / r2_buckets_list / d1_databases_list)
3. Plan changes → present to user
4. Execute after confirmation
5. Verify: audit logs + observability shows no errors

Output Format

• Language: English
• Structure: Conclusion → Key data/evidence → Tool call summary → Next steps
• Write operations: Must clearly list operations to be executed and impact scope

Example output:

✅ Investigation complete: worker `api-gateway` experienced 5xx spike between 18:00-18:30

Root cause: New code deployed threw TypeError when processing /v2/users
Evidence:
- Logs: 18:02 first occurrence of "Cannot read property 'id' of undefined"
- Audit: 18:00 user dev@example.com deployed new version
- Metrics: error_rate jumped from 0.1% to 12%

Recommendation: Roll back to previous version, or fix /v2/users handler

Error Handling

Scenario Examples

See scenarios.md for 20 real-world development scenarios.