The same answers as above, laid out as plain text so search engines and AI crawlers can read the whole thing without running any JavaScript. This is Cloudflare Ops MCP — an independent, open-source, approval-gated Cloudflare operations layer for AI agents, made by Artificial Mind Hive and operated by Service Pricer LLC.
What is Cloudflare Ops MCP, in one paragraph?
Cloudflare Ops MCP ("Walrus Tooth") is an approval-gated operations suite for the Cloudflare tasks that quietly break product launches: DNS cutovers, email trust (SPF/DKIM/DMARC/BIMI), bot checks (Turnstile), cache freshness, Pages deploys, and AI-agent workflows. It exists so an AI agent — a small K2-class model, Claude, or your own — can safely do real Cloudflare work through the Model Context Protocol without ever holding your raw account credentials or being able to break something irreversibly. The design principle is bounded delegation: the agent proposes, a deterministic layer verifies, and a human approves the one risky click. Use case: you tell an agent "cut api.example.com over to the new Worker and purge cache," and instead of it running wild, you get a dry-run diff to approve, then a verified 2xx check confirming the cutover actually served.
Is this an official Cloudflare product?
No. Cloudflare Ops MCP is made by AMH — Artificial Mind Hive, operated by Service Pricer LLC. It is independent, third-party, open-source software: not affiliated with, endorsed by, sponsored by, or made by Cloudflare, Inc. The names "Cloudflare" and "Wrangler" are referenced only to describe compatibility with Cloudflare's platform and official developer tooling. You bring your own Cloudflare account and your own scoped token; the tool is a safety layer on top of Cloudflare's own APIs, not a replacement for or a reseller of them.
Can an agent change my DNS without asking?
No. Every mutating function is dry-run by default and only writes when { apply: true } is passed; the CLI is dry-run unless you add --apply. A dry-run returns the planned change plus a full before/after diff and writes nothing. This is the core safety guarantee: an agent can propose a hundred changes and read your whole zone, but it cannot mutate a single record until a human (or an explicitly configured approval step) turns apply on. Use case: an agent auditing your DNS for a migration returns a diff of the 12 records it would change; you read the diff, approve, and only then does anything write.
Does it ever delete records on its own?
Never as a side effect. Deleting a DNS record requires an explicit deleteDnsRecord(..., { confirm: true }) call (CLI: --force) — deletion is a separate, intentional operation, not something an apply can trigger while doing something else. An apply that updates or creates records will never remove one. This closes the most common way automation destroys production: a well-meaning 'sync' that treats absence as 'delete'. Here, removal is always a deliberate, named, confirmed act.
Where does my Cloudflare token live, and how is it protected?
The Cloudflare API token is read only from process.env.CLOUDFLARE_API_TOKEN. It is never logged, never written to the audit log, and never included in thrown error messages — any token-looking substring is redacted defensively before anything is emitted. Tool arguments never carry the token, so it cannot leak into an agent's transcript or an MCP tool call. Use a least-privilege scoped token (Zone:DNS:Edit for the one zone, not the Global API Key), so even a worst-case compromise is contained to exactly what you granted. In the hosted mode you don't hand over a token at all — see the connector-key answer below.
What do public / hosted users connect with instead of a token?
Public users authorize Cloudflare directly through OAuth and receive an opaque cfops_ connector key. The OAuth access and refresh tokens stay server-side in Workers KV and never reach the browser or the agent; the connector key itself is stored only as a SHA-256 hash and is bound to exactly one OAuth grant. Either side can revoke the connection at any time, which instantly invalidates the key. This means an AI can be given a connector key to operate on your behalf without ever seeing a credential it could exfiltrate or reuse elsewhere — the key is useless outside this one grant.
What counts as a 'verified' deploy — why not just trust a 200?
The deploy gate checks the public target for an explicit 2xx status, rejects redirects (a 301/302 to a login or holding page is not success), and optionally requires an expected release marker — a string you know is in the new build — before reporting success. This catches the two failure modes that make deploys lie: a CDN or SPA fallback serving a stale-but-200 page, and a redirect that looks healthy but sends users somewhere wrong. Use case: you deploy v0.4.2 and require the marker "v0.4.2"; if the live URL 200s but the marker is missing, the gate reports FAILED, so you learn the old build is still serving instead of finding out from a customer.
Does the email check prove my mail hits the inbox?
No — and it deliberately doesn't claim to. The self-catching loopback exercises the configured sending and routing path end to end and records delivery evidence (that the message was accepted, routed, and received by the path you set up). It does not claim to prove placement in a specific provider's inbox tab, because no honest tool can guarantee Gmail's Primary tab from the outside. What it does give you is a real, self-verifying signal that your send rail works — so an agent can test 'did mail actually go out and come back' without asking you to go check your inbox.
How do I run it? What are the five modes?
Version 0.4.2 runs five ways, smallest to largest: (1) the cfops CLI locally with a scoped Cloudflare token — dry-run by default; (2) the zero-dependency library imported into your own code; (3) the hosted OAuth MCP, where users connect via connector key and nothing is self-hosted; (4) a self-hosted MCP Worker you deploy with Wrangler and your own secrets; and (5) the private Agent Harness behind the MCP Worker's AGENT_HARNESS service binding, which adds bounded jobs, health watches, schedules, the audit chain, and the authenticated operator console. Pick the smallest one that fits: a solo dev uses the CLI; a team wanting agents-as-a-service runs the Worker plus the Harness.
What is the Agent Harness and the operator console?
The Agent Harness is the optional private layer that turns one-off tool calls into bounded, logged jobs. Instead of chatting with an agent, you give it a job with a written objective, allowed domains, and hard limits (max URLs, max source characters, max AI calls per day), and it runs deterministically where it can — site-health checks and mail loopbacks cost zero AI. Its agents (a small named crew) carry reusable profiles and process skills. The operator console is the authenticated dashboard where you watch the crew live: what each agent is doing, progress on each job, AI-call budget per agent and per day, and the reviewed lessons the crew has learned. It's the 'humans just hold the approve button' surface.
What are the process skills, and can agents rewrite themselves?
The harness ships process-skill folders the crew auto-selects per job: safe Cloudflare deploy, live-site verification, email loopback, context handoff, refute-first security review, private MCP access, source research, an optional Claude second opinion, plus operator-specific packs (two-account Pages deploy, landing guard, NU publishing, mail send-verify). Agents can PROPOSE improvements to a skill or template when a correction repeats — but a proposal is reviewable and can never silently self-promote into active behavior. Nothing an agent does can change what it is allowed to do without a human-reviewed step. That guardrail is the point: the system learns without quietly rewriting its own limits.
Is there an audit trail I can replay or dispute?
Yes. Every apply appends one JSON line to an audit log (default ./cloudflare-ops-mcp-audit.log) recording { ts, action, domain, record, before, after } — and never the token. The harness keeps a tamper-evident chain in one Durable Object per user, so each job records packet and memory hashes that let a run be replayed or disputed after the fact. Use case: three weeks later someone asks 'who changed this MX record and to what?' — you have the exact timestamp, the before value, the after value, and the job that did it, instead of a shrug.
What Cloudflare tasks does it actually handle?
Twelve operation areas, all dry-run-first where they write: DNS record scan/lookup/create/update/no-op-detection/guarded-delete; SPF detection (so you don't create a second SPF record and break mail); DMARC parsing and field-scoped policy updates; BIMI TXT setup gated on DMARC enforcement; DKIM discovery; MX and Cloudflare Email Routing checks and rule setup with verified-destination protection; Turnstile widget planning for bot checks; Cloudflare Pages DNS cutovers and cache purge; MCP endpoint deployment on Workers with Wrangler secrets; audit logging of applied changes; and AI-agent safety defaults (dry-run first, diff display, no token in tool args, no accidental deletes). It targets the launch-breaking, trust-breaking tasks specifically — not a generic 'do anything' shell.
What does BIMI require before it will write?
setupBimi first checks the domain's DMARC policy. If the policy (p=) is missing or set to none, it refuses to write in apply mode — because BIMI is not honored by mailbox providers below DMARC enforcement, so writing the record early would be a no-op that looks done. You can override with { force: true } if you know what you're doing; in dry-run it warns you of the precondition instead of failing silently. This is the pattern throughout: the tool encodes the real-world precondition so an agent can't 'successfully' do something that won't actually work.
from Apiary →