Skip to main content
Glama
ni-c
by ni-c

Change primary nameservers

change_primary_nameservers
Idempotent

Replace the primary nameservers of a secondary DNS zone to update which servers Hetzner transfers the zone from.

Instructions

Replace the primary nameservers of a secondary zone (the servers Hetzner transfers the zone from). Only applicable to zones in secondary mode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
zoneYesID or name of the zone, e.g. "example.com"
primary_nameserversYesPrimary nameservers to transfer the zone from (secondary zones)
Behavior3/5

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

Annotations include idempotentHint: true, so the description does not need to discuss idempotency. The description adds context about the secondary-zone scope and what the primary nameservers are, but it does not disclose any side effects, auth requirements, or other behavioral traits beyond the obvious 'replace' operation. This is adequate but not rich.

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 two sentences, front-loaded with the action, and every word is informative. There is no redundancy or filler.

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

Completeness4/5

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

For a simple mutation tool with two well-documented parameters and an idempotency annotation, the description provides the necessary context: what is replaced and the applicable zone mode. It does not explain return values, but that is adequately handled by the lack of an output schema and the tool's simplicity. Slight room for improvement could mention the list replacement semantics, but it's not a critical gap.

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 description coverage is 100% for both parameters. The description does not add specific parameter details beyond the schema, so it meets the baseline of 3 without adding extra value.

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 action (replace), the resource (primary nameservers of a secondary zone), and adds explanatory context about what these servers are ('the servers Hetzner transfers the zone from'). This distinguishes it from sibling tools like update_zone, which would have a broader purpose.

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

Usage Guidelines4/5

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

The description gives an explicit usage restriction: 'Only applicable to zones in secondary mode.' This tells the agent when to use the tool, but it does not explicitly mention alternatives or when not to use it outside that condition. The clear context and exclusion warrant a 4, not a 5.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ni-c/mcp-hetzner-dns'

If you have feedback or need assistance with the MCP directory API, please join our Discord server