Set DNSSEC

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

Annotations declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description goes beyond annotations by explaining the impact ('changes the zone's DNSSEC chain and can affect validating resolvers'), the ordering constraint with parent DS records, and the required permission scope (dnssec:manage). It stops short of describing reversibility or exact response behavior, but adds substantial safety and operational context.

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 sentences, front-loaded with the primary action and impact, followed by the critical prerequisite and permission note. No wasted words, though it is dense and could be split for readability. Every sentence carries operational weight.

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 destructive mutation with no output schema, the description covers impact, prerequisites, permission requirements, and secondary-zone handling. It is missing a note on what the response returns or whether the change is reversible, but given annotations already flag destructiveness, this is largely complete.

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 100%, so the baseline is 3. The description adds semantic meaning beyond the schema by explaining the parent_ds_removed flag in operational terms and clarifying that 'enabled' toggles signing on/off in the context of DNSSEC chain management. This is useful value-add over the schema alone.

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?

The description states a specific verb (Enable or disable) and resource (public DNSSEC signing for a native DNS zone), and names the sibling concept get_dnssec implicitly by being the mutation counterpart. An agent can immediately distinguish this from get_dnssec or list_dns_zones.

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?

The description gives clear prerequisites and conditions for use: remove parent DS records first and set parent_ds_removed=true before disabling, and secondary-zone DNSSEC is controlled on the primary server. It does not explicitly name an alternative tool, but the when-to-use context is strong.

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