Create or update A, AAAA, or CNAME DNS records in Cloudflare, with dry-run and DNS-only defaults. Replace differing records via replace_id; SSL settings stay unchanged.
Create or update A/AAAA/CNAME. Defaults to dry run and DNS-only. Existing differing record needs replace_id. Does not alter zone SSL configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | ||
| name | Yes | ||
| type | Yes | ||
| content | Yes | ||
| dry_run | No | ||
| proxied | No | ||
| zone_id | Yes | ||
| replace_id | No |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful behavior: dry_run defaults on (so calls are non-mutating by default), DNS-only/proxied-off by default, and the replace_id requirement for conflicting records. It omits auth/permission needs, idempotency, and what a dry-run response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with purpose and immediately followed by defaults and the key edge case. No filler; every sentence carries signal, though the trailing SSL note could be folded into the boundary statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description should do more: return shape, permission requirements, and the undocumented ttl/name/content semantics are all missing. It covers the critical safety defaults but not the full operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 8 parameters, so the description must compensate. It explains the meaning of dry_run, proxied, replace_id, and type, but leaves ttl, name, content, and zone_id undefined — roughly half the parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair (create/update) and the exact resource (A/AAAA/CNAME records), which an agent can distinguish from cloudflare_delete and cloudflare_records. However, it never names which sibling to prefer when a record may or may not already exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete usage conditions: dry-run is the default, and replacing a differing existing record requires replace_id. It stops short of explicit when-to-use vs cloudflare_records/cloudflare_delete routing or when proxied should be turned on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.