eurodns-mcp

Create or update a DNS record

eurodns_dns_upsert_record

Idempotent

Add or update a single DNS record in a zone, with validation and conditional save. Use matchRdata or append to handle multiple records.

Instructions

Adds one DNS record to the zone domainName, or updates the existing record with the same type and host, and returns the record as saved with the action taken. It reads the zone, applies the change, runs the API’s validator and saves only if validation passes; a rejected change returns the validation report and writes nothing. Prefer it over eurodns_dns_save_zone, which replaces the whole zone. Give matchRdata to pick one of several records sharing a host, or append: true to add a further record under an existing type and host rather than updating it; the value goes in rdata.

Input Schema

TableJSON Schema

Name	Required	Description
`ttl`	No	Record TTL in seconds. Allowed values: 600, 900, 1800, 3600, 7200, 14400, 21600, 43200, 86400, 172800, 432000, 604800.
`host`	Yes	Node the record applies to. Use "" or "@" for the apex.
`type`	Yes	Record type, e.g. A, AAAA, CNAME, MX, TXT.
`rdata`	Yes	Record value. The API field is "rdata", not "data".
`append`	No	true adds the record even when one with the same type and host exists, instead of updating it: a second TXT under one host, or a further MX. Default false.
`domainName`	Yes	Zone to modify, e.g. example.com.
`matchRdata`	No	Update only the record whose current value matches this. Use when several records share a type and host, such as multiple TXT entries.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`zone`	Yes
`action`	Yes
`record`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.11.0Sep 8, 2026

addedInput schema / properties / append

Added value: +{
+  "description": "true adds the record even when one with the same type and host exists, instead of updating it: a second TXT under one host, or a further MX. Default false.",
+  "type": "boolean"
+}

First observedv0.9.1Sep 5, 2026

TDQS

A5/5.0

Behavior5/5

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

Given the annotations (readOnlyHint: false, destructiveHint: false, idempotentHint: true, openWorldHint: true), the description goes beyond the annotations by explaining that the tool reads the zone, applies the change, validates, and only writes if validation passes. It also states that a rejected change writes nothing, which is a key behavioral detail not covered by annotations.

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 concise yet comprehensive—four sentences covering purpose, alternative guidance, special-case parameters, and validation behavior. Every sentence adds value, and the structure front-loads the primary action before discussing edge cases.

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?

Given the tool's moderate complexity (7 parameters, 4 required, enums, and both append and matchRdata special cases), the description provides all necessary context: what the tool does, how it differs from siblings, when to use advanced parameters, and the validation/write behavior. The presence of an output schema covers return format, and the description fills the remaining gaps for successful invocation.

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?

The schema already has 100% parameter description coverage, and the tool description adds extra meaning beyond the schema, such as clarifying that the API field is 'rdata' not 'data', explaining when to use matchRdata for multiple records sharing a type and host, and specifying the behavior of append. This significantly aids in correct parameter usage.

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 clearly states the tool adds or updates a single DNS record and returns the saved record with the action taken. It distinguishes itself from the sibling tool save_zone by explicitly noting it replaces the whole zone, and from delete_record by implying record-level modification. The verb and resource are specific and 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?

The description explicitly says 'Prefer it over eurodns_dns_save_zone, which replaces the whole zone', giving direct guidance on when to use this tool instead of an alternative. It also explains when to use append (add a second record with same type/host) and matchRdata (update a specific record among several) which are conditional usage instructions.

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

Deploy Server