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

With no annotations, the description carries full behavioral burden. It usefully discloses duplicate handling (new value appended to the record set) and accepted hostname forms, but it omits permissions, reversibility, propagation timing, and return behavior for a mutation operation.

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?

The description is two tight sentences. The core purpose is front-loaded, followed by accepted input formats and duplicate behavior, with no wasted text.

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?

The core invocation is covered, including hostname formats and duplicate append behavior. But with no annotations and no output schema, the description remains incomplete about authorization, side effects, and what the caller receives after adding a record.

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 all five parameters are already documented. The description repeats the accepted name formats but does not add meaningful parameter semantics beyond the schema; baseline 3 applies.

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 and resource: "Add a DNS record to a domain." It also clarifies duplicate name/type behavior, which helps distinguish it from update_record and set_records, though it does not explicitly name those alternatives.

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?

Usage is implied by "Add" and by the note that an existing same-name/type record will have the new value appended. However, the description gives no explicit when-to-use guidance, prerequisites, or named alternatives for replacing versus appending records.

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

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

No annotations are provided, so the description carries the full behavioral burden for a mutation operation. It states what permissions can be configured but omits whether existing TSIG configuration is overwritten, what permissions or authentication are required, whether the operation is idempotent, and what happens when subdomains is omitted.

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?

The description is a single, front-loaded sentence with no filler. The key operation and the permission categories are presented immediately.

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 mutation tool with no annotations and no output schema, the description is too thin. It does not explain authorization requirements, overwrite/merge behavior, or the effect of omitting optional parameters, leaving important operational context unaddressed despite the schema's complete parameter documentation.

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 all five parameters are already documented in the input schema. The description adds a high-level mapping of the permission types but does not add syntax, defaults, or edge-case semantics beyond what the schema already provides.

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+resource combination ('Attach and configure TSIG permissions') and enumerates the permission types it handles (AXFR, dynamic updates, subdomain restrictions). It is clear enough to distinguish from retrieval/removal siblings, though it does not explicitly name when to choose this over create_tsig_key or remove_domain_tsig.

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 offers no explicit when-to-use guidance, prerequisites, or alternatives. It does not clarify whether this is for new TSIG attachment versus modifying existing permissions, nor does it reference related tools such as create_tsig_key or get_domain_tsig.

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

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

Because no annotations are provided, the description carries the full burden. 'Create/add' implies a write operation, but there is no disclosure of permissions needed, whether the call is reversible, what happens on duplicate domain names, or what the response contains.

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?

The description is a single front-loaded sentence with no filler. However, 'Create/add' and 'zone/domain' are mildly redundant synonym pairs, so it is concise without being maximally precise.

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 creation tool with no annotations and no output schema, the description is too thin. It does not explain the result of the call, error behavior, or operational context beyond 'under the OnlyDNS account,' leaving the agent without enough behavioral context.

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 coverage is 100%, and the single parameter (domainName) already has a clear example in the schema. The description adds no parameter-level format, validation, or constraint details beyond the schema, so the baseline of 3 is appropriate.

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 supplies a specific verb and resource ('Create/add a new DNS zone/domain') and scopes it to the OnlyDNS account. It is distinct from record-level siblings such as add_record, but it never names or contrasts those siblings explicitly, so it falls 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.

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

No when-to-use or when-not-to-use guidance is provided; the description only states what the tool does. It does not direct the agent to alternatives like add_record or list_domains or mention prerequisites like account ownership.

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

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

With no annotations, the description carries the full behavioral burden and leaves key traits unstated: whether the generated secret is returned once and must be stored, whether the key is persisted to a keystore, whether it is idempotent, and what privileges are required. For a credential-generation tool these omissions matter.

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?

A single front-loaded sentence with the verb and resource first and no filler. It is appropriately sized, though it spends its one clause on use cases rather than the behavior an agent most needs.

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?

The tool is simple (one optional enum param, no output schema), so little is required, but with no output schema the description should say something about the returned key material and that it must be captured. That gap keeps it at minimum-viable completeness.

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% and the single algorithm parameter is fully documented with an enum and a default in the schema, so the baseline of 3 applies. The description adds no guidance on algorithm selection tradeoffs.

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?

States a specific verb (generate) and resource (TSIG key) plus the intended purpose (secondary DNS transfers via AXFR, dynamic DNS updates). That distinguishes it from read-only siblings like list_tsig_keys and destructive ones like delete_tsig_key, though it never names an alternative explicitly.

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 AXFR/dynamic-update phrasing implies when the key is needed, which is more than nothing, but there is no explicit when-to-use vs when-not guidance and no mention of the related siblings configure_domain_tsig or delete_tsig_key that follow creation.

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

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

