Cloudflare DNS

Lets an agent read and add DNS records in exactly one zone. The zone is fixed in the config, the token is scoped to that zone, and nothing here can delete a record.

What you get

• cf.dns.list — records in the zone, filtered by type and name.
• cf.dns.create — add one record.
• cloudflare://zone — the zone's own settings, as an MCP resource.

What you need

• Cloudflare API token — a scoped token with Zone → DNS → Edit on this one zone. Not the global API key, which reaches every zone on the account and cannot be narrowed.
• Zone id — from the zone's overview page in the dashboard. It is a config value rather than a caller argument, so "which zone" is never a question an agent gets to answer.
• JWKS endpoint — the host where your identity provider publishes its signing keys, without a scheme.
• Token audience — the aud claim your callers' tokens carry.

How it works

DNS is the class of change where an agent's mistake is other people's outage, so this template narrows twice. The zone id is interpolated into every URL from config, so a caller cannot address another zone. And the token is expected to be scoped to that same zone, so even a config edit that widened the URL would still be refused by Cloudflare.

There is deliberately no update and no delete binding. Adding a record is recoverable by deleting it in the dashboard; deleting one an agent should not have touched is an incident. If you need removal, add it as a separate binding with its own trust floor rather than widening one of these.

Audit runs fail_closed. A gateway that cannot record what it changed does not get to change anything.

Notes

Cloudflare answers HTTP 200 with {"success": false, "errors": [...]} for many failures, so the status code alone is not the outcome. Read success in the agent or pipeline layer.

proxied: true only means anything for A, AAAA and CNAME records. On the others Cloudflare ignores it rather than refusing the call.