zone-mcp

Create DNS record

create_dns_record

Create a DNS record in a Zone.ee/Zone.eu zone by specifying the zone, record type, name, and destination, including MX, SRV, CAA, TLSA, SSHFP, and URL redirect fields.

Instructions

Create a DNS record. name may be '@' (zone apex), a label like 'www', or the FQDN; it is sent to Zone as an FQDN. Type-specific fields: MX priority; SRV priority, weight and port; CAA flag and tag; TLSA certificate_usage, selector and matching_type; SSHFP algorithm and fingerprint_type; URL redirect_type. TTL can't be set through the API.

Input Schema

Name	Required	Description
`tag`	No	CAA: tag.
`flag`	No	CAA: flag (usually 0).
`name`	Yes	'@', a label ('www', '_acme-challenge') or the FQDN.
`port`	No	SRV: port.
`type`	Yes	Record type: a, aaaa, cname, mx, txt, ns, srv, caa, tlsa, sshfp, or url (Zone's HTTP redirect record).
`zone`	Yes	DNS zone, e.g. 'example.com'.
`weight`	No	SRV: weight.
`priority`	No	MX, SRV: priority.
`selector`	No	TLSA: selector 0–1.
`algorithm`	No	SSHFP: algorithm (1=RSA, 2=DSA, 3=ECDSA, 4=Ed25519).
`destination`	Yes	The record value: IP, target host, TXT text, CAA value, fingerprint, or the redirect URL for URL records.
`matching_type`	No	TLSA: matching type 0–2.
`redirect_type`	No	URL: HTTP redirect status, 301 (default) or 302.
`fingerprint_type`	No	SSHFP: fingerprint type (1=SHA-1, 2=SHA-256).
`certificate_usage`	No	TLSA: certificate usage 0–3.

Output Schema

Name	Required	Description	Default
`record`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

B3.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description adds two genuinely useful behavioral facts: TTL is not settable via API, and `name` is normalized to an FQDN when sent to Zone. This is the kind of context annotations (readOnly=false, idempotent=false, openWorld=true) cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the core action, but the middle sentence is a long run-on list of type-specific fields that mostly duplicates the schema descriptions one-for-one. That list could be compressed or dropped without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 15 parameters and an output schema present, the definition covers the essentials but omits which fields are mandatory for which record types (e.g. priority for MX/SRV) and any error behavior. For a tool with 11 record types this leaves meaningful gaps for an agent composing a call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter already has a description, including the 'MX, SRV: priority' and 'CAA: flag' notes that the description largely restates. The only added meaning is the '@' apex shorthand and the FQDN normalization behavior, which the schema hints at but doesn't fully explain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Create a DNS record'), which is unambiguous and easily separable from the sibling list/update/delete_dns_record tools by name alone. It doesn't explicitly contrast itself with those siblings, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to create versus update an existing record, no prerequisites (e.g. that the zone must already exist), and no mention of what happens if a conflicting record exists. The agent must infer all routing decisions from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.