With no annotations, the description must carry behavioral disclosure. It states deletion but does not mention destructiveness, irreversibility, required permissions, behavior when the record is absent, or the important consequence that omitting value deletes all values (which appears only in the schema).

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?

Two concise sentences, front-loaded with the action and followed by relevant name-format details. There is no redundant or wasted text.

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?

The description covers the core action and the accepted name forms, and the schema covers parameters fully. However, for a destructive mutation tool with no annotations or output schema, it omits safety, permissions, and side-effect context that an agent would benefit from.

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 schema already documents all four parameters thoroughly. The description reinforces accepted name formats and the value-specific deletion concept, but adds no material semantics beyond the schema; baseline 3 is appropriate.

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 gives a specific verb and resource: "Delete a DNS record or specific value from a domain." It is clearly a deletion tool and distinguishes itself from add/update/set siblings by action, though it does not explicitly name those alternatives.

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?

It implies the tool is used to delete records or specific values, but provides no explicit when-to-use guidance, no exclusions, and no comparison to update_record, set_records, or other siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that keys are removed, which implies a destructive effect, but does not describe permissions required, reversibility, side effects on existing records, or error conditions.

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?

The description is a single, front-loaded sentence with no wasted words. It conveys the core action efficiently.

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?

The tool is simple with one fully documented parameter, and the description states the action clearly. However, for a destructive operation with no annotations and no output schema, it lacks important behavioral context such as permissions and irreversibility.

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?

The input schema has 100% description coverage for the single 'domainName' parameter. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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 ('Disable') and resource ('DNSSEC signing and DNSSEC keys') and scopes it to a domain. It clearly distinguishes the tool from the sibling 'enable_dnssec' by indicating the opposite operation.

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 provides no explicit guidance on when to use this tool versus alternatives such as 'enable_dnssec' or 'get_dnssec'. It only states the action, leaving usage conditions and prerequisites to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a state-changing operation but says nothing about required permissions, whether the change is reversible, what happens if DNSSEC is already enabled, or what the response contains. For a mutation tool with zero annotation coverage this is a significant gap.

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?

One short, front-loaded sentence with no filler. It is efficient, though it is so terse that it omits context that would have been worth the extra words.

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 single-parameter tool with a fully documented schema and no output schema, the description is minimally adequate. It nonetheless omits any behavior on error or re-invocation, which matters for a state-changing DNS operation.

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?

There is a single parameter with 100% schema description coverage, so the schema fully documents 'domainName' with an example. The description adds no syntax or format detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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 and resource: enabling DNSSEC signing for a domain. It is clear what the tool does and distinguishable from siblings like get_dnssec and disable_dnssec by the verb and the tool name. It does not explicitly contrast itself with disable_dnssec or note the domain must already exist, but the purpose itself is unambiguous.

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?

There is no guidance on when to use this versus alternatives, nor any mention of prerequisites such as the domain existing, DNSSEC being currently disabled, or DS records needing configuration at the registrar. The agent must infer the entire usage context 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.

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

No annotations are supplied, so the description carries the full disclosure burden. It does usefully disclose the shape of what comes back (NSEC3 parameters, DS and DNSKEY keys), but says nothing about permission requirements, whether the call fails or returns an empty/disabled status when DNSSEC is off, or any rate limits.

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?

One front-loaded sentence with zero filler; the verb and resource lead and the enumerated content follows. Nothing could be trimmed without losing information.

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 single-parameter read tool with no output schema, enumerating the returned data (status, NSEC3, DS/DNSKEY) is exactly the compensation needed. It is only incomplete on edge-case behavior — what happens when DNSSEC is not enabled on the domain.

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?

Only one parameter and schema coverage is 100%, with the schema documenting domainName and an example format. The description's phrase 'for a domain' adds no syntax or constraints beyond the schema, so the baseline 3 applies.

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?

States a specific verb ('Get') and resource ('DNSSEC configuration') and enumerates the payload it covers (status, NSEC3 parameters, DS/DNSKEY keys), which makes it clearly the read counterpart to the sibling enable_dnssec/disable_dnssec tools. It stops short of naming those siblings explicitly, so an agent must infer the routing rather than being told.

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?

