What it gives Plexward
- Zone and DNS record reads, so a session can answer "where does this subdomain point" without a browser.
- Record changes when you have deliberately granted write, for example pointing a new subdomain at a box you just provisioned.
- Context for deployment runbooks, which otherwise stall on a DNS question that only you can answer.
Layer
brain. It is a remote HTTP MCP server, declared in the brain's .mcp.json, so it is scoped to the entity whose domains it serves.
{ "name": "cloudflare", "layer": "local MCP", "svc": "DNS · Zones", "account": "acme zone" }
Prerequisites
- A Cloudflare account that holds the entity's zone.
- Either an account login for the remote MCP server's OAuth flow, or a zone-scoped API token if you script against the REST API directly.
- A decision on scope. A token with
Zone:DNS:Editon one zone is a very different object from a global API key, and only one of them is acceptable.
Setup steps
Remote HTTP MCP server, in the brain's gitignored .mcp.json:
{
"mcpServers": {
"cloudflare": {
"type": "http",
"url": "https://mcp.cloudflare.com/..."
}
}
}
The first call triggers an OAuth consent in a browser. That step is yours.
If you also want scripted access, mint a zone-scoped token and store it:
cat > ~/.config/secrets/cloudflare.env <<'ENV'
CLOUDFLARE_API_TOKEN=<zone-scoped-token>
CLOUDFLARE_ZONE=acme.example
ENV
chmod 600 ~/.config/secrets/cloudflare.env
Per-entity routing
## Owned Integrations
| MCP Tool | Service | Account | Notes |
|---|---|---|---|
| cloudflare | DNS, Zones | acme zone | Remote HTTP MCP. Zone-scoped. |
## NOT This Company
- Zones for any other entity's domains.
Verify
cd ~/brains/acme-brain && claude mcp list | grep -i cloudflare
Expected ✔ Connected. Then a real read: list the DNS records for the entity's zone and check one you know.
Common failures
- A token that was never stored. A token minted in a browser and pasted into a chat is gone the moment the session ends. If it is not in the secrets directory at mode 600 or in a vault, it does not exist. This has blocked real deployments.
- Scope too narrow, discovered late. A
Zone:DNS:Readtoken looks fine until the step that actually needs to create a record. - Proxy status changes behaviour. A proxied record hides the origin and terminates TLS at the edge, which breaks certificate issuance flows that expect to answer a challenge themselves. If a certificate will not issue, check the proxy toggle first.
- OAuth consent expiry on the remote server presents as
Needs authenticationin the probe.
What Plexward does with it once connected
Deployment runbooks read the current records before changing anything and report what they would change. Record creation stays behind an explicit human confirmation, because DNS mistakes are fast to make and slow to notice.