plexward

CONNECTORS / CLOUDFLARE

Cloudflare

DNS, zones and edge configuration for the domains an entity owns. Useful when an entity's infrastructure is yours to run, and inert otherwise.

Brain layerDNS and zone state for entities whose domains you operate.

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:Edit on 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:Read token 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 authentication in 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.

Every connector, one convention.

Plexward keeps the bookkeeping: which entity is supposed to have which connector, whether it is actually working right now, and what an agent is allowed to do with it.