There is no when-to-use or when-not-to-use guidance, no prerequisite (e.g. the domain must exist / be registered in the account), and no explicit contrast with enable_dnssec or disable_dnssec. The read intent is only implied by the verb 'Get'.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' implies a read operation and the parenthetical lists the permission categories involved, but it does not disclose whether secret key material is returned, required authorization, or side effects, which matters for TSIG credentials.

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?

It is a single efficient sentence with the main action front-loaded. The parenthetical adds useful scope without becoming verbose.

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 simple one-parameter getter, the description adequately explains what domain-scoped TSIG data is retrieved, including permission categories. Since no output schema exists, it could say more about the exact return shape, but the tool complexity is low.

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 single domainName parameter is already well documented. The description reinforces that the lookup is domain-scoped but adds no parameter syntax or format details beyond the schema.

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 gives a specific verb and resource: get TSIG keys and permissions configured for a domain. It clarifies scope and includes examples of the permission types, but it does not explicitly distinguish this from sibling tools such as get_tsig_key or list_tsig_keys.

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?

Usage is implied by the domain-scoped retrieval purpose, but there is no explicit guidance on when to use this instead of get_tsig_key, list_tsig_keys, or configure_domain_tsig. No exclusions or prerequisites are stated.

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

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

No annotations are provided, so the description carries the full burden. 'Get details' implies a read, but it says nothing about required permissions, what fields the details contain, or behavior when the key name does not exist.

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?

A single tight sentence with the resource and selection criterion front-loaded; no wasted words. It is perhaps overly terse rather than padded.

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 one-parameter read tool with no output schema, the description is adequate but thin: it does not say what 'details' comprises or how a missing key is handled, and there are no annotations to fill the gap.

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 coverage is 100% and the single keyName parameter is already documented with a format example in the schema, so the description adds no meaning beyond it. Baseline 3 per the high-coverage rule.

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?

States a specific verb (get) and resource (TSIG key) scoped to a single key selected by name, which contrasts with the sibling list_tsig_keys. However, it never names that sibling or explicitly says it returns one key rather than many.

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?

No when-to-use guidance and no alternatives referenced, despite a crowded sibling set (list_tsig_keys, create_tsig_key, configure_domain_tsig). The agent must infer that this is the single-key lookup path.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only scope (account-wide domains) and gives no information about pagination behavior, auth/permission requirements, ordering, or whether results are cached — thin for a no-annotation tool.

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?

A single front-loaded sentence with no filler; the scope qualifier is placed immediately after the verb+resource.

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 simple read-only list tool with two fully documented optional params and no output schema, the description is minimally sufficient. It omits any read-only/permission context that would matter given the absence of annotations.

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%, with limit and offset fully documented inline including defaults and bounds. The description adds nothing beyond that, so the baseline 3 is appropriate.

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?

States a specific verb (List) and resource (DNS domains) scoped to the OnlyDNS account, which is enough to distinguish it from record- or TSIG-focused siblings. However it does not name or contrast with any alternative (e.g. list_records), so it stops short of full sibling differentiation.

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 phrase 'List all' implies an unfiltered enumeration, but there is no explicit when-to-use guidance, no mention of when a more targeted tool (list_records) is preferable, and no note about paginating large accounts.

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

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

No annotations are provided, so the description carries the burden. "List" implies a non-destructive read, which is the main behavioral signal, but it discloses nothing about pagination, result limits, permissions, or result ordering — the details that matter for a listing tool with zero annotation coverage.

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?

A single front-loaded sentence with the resource, scope, and optional filters in the first few words; no filler or redundancy.

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?

With no output schema and no annotations, the description should cover what comes back; "List all DNS records" is minimal but sufficient for a straightforward read tool whose parameters are fully specified in the schema. Return shape and any paging behavior remain unstated, which keeps it short of a 5.

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 coverage is 100%, so all three parameters are already fully documented, including the accepted hostname formats and record-type values. The description restates those filters at a high level but adds no syntax or semantics beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ("List all DNS records for a domain") plus the two optional filter dimensions, so an agent knows exactly what it does. It is distinguishable from add_record/update_record/delete_record by the verb, but does not explicitly differentiate from list_domains or set_records.

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 makes the usage context clear (listing records for a given domain, with optional narrowing by type or hostname) but names no alternatives or exclusions — e.g. it never routes the agent to get_domain_tsig or list_domains, nor states when not to filter.

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

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

No annotations are provided, so the description carries full behavioral burden. It implies a read-only list operation but does not disclose permissions, pagination, rate limits, or return format, leaving significant behavioral gaps.

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?

