eurodns-mcp

Validate a DNS zone

eurodns_dns_check_zone

Read-only

Validate a complete DNS zone before saving: submit records, URL forwards, and mail forwards to receive a per-record error report without changing anything. Use this check to catch problems and avoid a rejected save.

Instructions

Validates the candidate zone in body against the API’s rules for domainName and returns it with a per-record report of errors, without saving anything. Use it before eurodns_dns_save_zone, whose rejection is a bare 400. It does not preview what a change would alter, which is what eurodns_dns_diff_zone reports. The body must be the complete zone — records, urlForwards and mailForwards — with values in rdata.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`body`	Yes	The candidate zone to validate: records, urlForwards and mailForwards in the shape eurodns_dns_get_zone returns. Nothing is saved.
`domainName`	Yes	Name of the zone, e.g. example.com: a domain whose DNS is hosted here.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	Response body as returned by the API.
`status`	Yes	Upstream HTTP status code.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.10.0Sep 7, 2026

changedInput schema / properties / body / description

Previous value: -"Request body."New value: +"The candidate zone to validate: records, urlForwards and mailForwards in the shape eurodns_dns_get_zone returns. Nothing is saved."

changedInput schema / properties / domainName / description

Previous value: -"a domain name (e.g. example.com)"New value: +"Name of the zone, e.g. example.com: a domain whose DNS is hosted here."

First observedv0.9.1Sep 5, 2026

TDQS

A4.8/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description reinforces this by saying 'without saving anything' and 'Nothing is saved.' It adds relevant behavioral context beyond the annotations, though it does not discuss auth or rate limits, which are not central here.

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

Conciseness5/5

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

The description is compact and front-loaded with the purpose, then immediately gives usage guidance and exclusions. Each sentence adds distinct value with no redundant or vague wording.

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

Completeness5/5

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

The output schema is provided and the description gives enough context about the validation report and the relationship to sibling tools. Since the output schema exists, the description does not need to enumerate return fields, and it covers the necessary operational context.

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

Parameters5/5

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

Both parameters are described with meaningful context: domainName includes an example and hosting note, while body explains it must be the complete zone in the shape returned by eurodns_dns_get_zone. This goes well beyond the parameter names and provides clear semantic guidance.

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

Purpose5/5

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

The description uses a specific verb ('Validates') and resource ('candidate zone'), and clearly distinguishes this tool from eurodns_dns_save_zone and eurodns_dns_diff_zone by stating what it does and does not do. This makes the tool's purpose unambiguous.

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

Usage Guidelines5/5

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

Explicitly instructs to use this tool before eurodns_dns_save_zone because save returns a bare 400 on rejection, and clarifies that previews of changes are handled by eurodns_dns_diff_zone. It also states the required body shape, leaving no ambiguity about when and how to invoke it.

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

Deploy Server