An approval-gated Cloudflare operations suite with an optional private Agent Harness: bounded delegation, deterministic verification, OAuth-isolated MCP tools, and verified deploy checks without handing agents raw account credentials.
Latest update - v0.4.2: the live harness now selects reusable skill folders automatically, shows them in the operator console, records them in hashed job packets, supports Google-first source research and an optional user-configured Claude verification pass, and targets learned improvements at reviewable skill revisions. See the latest release.
Cloudflare Ops MCP scans Cloudflare configuration, computes a diff of desired vs current DNS / Email Routing / BIMI / DMARC / SPF / Pages / cache / Turnstile setup, and applies fixes only after explicit approval. It is built for people who want an AI agent to help with Cloudflare safely: scan first, show the plan, then write only when the owner approves.
For repository-connected deployments, see GIT-INTEGRATION.md. The recommended route uses Cloudflare Workers Builds' GitHub App authorization; the MCP does not store a GitHub token.
Cloudflare Ops MCP is especially useful for Cloudflare operators who need repeatable DNS hygiene across many zones: SPF cleanup, DMARC enforcement, BIMI records, MX checks, DKIM discovery, Cloudflare Email Routing, TXT verification records, safe DNS upserts, and audit logs for every approved write.
Unofficial Cloudflare tool. Cloudflare Ops MCP is made by AMH - Artificial Mind Hive, operated by Service Pricer LLC. It is independent, third-party, open-source software. It is not affiliated with, endorsed by, sponsored by, or made by Cloudflare, Inc. "Cloudflare" and "Wrangler" are referenced only to describe compatibility with Cloudflare's platform and official developer tooling. You are responsible for every DNS, Email Routing, DMARC, BIMI, SPF, or Worker change you approve and apply.
No owner's API key in Git or in your client. Public users authorize Cloudflare directly. OAuth access and refresh tokens stay server-side in KV; the connector key is stored only as a SHA-256 hash and is bound to one OAuth grant.
Cloudflare Ops MCP is focused on the Cloudflare tasks that regularly break launches, email trust, bot checks, cache freshness, brand display, and AI-agent workflows:
This is not meant to replace every Cloudflare feature. It is the narrow, safe lane for common Cloudflare ops an operator or AI agent should be allowed to do.
The examples below are intentionally direct. They are not toy examples. They show the exact dry-run -> review -> apply pattern users should follow when fixing real domains.
Use this when an old registrar, parking page, Vercel app, HugeDomains page, or stale A/AAAA records are blocking a Cloudflare Pages custom domain.
Dry-run first:
cfops pages example.com --target project.pages.dev
Apply only after reviewing the delete/create plan:
cfops pages example.com --target project.pages.dev --apply
Wrangler is Cloudflare's official developer CLI. Cloudflare Ops MCP can run without Wrangler as a local CLI/library, but Wrangler is the right path when you want a remote MCP server because it deploys the Worker, stores secrets, tails logs, and manages Cloudflare bindings from the same toolchain Cloudflare documents.
Use the plain CLI when you only need one local terminal to scan or fix a zone.
Cloudflare Ops MCP keeps the write path narrow: scan the target, show the diff, wait for explicit approval, then apply only the requested DNS, DMARC, BIMI, SPF, Email Routing, Pages, cache, or Turnstile change.
Public users connect their own Cloudflare account and receive an opaque cfops_ connector key. Only its hash is stored. Each request resolves to exactly one OAuth grant, user-supplied tenant switching is ignored, refresh tokens remain server-side, and either side can revoke the connection.
The scanner reports SPF, DKIM discovery, DMARC policy, BIMI readiness, MX records, and Cloudflare Email Routing status so an agent or operator can see what is missing before touching production DNS.
For the fastest path, start with SETUP.md. It explains the CLI path, the Wrangler-hosted MCP path, and how users provide their own Cloudflare credentials safely. See PHASES.md for the rollout model, OAUTH.md for hosted Cloudflare OAuth, and ROADMAP.md for the next upgrades.
Scan example.com and explain the DNS and email-auth problems. Do not write anything. Check DMARC, SPF, DKIM, BIMI, MX, and Cloudflare Email Routing. Show me a dry-run to move example.com to project.pages.dev. Preserve email records. Plan a cache purge for these three URLs. Do not apply it. Apply exactly the change I just approved, then verify the live result.
The agent chooses the appropriate MCP tool from its schema. Read-only calls run immediately. Mutation tools return a dry-run diff unless the caller explicitly sends apply: true; users should approve only after reading that diff.
Current v0.4 tools cover DNS, email authentication/routing, Pages cutover, cache purge, Turnstile, token operations, and account diagnostics — plus the AMH WT Agent Harness (agent/): a private companion Worker for bounded research, verification, UI checks, and zero-AI site-health watches. Eight native process folders under skills/ are selected automatically and recorded in each job packet: safe deployment, live verification, email loopback, compact context handoff, refute-first security review, private MCP access, Google source research, and an optional user-configured Claude second opinion. One Durable Object per user keeps a tamper-evident audit chain, friendly reusable agent profiles (Jack is the default office manager), a Continuity Keeper briefing with automatic 4/7/30-day retention, daily model-call limits, schedules, and candidate skill/template revisions that never self-apply. The default Free profile uses @cf/zai-org/glm-4.7-flash with independent @cf/google/gemma-4-26b-a4b-it verification; @cf/moonshotai/kimi-k2.6 is labeled and enabled only as an explicit Workers Paid profile. The authenticated console and optional terminal show live handoffs, names, skills, limits, alerts, and exact recorded model calls without spending another inference. Official Cloudflare API, Workers Builds, Bindings, Observability, and Docs MCP connectors use each operator's own OAuth grant. See AGENT-HARNESS.md, CLOUDFLARE-MCP.md, MAIL-LANDING-GUIDE.md, and RELEASE-GATE.md.
Request: “Deploy my Worker, make sure the nav does not 404 on phone, and verify the confirmation email really comes back.”
For current research, cfops-google-research opens and traces primary sources instead of trusting snippets. Hard claims may also use cfops-claude-verifier as an independent second opinion when the operator has configured that provider; the user's key is never included in the repository.
npm install cloudflare-ops-mcp # or run the CLI without installing: npx cloudflare-ops-mcp scan example.com
Requires Node.js >= 18 (for the built-in global fetch). No other dependencies.
Do not use the Global API Key - it has access to everything, cannot be scoped or time-limited, and there is only one per account.
Put it in your environment (never in a CLI argument or in code):
export CLOUDFLARE_API_TOKEN="your-scoped-token"
or copy .env.example to .env and fill it in:
cp .env.example .env # then load it however you prefer (e.g. `set -a; . ./.env; set +a`)
cloudflare-ops-mcp reads CLOUDFLARE_API_TOKEN from the environment only.
For the public hosted service:
The connector key is not a Cloudflare API token. Its SHA-256 hash maps to one server-side OAuth connection, so it cannot select another user's grant. Cloudflare access and refresh tokens never enter Git, chat, an issue, or the MCP tool arguments.
{
"mcpServers": {
"cloudflareOps": {
"url": "https://cfops.nothingunseen.com/mcp",
"headers": {
"Authorization": "Bearer cfops_YOUR_CONNECTOR_KEY"
}
}
}
}
codex mcp add cloudflare-ops --url https://cfops.nothingunseen.com/mcp \ --bearer-token-env-var CFOPS_CONNECTOR_KEY
Then set CFOPS_CONNECTOR_KEY in your own environment. Do not commit it. See OAUTH.md for status, revocation, refresh behavior, and self-hosting.
Cloudflare Ops MCP does not ship with an API key, shared account, hosted proxy token, or any hidden credentials. Every operator must bring one of these:
Do not ask users to send tokens through chat, issues, logs, or screenshots. If a token is exposed, rotate it in Cloudflare and create a new scoped token.
Wrangler consumes tokens. The official Cloudflare MCP consumes tokens. Nothing in the toolchain manufactures least-privilege tokens on demand — so everyone ends up doing agent work with one big long-lived key. This is the gap mint_scoped_token closes:
This is the flow the vending machine is built for: a strong orchestrator model plans, a cheap model executes.
MCP is model-agnostic by design: any MCP client can point at the hosted Worker endpoint, and any tool-calling LLM can drive that client.
Read-only diagnostics for the failure modes that actually burn multi-account operators:
cfops <command> <domain> [options]
scan <domain>Full read-only snapshot: DNS, SPF, DKIM, DMARC, BIMI, Email Routing.plan <domain> [--inbox x@y]Report desired vs current email-auth posture (no writes).dns <domain> --type T --name N --content C [--ttl n] [--proxied] [--apply]Upsert a DNS record (create / update / no-op).email <domain> --forward a@b=to@c [--catch-all to@c] [--apply]Plan/apply Email Routing forward rules + catch-all.dmarc <domain> --policy quarantine [--rua mailto:x] [--pct 25] [--apply]Change only the DMARC p= (and rua/pct), safely.bimi <domain> --logo <url> [--vmc <url>] [--apply] [--force]Set default._bimi TXT (refuses if DMARC=none unless --force).verify <domain>Verify the API token, then resolve the zone.Global flags: --apply (perform the write; default is dry-run), --force (BIMI DMARC override / delete), --audit <path> (audit log location), -h/--help.
Everything is a dry-run until you add --apply. BIMI needs a hosted SVG Tiny-PS logo URL that you supply via --logo (and, for Gmail/Apple Mail display, a VMC/CMC via --vmc).
Assume a scoped token is exported and each domain is a zone in your account.
First, dry-run (writes nothing - shows the diff):
cfops bimi example.com --logo https://example.com/bimi/logo.svg
BIMI for example.com (DMARC p=quarantine, enforcing=true): new record: v=BIMI1; l=https://example.com/bimi/logo.svg action: create (dry-run) record: TXT default._bimi.example.com - before: (record does not exist) + after: content="v=BIMI1; l=https://example.com/bimi/logo.svg" ttl=1 warn: No VMC/CMC supplied (a=). Gmail and Apple Mail require a VMC/CMC to display the logo; Yahoo/AOL do not. Dry-run only. Re-run with --apply to write this change.
Then apply:
cfops bimi example.com --logo https://example.com/bimi/logo.svg --apply
If example.com's DMARC were still at p=none, the apply would be blocked with an error telling you to raise DMARC first (or pass --force). Fix DMARC, then set BIMI.
Dry-run:
cfops bimi example.org --logo https://example.org/bimi/logo.svg
Apply once the diff looks right:
cfops bimi example.org --logo https://example.org/bimi/logo.svg --apply
(For broad display in Gmail/Apple Mail, host a VMC/CMC and add --vmc https://example.org/bimi/vmc.pem.)
Dry-run first - note it changes only p, preserving your existing rua:
cfops dmarc example.org --policy quarantine --rua mailto:[email protected] --pct 25
DMARC none -> quarantine for example.org: new record: v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25 action: update (dry-run) record: TXT _dmarc.example.org - before: content="\"v=DMARC1; p=none; rua=mailto:[email protected]\"" ttl=1 + after: content="\"v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25\"" ttl=1 changed fields: content Dry-run only. Re-run with --apply to write this change.
Then apply:
cfops dmarc example.org --policy quarantine --rua mailto:[email protected] --pct 25 --apply
Ramp safely. Only flip to quarantine after p=none + rua reports show all your legitimate mail is authenticating with alignment. Then widen --pct 25 -> 50 -> 100 over a couple of weeks before ever considering p=reject. pct is honored today but is being removed in the in-progress DMARCbis revision - treat it as current best practice, not forever.
cloudflare-ops-mcp exposes clean named exports so a host app can import and wrap it (add your own auth, approval UI, or multi-tenant token vault) - but it has no dependency on any host and runs perfectly standalone.
import {
CloudflareClient,
scanZone,
applyDnsRecord,
setDmarcPolicy,
setupBimi,
setupEmailRouting,
planEmailAuth,
appendAudit,
} from "cloudflare-ops-mcp";
const client = new CloudflareClient(); // reads CLOUDFLARE_API_TOKEN from env
// (you may also inject { token, fetch } - useful for tests)
// Read-only snapshot:
const snapshot = await scanZone(client, "example.com");
// Plan a DMARC flip (dry-run - writes nothing):
const plan = await setDmarcPolicy(client, "example.com", "quarantine", {
rua: "mailto:[email protected]",
pct: 25,
});
// Apply it, then record the change yourself (you supply the timestamp):
const applied = await setDmarcPolicy(
client,
"example.com",
"quarantine",
{ rua: "mailto:[email protected]", pct: 25 },
{ apply: true }
);
appendAudit("./cloudflare-ops-mcp-audit.log", {
ts: new Date().toISOString(),
action: "dmarc.policy",
domain: "example.com",
record: applied.record,
before: applied.before,
after: applied.after,
});
Every mutating export is dry-run unless you pass { apply: true }, and pure logic never calls Date.now() - you (or the CLI) supply audit timestamps.
cloudflare-ops-mcp is a generic, open tool. A larger platform can import it to automate zone hygiene for its users (wrapping it with per-account tokens and an approval step), but it is completely standalone - the library and CLI run on their own with nothing but a scoped Cloudflare token.
worker/ is an optional Model Context Protocol server (a Cloudflare Worker) that exposes the same engine as tools over a URL, so any MCP client - an agent, Claude, Cursor - can scan_zone, plan_email_auth, set_dmarc_policy, setup_bimi, etc. by pointing at it.
cd worker npx wrangler secret put CLOUDFLARE_OAUTH_CLIENT_ID npx wrangler secret put CLOUDFLARE_OAUTH_CLIENT_SECRET npx wrangler secret put CLOUDFLARE_OAUTH_REDIRECT_URI npx wrangler deploy
Users visit /oauth/cloudflare/start, complete Cloudflare consent, and copy the one-time connector configuration. The MCP endpoint is /mcp. Private self-hosters may additionally set MCP_ACCESS_KEY and CLOUDFLARE_API_TOKEN as an owner-only fallback; never distribute that admin key.
The core library has zero dependencies; the Worker is an optional surface - you never need it to use the CLI.
npm test # node --test (mock fetch, no live network calls)
WT is AMH's current operator-safety effort: a guarded agent middle layer connecting Cloudflare Agents, MCP, and Wrangler. The goal is to let capable orchestrators and correctly labeled free or paid tool-calling agents inspect, plan, request approval, deploy, verify, and recover—without handing them raw Cloudflare tokens or letting stale agents overwrite newer work.
Watch for the stateful AMH Agent Coordinator, Cache Guardian, Change Guardian, Playwright phone/UI checks, and allowlisted Wrangler doctor, deployment, log, rollback, binding, and storage-health tools. The execution rule stays the same: check → diff → approve → apply → verify.
/\ |\ /| | |
/--\ | \ / | |----|
/ \ | \/ | | |
A M H // W T
-/\-\ M H // WT · YOUR CLOUDFLARE STAYS YOURS
Made by -/-\ M H // WT — AMH, Artificial Mind Hive, operated by Service Pricer LLC.
License: MIT (c) 2026 Pain2HuStle
AMH WT Cloudflare Ops MCP: per-user OAuth tools plus a private SafeTry Agent Harness with automatic process skills, Google source research, optional Claude verification, live/404 and email loopback checks, Wrangler deploy gates, audit, and no shared owner API keys.