A single sentence that is front-loaded and contains no filler. Every part of the sentence earns its place by naming the action, resource, and account scope.

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 simple no-parameter list tool with no output schema, the description sufficiently conveys what the tool returns. It could mention return shape or read-only nature, but the core information is present.

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?

The tool takes zero parameters, so there are no parameter semantics to document. Per the baseline rule for 0 parameters, a 4 is appropriate.

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?

Provides a specific verb (List) and resource (TSIG keys) with account scope (OnlyDNS account). It implies a contrast with get_tsig_key via 'all' and plural 'keys', but does not explicitly name or rule out any sibling tool.

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?

No when-to-use guidance, prerequisites, or alternatives are provided. The description only states what the tool returns, leaving the agent to infer usage from the tool name and resource alone.

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

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

With no annotations, the description carries the full burden. It does disclose the one behaviorally important fact for a destructive call: this removes ALL keys for the domain, not one. It omits permissions required, irreversibility, and side effects (e.g. broken TSIG-authenticated transfers).

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?

A single front-loaded sentence with no filler; the scope qualifier 'all' appears immediately after the verb where it matters most.

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 one-parameter destructive tool with no annotations and no output schema, the description names what is destroyed but leaves out prerequisites (does the domain need existing keys?), reversibility, and downstream impact on DNS authentication.

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% and there is a single documented parameter (domainName with an example), so the schema already does the work. The description adds no format or constraint detail beyond the schema baseline of 3.

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?

States a specific verb (remove) and resource (all TSIG keys associated with a domain), and the word 'all' scopes the operation usefully. It implicitly separates itself from configure_domain_tsig, but never names or contrasts with that sibling explicitly.

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?

There is no statement of when to use this tool versus alternatives such as configure_domain_tsig or a per-key deletion path. Usage can only be inferred from the verb and the word 'all', which is not real guidance.

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

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

With no annotations, the description carries the full behavioral burden. It correctly discloses the destructive, full-replacement semantics and warns about omitted records, which is valuable. However, it omits other important traits such as permission requirements, atomicity, return behavior, and interaction with DNSSEC, leaving gaps for a destructive mutation.

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?

Two sentences, front-loaded with the core action and followed by a critical warning. Every sentence earns its place with zero waste.

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 annotations and no output schema, the description states the key risk but lacks operational context an agent might need: prerequisites (e.g., domain existence, permissions), whether the operation is atomic, and what the response looks like. It is minimally adequate but not 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 schema already documents both parameters in detail (domainName and the nested records structure). The description adds no parameter-specific meaning beyond what the schema provides; baseline 3 is appropriate.

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 and resource: 'Completely replace ALL DNS records in a zone with a new list of records.' The use of 'Completely replace ALL' clearly distinguishes this bulk-replacement tool from the incremental siblings like add_record, update_record, and delete_record.

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 warning 'destructive if omitted records are intended to be preserved' implies when caution is needed, but the description does not explicitly state when to use this tool versus alternatives (e.g., 'use update_record to modify a single record' or 'use add_record to append'). Usage is implied rather than guided.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the key mutation trait that existing values are wholly overwritten rather than merged, and that TTL is preserved when omitted, which is meaningful. However, it is silent on failure modes (what happens if the record does not exist), whether the call is idempotent, permissions/API key needs, or rate limits for a destructive replace.

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?

Two sentences, front-loaded with the operation and its replacement semantics before the naming detail. The second sentence largely restates the `name` parameter description, so it earns only marginal space, but there is no filler.

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 5-parameter mutation with no annotations and no output schema, the description covers what the tool does, the destructive replacement scope, and TTL defaulting behavior, and the schema fully documents inputs. The remaining gap is behavior on a missing record and any error/return expectations, which is a moderate but not severe omission.

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 every parameter including the name-format options and TTL preservation is already documented. The description's naming-format sentence duplicates the schema's `name` description almost verbatim, adding no new syntax or constraint information. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Update an existing DNS record set') scoped to a name and type, and clarifies the operation is a full replacement of values and/or TTL. This separates it from an additive tool like add_record, but it never names or contrasts with set_records, delete_record, or add_record, so the sibling boundary is only implied.

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 phrase 'update an existing ... record set' implies the record must already exist, and 'completely replacing' implies the when-not for partial/append flows, but neither is stated. With siblings add_record, set_records and delete_record present, an explicit routing hint (e.g. use add_record to append, delete_record to remove) is missing.

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