Server Quality Checklist

Tool Scores

• export_zonefileB
  3.4/5.0
  Behavior3/5

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

  Annotations mark this as readOnlyHint=true, which aligns with the export operation. The description adds that it exports the full contents in BIND format, but does not clarify details like whether the output is plain text or includes all record types, or if special zones are excluded. No contradiction, but limited additional transparency.

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

  Conciseness4/5

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

  The description is a single sentence, concise and front-loaded with the action ('Export') and resource ('DNS zone'). It omits no critical context but is adequately structured and not verbose.

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

  Completeness3/5

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

  Given the simple nature of this tool (single parameter, no output schema, read-only), the description is sufficient for an agent to understand the action. However, for a tool that returns a specific format, some context on the output evolution or access requirements could enhance completeness, but not critically needed here.

  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 coverage is 100%, with the single 'zone' parameter already documented as 'ID or name of the zone'. The description does not add any further parameter details beyond the schema, but the baseline of 3 is acceptable given full schema description, so a 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool exports a DNS zone's full contents in BIND zone file format, which is a specific and distinct action among siblings like get_zone and import_zonefile. It does not explicitly distinguish from get_zone, but the action is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for exporting zone data, but does not provide explicit guidance on when to use this tool versus alternatives like get_zone or import_zonefile. No when-not-to-use or alternative references are given, so guidance is only implicit.

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

• get_rrsetA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the agent knows it's a read operation. The description adds that it returns a single RRSet but doesn't disclose behavior like whether it returns the full record set with TTL or just the records. It doesn't contradict annotations, but adds minimal context beyond them. Baseline 3 is appropriate.

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

  Conciseness4/5

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

  Single sentence, front-loaded with the key action. It's concise and to the point. Slightly could mention that it's read-only but the annotation covers that. Score 4 because it's efficient and free of fluff.

  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 get operation with 3 parameters, full schema coverage, and a readOnly hint, the description is adequate. It conveys the core purpose. No output schema, but returning a single RRSet is implied. It could mention absence of filtering options, but it's not necessary. Completeness is high given the tool's simplicity.

  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 covers all parameters with descriptions (100% coverage). The description doesn't add much beyond the schema, but that's fine since schema is complete. The enum for type and regex for name/zone are well documented. No extra semantics needed, so baseline 3.

  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 (get), the resource (a single RRSet), and the scoping (by name and type within a zone). It distinguishes from siblings like list_rrsets (which would list all) and create/update/delete (which mutate). The phrase 'Get a single RRSet' is 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 Guidelines3/5

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

  The description implies this is for fetching one specific RRSet, but does not explicitly state when to use it versus list_rrsets or mention that it's read-only. It provides clear context (by name and type) but no exclusion or alternative naming. Acceptable but could be stronger.

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

• list_rrsetsA
  3.8/5.0
  Behavior3/5

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

  Annotations already provide readOnlyHint=true, so the description does not need to establish safety. It adds that results include records, TTLs, and protection status, which helps set expectations, but it does not disclose pagination limits, filtering behavior, or any other runtime traits beyond 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.

  Conciseness5/5

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

  A single, front-loaded sentence communicates the tool's core purpose and return contents with no filler or repetition. Every word adds value.

  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 read-only listing operation, the description provides enough context: it identifies the target resource and the key fields returned. Pagination and filter details are fully covered in the schema, so the absence of an output schema is 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%, so parameters like 'name', 'type', 'page', and 'per_page' are already well documented. The tool description adds no parameter-level meaning beyond what the schema provides, keeping this at the baseline.

  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?

  Description uses a specific verb ('List') and resource ('RRSets of a zone'), clearly distinguishing from singular get_rrset and zone-level tools. It names the key included fields (records, TTLs, protection status), leaving no ambiguity about what the tool returns.

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

  Usage Guidelines3/5

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

  Usage is implied: use this tool to list all RRSets in a zone. However, it does not explicitly contrast with get_rrset for a single RRset, export_zonefile for zone export, or list_zones for zone listing, so guidance on alternatives is weak.

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

• add_recordsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing mutating behavior. It honestly conveys that this adds to existing records and can create the RRSet, which is valuable. However, it does not mention potential duplicate handling, validation failures, or any other side effects, leaving some behavioral gaps for a mutation tool.

  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?

  Two short sentences deliver the essential semantics without filler. The first sentence names the action and resource; the second adds the two most important behavioral nuances. Every word earns its place.

  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 straightforward add operation, the description covers the main context: append semantics and creation behavior. It does not explain return values or error conditions, but with no output schema and a well-described parameter set, the core intent is sufficiently complete for an agent to select and invoke it correctly.

  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 high at 80%, and the schema already documents each parameter with examples. The tool description adds no parameter-level information, so it neither improves nor harms the schema's meaning; baseline 3 is appropriate.

  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 states a specific action ('Add records to an RRSet') and immediately clarifies the two key behavioral distinctions: existing records are preserved and the RRSet is created if absent. This clearly differentiates it from sibling tools like set_records or remove_records.

  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 clear context for when to use this tool: when you want to append records while keeping existing ones, and when the RRSet may not yet exist. It does not explicitly name alternatives, but the behavioral guidance strongly implies the contrast with replace-style tools like set_records.

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

• change_rrset_ttlA
  4/5.0
  Behavior4/5

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

  The description discloses a meaningful behavioral trait beyond the idempotentHint annotation: passing null resets to the zone's default TTL. It does not contradict the annotation, though it omits details about error behavior or whether existing records are preserved.

  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?

  Two concise sentences with the action front-loaded. No filler or repetition; every sentence adds value.

  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?

  Given the simple single-purpose mutation, the schema fully documents all four parameters, and the idempotentHint annotation covers repeat-safety, the description is adequate. It could mention return values or missing-RRSet errors, but those are not essential for this low-complexity tool.

  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 coverage is 100%, with each parameter already described in detail. The description's null-fallback note duplicates the ttl schema description, adding little new information that the schema does not already provide.

  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 and resource ('Change the Time To Live (TTL) of an RRSet') and adds the key null-fallback detail. It clearly distinguishes itself from sibling tools such as change_zone_ttl and change_rrset_protection.

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

  Usage Guidelines3/5

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

  The description implies the use case (changing an RRSet's TTL) and provides a specific usage pattern ('Pass null to fall back'), but it does not explicitly state when not to use this tool or mention alternatives like update_rrset. No exclusions or comparisons to siblings are provided.

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

• get_zone_actionA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, covering the safety profile. The description adds that it returns status and result, which is useful behavioral context. It does not go beyond that, but for a simple get-by-ID operation this is acceptable given the 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.

  Conciseness5/5

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

  A single, front-loaded sentence that states the action, the resource, and the purpose without unnecessary words. Every word earns its place.

  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 one-parameter read operation with no output schema, the description is largely complete: it explains what the tool does and why an agent would use it (check status/result). It does not specify the exact return format, but that is often unnecessary for a simple get, and the sibling list tool covers broader listing.

  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?

  The schema provides 100% coverage with a description for action_id ('ID of the action') and its type/constraints. The description adds no new parameter-specific meaning beyond referencing the ID. Baseline 3 is appropriate because the schema fully documents the parameter.

  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?

  Uses specific verb 'Get' plus resource 'single zone action by ID' and clearly states its purpose 'to check its status and result'. This directly distinguishes it from sibling list_zone_actions, which would be used for multiple actions.

  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 implies usage context: fetch one action by its ID to check status/result, which is a natural complement to list_zone_actions. It does not explicitly mention alternatives or exclusions, but the action_id parameter and singular 'a single zone action' make the intended scenario clear.

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

• list_zonesA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds value by specifying the returned fields (status, mode, default TTL, nameservers, record counts), which goes beyond the annotation. No contradictions found.

  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 a single, front-loaded sentence that conveys the tool's purpose and key output fields with no wasted words. Every element contributes to understanding.

  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?

  With no output schema, the description does well to list the returned fields. It covers the core functionality adequately, though pagination defaults and filtering options live only in the schema, which is acceptable since the schema is rich. For a simple read-only list tool, this is sufficiently complete.

  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?

  The input schema covers 100% of parameters with detailed descriptions and enums, so the baseline is 3. The tool description does not add any additional parameter-level 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.

  Purpose5/5

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

  The description uses a specific verb+resource combination: 'List the DNS zones of the Hetzner Cloud project', clearly distinguishing it from singular operations like get_zone. It also enumerates the returned fields, making the tool's purpose unmistakable.

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

  Usage Guidelines3/5

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

  The plural 'zones' and 'List' imply this is for listing multiple zones, which differentiates it from get_zone (singular), but there is no explicit 'when to use' or 'use get_zone instead' guidance. No exclusions or alternative recommendations are provided.

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

• get_zoneA
  4.1/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=true, and the description aligns with a read-only operation. However, the description adds no behavioral context beyond what the annotation implies, such as response format or error handling. Since annotations cover the safety profile, this is acceptable but not enriched.

  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 a single concise sentence that efficiently communicates the tool's purpose with no unnecessary words.

  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?

  For a simple read-only operation with one parameter and no output schema, the description is sufficient. It clearly states what the tool does, and the annotation covers the read-only behavior.

  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?

  The input schema covers the single parameter 'zone' with a description and pattern. With 100% schema coverage, the description does not need to add parameter details, and it does not. Baseline of 3 is appropriate.

  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 specifies the action (Get), the resource (DNS zone), and the scope (full details of a single zone). It distinguishes from siblings like list_zones (multiple) and delete_zone (mutation).

  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 implies when to use this tool (when you need full details of a single zone) but does not explicitly mention alternatives or when not to use it. It provides clear context without exclusions, so it is adequate but not exhaustive.

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

• list_zone_actionsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint; the description adds clarifying context that 'actions' are asynchronous operations like zone file imports, which helps the agent understand the domain without repeating annotation data.

  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?

  Single, front-loaded sentence with a parenthetical for clarification. Every word earns its place; no redundancy.

  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?

  For a read-only listing operation with clear schema and annotations, the description is fully adequate. It explains the domain concept (actions) and the filtering behavior without unnecessary details.

  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%, so the description doesn't need to elaborate on parameters. It adds the relational nuance 'if one is given' which matches the zone parameter, but this is minor value beyond the schema.

  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?

  Clear verb 'List' with specific resource 'zone actions' and scope ('of all zones, or of a single zone if one is given') that distinguishes it from siblings like list_zones and get_zone_action.

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

  Usage Guidelines3/5

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

  Usage context is implied through the conditional 'if one is given' but no explicit comparison to alternatives like get_zone_action or list_zones, nor any when-not-to-use guidance.

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

• change_zone_protectionA
  4.2/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description discloses important behavioral details: enabling is immediate, disabling requires a confirmToken and is 'exactly like a deletion.' This adds meaningful context about the two-step flow and risk profile that the annotation alone doesn't convey. No contradiction with 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 two sentences, front-loaded with the core action, and the second sentence efficiently conveys the critical exception for disabling. Every word earns its place, with no redundancy or fluff.

  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?

  The description adequately covers the tool's main purpose and the crucial confirmToken requirement for disabling. It doesn't describe return values, but the schema already explains the token return in the confirmToken parameter description. For a simple toggle tool with rich schema documentation, this is sufficiently complete, though a brief mention of the response would make it fully self-contained.

  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?

  The input schema provides 100% coverage with descriptions for all three parameters, including the confirmToken flow. The description adds minimal additional parameter meaning beyond what the schema already offers (it reinforces the token requirement but doesn't introduce new syntax or semantics). Baseline of 3 is appropriate given the high schema coverage.

  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's function: enabling or disabling delete protection of a DNS zone. It uses a specific verb ('enable or disable') and resource ('delete protection of a DNS zone'), which distinguishes it from sibling tools like delete_zone or update_zone.

  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 provides clear context on when the tool is used (for toggling delete protection) and highlights the special requirement for disabling (needs a confirmToken). It implicitly contrasts with delete_zone by noting the protection is the 'last safeguard' against deletion, though it doesn't explicitly name alternatives or say when not to use the tool.

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

• change_zone_ttlA
  4.2/5.0
  Behavior3/5

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

  Annotations only declare idempotentHint=true, so the description carries most of the behavioral burden. It adds useful context that the change affects only RRSets lacking an explicit TTL, but it does not describe other behavioral aspects such as response, propagation, or whether existing explicit TTLs are preserved.

  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 concise sentences with no wasted words. The main action is front-loaded, and the clarifying scope statement earns its place without redundancy.

  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 two-parameter mutation tool, the description provides enough context to understand the operation and its scope. The output schema is absent and annotations are minimal, but the description covers the key distinction from per-RRSet TTL changes, making the tool sufficiently understandable.

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

  Parameters4/5

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

  The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds value beyond the schema by clarifying that the ttl parameter is the default TTL for the zone and applies only to RRSets without an explicit TTL, which gives deeper semantic meaning.

  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 changes the default TTL of a DNS zone, with a specific verb and resource. It also distinguishes itself from the sibling change_rrset_ttl by scoping the change to the zone-level default and clarifying it applies only to RRSets without an explicit TTL.

  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 implies when to use this tool: when setting the zone-wide default TTL rather than an individual RRSet's TTL. It does not explicitly name an alternative tool like change_rrset_ttl, but the phrase 'default' and 'without an explicit TTL' gives clear contextual guidance.

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

• create_zoneA
  4.2/5.0
  Behavior3/5

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

  Annotations are empty, so the description must carry the safety and behavior burden. It discloses the mutating nature (create) implicitly and notes that the zonefile is ignored for secondary zones, adding useful context. However, it does not disclose potential side effects like uniqueness validation, DNS propagation, or that TSIG keys are secrets (though the schema mentions that). This is a moderate gap, hence a 3.

  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, consisting of three sentences that directly explain the tool's purpose and key usage distinctions. It is front-loaded with the core action and immediately follows with critical mode guidance. No extraneous information or repetition of the schema, earning a 5.

  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?

  Given the tool's moderate complexity (6 params including nested objects), the description covers the key decision points (mode choice, primary_nameservers requirement, zonefile option). The lack of output schema does not require explanation since it's a creation tool, and the schema provides sufficient detail for parameters. It is complete enough for an agent to invoke correctly, though it could optionally mention error cases, but that is not critical.

  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?

  The schema has 100% coverage of parameters with descriptions, so the baseline is 3. The description adds value by explaining the high-level relationship between mode, primary_nameservers, and zonefile, but it does not go beyond the schema's detailed parameter explanations. The description complements rather than replaces the schema, so a 3 is appropriate.

  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 (create a new DNS zone), the resource (DNS zone), and critically distinguishes between the two modes (primary and secondary) with specific conditions. This differentiates it from sibling tools like update_zone or list_zones, as it focuses on creation and highlights the mode-specific initialization.

  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 provides explicit usage guidance by explaining when to use each mode: 'primary' for zones managed at Hetzner, 'secondary' with primary_nameservers for transfers. It also mentions the optional zone file initialization, giving clear context on when this tool is appropriate versus alternatives.

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

• update_zoneA
  4.2/5.0
  Behavior4/5

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

  The description discloses the key behavioral trait that the given set replaces all existing labels, which is crucial for an update operation. The annotation idempotentHint=true is present, and the description doesn't contradict it. It adds value by clarifying the replacement semantics, which is beyond what the annotation provides. However, it doesn't mention any other behavioral aspects like permissions or side effects, but given the annotation coverage, this is adequate.

  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 primary purpose, and every sentence earns its place. It is concise and well-structured, with no wasted words.

  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?

  Given the tool's simplicity (2 params, no output schema, idempotent annotation), the description is complete enough. It covers the purpose, the replacement behavior, and the distinction from other zone property tools. The only minor gap is not explicitly stating the return value, but since there's no output schema, that's not required. Overall, it's well-rounded for the tool's complexity.

  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?

  The schema description coverage is 100%, with both parameters (zone and labels) having descriptions. The description adds the key semantic that the labels set replaces all existing labels, which is not fully captured in the schema. However, the schema already provides adequate parameter descriptions, so the description adds marginal value beyond the schema.

  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 updates DNS zone labels, specifies that the given set replaces all existing labels, and distinguishes it from other zone property changes via dedicated change_zone_* tools. This is a specific verb+resource with clear scope and sibling differentiation.

  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 explicitly notes that the given set replaces all existing labels, which is a critical usage guideline. It also mentions that other zone properties are changed via dedicated change_zone_* tools, providing clear context for when not to use this tool. However, it doesn't explicitly state when to use this tool versus alternatives beyond the label replacement context.

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

• change_primary_nameserversA
  4.4/5.0
  Behavior4/5

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

  Beyond the destructiveHint annotation, the description discloses that the entire zone content will be replaced from new primaries and explains the confirmation token flow. It does not describe all side effects in detail but adds meaningful behavioral context.

  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?

  Description is concise with four sentences, each providing essential information: purpose, side effect, applicability, and workflow. No redundant wording; the structure is logical and front-loaded with the main action.

  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?

  Given the rich schema and destructiveHint annotation, the description is quite complete. It covers scope, transfer impact, secondary mode restriction, and the confirmation token process. It does not detail second-call behavior or error cases, but that is not critical for this operation.

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

  Parameters4/5

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

  Schema provides 100% parameter descriptions, so baseline is 3. The description adds value by explaining the two-step confirmation token behavior and clarifies that primary_nameservers list is exactly what the token is bound to, enriching parameter understanding.

  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?

  Description clearly states the tool replaces primary nameservers of a secondary zone, specifying the resource and action. It also distinguishes from siblings by explicitly limiting to secondary zones and explaining the transfer context.

  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 clearly states applicability ('Only applicable to zones in secondary mode') and explains the transfer process, but it does not explicitly mention alternative tools or when-not-to-use scenarios beyond the secondary zone restriction. This is clear context but slightly lacks explicit exclusions.

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

• delete_rrsetA
  4.4/5.0
  Behavior5/5

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

  Beyond the destructiveHint=true annotation, the description discloses irreversibility, the short-lived confirmation token, and the requirement to ask the user before confirming. This adds significant behavioral context that annotations alone do not provide.

  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 core purpose, and every clause adds value: irreversibility, scope of deletion, and the confirmation workflow. No wasted words.

  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 destructive tool with no output schema, the description covers the essential workflow and irreversibility. It does not describe the post-deletion response or edge cases like protected zones, but the schema and annotations fill most gaps, making this sufficiently complete for correct invocation.

  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%, and each parameter already has a clear description, including confirmToken's omit-on-first-call behavior. The tool description adds workflow context but no additional parameter-level meaning beyond what the schema provides, 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.

  Purpose5/5

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

  The description uses a specific verb and resource: 'Permanently delete an RRSet (DNS record set) with all its records.' It clearly distinguishes this from sibling tools like delete_zone (zone-level deletion) and remove_records (record-level removal) by emphasizing the entire RRSet is deleted.

  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 clearly explains the required two-step workflow: first call returns a confirmation token, ask the user, then call again with confirmToken. It does not explicitly name alternative tools or state when not to use it, but the 'with all its records' phrasing implies this is for whole-RRSet deletion rather than partial record removal.

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

• change_rrset_protectionA
  4.5/5.0
  Behavior4/5

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

  Beyond the idempotentHint annotation, the description reveals that disabling removes the last safeguard and requires a confirmToken, adding critical behavioral context. It also notes that enabling is immediate. This goes beyond the annotation and is not contradicted by it.

  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—two sentences—and front-loaded with the purpose. The second sentence adds essential behavioral detail without unnecessary fluff. Every sentence earns its place.

  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 complexity (5 parameters, no output schema), the description covers purpose, behavior, and the confirmToken flow. The parameters are well-documented in the schema, and the description adds the missing behavioral nuance, making it complete for an agent to use correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, providing detailed descriptions for all parameters. The description adds extra meaning by clarifying that the 'change' parameter's false value (disabling) specifically requires a confirmToken, and that enabling is immediate. This reinforces the schema without repeating it.

  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 toggles change protection on an RRSet, distinguishing it from zone-level protection (sibling change_zone_protection) and other RRSet operations. It uses a specific verb ('Enable or disable') and names the target resource ('change protection of an RRSet').

  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 provides clear behavioral context: enabling is immediate, while disabling requires a confirmToken and is described as removing the last safeguard against delete_rrset and set_records. This implies when to use the tool and the caution needed, though it does not explicitly name alternative tools or exclude any use cases.

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

• create_rrsetA
  4.6/5.0
  Behavior4/5

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

  It discloses the key failure condition (duplicate name/type) and implies a write operation. However, it does not mention other potential side effects (e.g., zone update, permissions), though for a simple create this is acceptable.

  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, consisting of two sentences with no redundant information. It effectively conveys purpose and usage without fluff.

  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?

  The description covers the main behavior and failure condition, and does not need to explain return values since no output schema is provided. It could mention that the zone must exist, but that is implied by 'in a zone'.

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

  Parameters4/5

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

  The input schema already provides descriptions for all parameters (coverage 83%). The tool description adds an example that clarifies 'name' and 'type' but does not significantly enhance parameter understanding beyond the schema.

  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 verb 'Create' and resource 'RRSet', provides context 'in a zone', and includes an example ('A record for www'). It also distinguishes from sibling tools by explicitly noting when to use set_records or add_records instead.

  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 provides explicit guidance on when not to use this tool: 'Fails if an RRSet with the same name and type already exists — use set_records or add_records in that case.' This clearly delineates appropriate usage versus alternatives.

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

• remove_recordsA
  4.6/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses that removing the last record deletes the entire RRSet and explains the confirmation token mechanism (first call returns a short-lived token bound to the record list). This adds significant behavioral context not provided by the annotation, such as the two-step nature and the specific destructive consequence.

  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—two sentences—and front-loaded with the core action. The first sentence states what it does and the destructive edge case; the second explains the confirmation token flow. Every sentence contributes crucial information without redundancy.

  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?

  Given the tool's complexity (multi-step with confirmation token) and lack of an output schema, the description covers the essential behavioral aspects: matching by value, RRSet deletion on last record, and the confirmation token flow. The schema covers parameter specifics, and the description fills the key behavioral gaps. However, it does not specify what the second call returns or any prerequisites (e.g., zone existence), which would make it more complete.

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

  Parameters4/5

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

  Schema coverage is high (80%), so the baseline is 3. The description adds value by clarifying that records are matched by value and by explaining the confirmToken's purpose ('first call returns a token'), which complements the schema's description of the token as a confirmation from a previous call. This additional semantic clarity warrants a score above baseline.

  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 removes specific records from an RRSet, matched by value, and distinguishes it from sibling tools like delete_rrset (which removes the whole RRSet) and add/set records. It also highlights a key consequence (RRSet deletion when last record removed), making the 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 Guidelines4/5

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

  The description implies when to use this tool (to remove specific records from an existing RRSet) and outlines the two-step confirmation process, but it does not explicitly mention alternatives or when not to use it. The context is clear but lacks explicit exclusions or alternative tool naming.

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

• set_recordsA
  4.6/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description adds crucial behavioral detail: 'Existing records not listed are removed.' It also discloses the confirmation token mechanism, which is not implicit in the annotations, enhancing transparency about the tool's destructive and multi-step nature.

  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?

  Two sentences deliver the essential information: the primary action and its effect, plus a clear alternative and the confirmation token flow. Every word earns its place, and the key details are front-loaded.

  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?

  Given the destructive annotation, high schema coverage, and no output schema, the description covers the key aspects: replacement behavior, the token flow, and a sibling alternative. It doesn't explicitly mention prerequisites like zone existence, but those are likely handled by other tools or standard DNS context. Overall, it's sufficiently complete for an agent to use correctly.

  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 high (80%), and the schema already documents each parameter thoroughly, including the confirmToken's purpose. The description adds marginal semantic value beyond the schema; it only slightly reinforces the replacement semantics. Baseline score of 3 is appropriate given the strong schema coverage.

  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 replaces ALL records of an RRSet with given records, and explicitly notes that existing records not listed are removed. This directly differentiates from add_records (append), making the purpose 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 provides explicit guidance on when to use this tool versus an alternative: 'Use add_records to append instead.' It also explains the two-step confirmation token flow, giving clear context on how to invoke the tool correctly.

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

• update_rrsetA
  4.6/5.0
  Behavior4/5

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

  The description goes beyond the idempotentHint annotation by disclosing that the provided label set 'replaces all existing labels.' This is a key behavioral trait for an update operation, though it does not cover edge cases like missing RRSet behavior.

  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?

  Two concise sentences, front-loaded with the primary purpose and enriched with one high-value disambiguation. No wasted words or repetition of schema details.

  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 focused update tool with complete schema coverage and an idempotency annotation, the description is largely sufficient. It explains the operation, replacement behavior, and exclusions, though it does not mention potential prerequisites or return behavior.

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

  Parameters4/5

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

  The schema already documents all parameters (100% coverage), but the description adds meaning to the labels parameter by explaining it replaces the entire existing label set. It also clarifies that records and TTL parameters are intentionally handled by other tools.

  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: 'Update the labels of an RRSet.' It identifies the specific resource (RRSet labels) and the replacement semantics, distinguishing it from sibling tools that manage records or TTL.

  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 parenthetical explicitly directs record and TTL changes to named alternatives (set_records/add_records/remove_records and change_rrset_ttl), giving clear when-not-to-use guidance and making the tool's narrow scope obvious.

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

• delete_zoneA
  4.7/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses irreversibility, the deletion of all records, and the two-step confirmation flow with a short-lived token requiring user confirmation. This is exactly the kind of behavioral context that helps an agent avoid unsafe actions.

  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?

  Two sentences, front-loaded with the most critical fact (permanent deletion), and every clause adds value: scope, irreversibility, confirm flow, and user interaction. No filler.

  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?

  For a destructive tool with two simple parameters and no output schema, this description is complete. It states what is destroyed, the irreversible nature, and the confirmation protocol, giving an agent sufficient information to invoke the tool safely.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds meaningful workflow semantics for confirmToken: first call returns a token, then ask the user, then call again with the token. This goes beyond the schema's field-level description by explaining the required interaction sequence.

  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 and resource: "Permanently delete a DNS zone including all its records." It clearly distinguishes this from sibling tools like delete_rrset by stating it deletes the zone and all contained records.

  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 provides clear context: use this when you want to permanently remove a DNS zone and all its records. It does not explicitly name alternatives or state when not to use it, but the sibling list and the phrase 'including all its records' imply the contrast with record-level deletion tools.

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

• import_zonefileA
  4.7/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description discloses that records are replaced and explains the two-step token flow, including binding the token to the exact zone file and the need to ask the user. This provides substantial context beyond the annotation.

  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 three sentences with no fluff. It front-loads the core purpose, immediately warns about replacement, and then explains the confirmation flow. Every sentence earns its place.

  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 complexity (destructive, two-step, backup consideration), the description covers all essential aspects: purpose, destructive effect, confirmation procedure, and backup recommendation. No output schema exists, but the description sufficiently prepares the agent for invocation and sequencing.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context for confirmToken by emphasizing it is bound to exactly this zone file and clarifying the first-call behavior. It also notes the BIND format, which is not fully captured in the schema.

  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 imports a zone file (BIND format) into an existing primary zone and explicitly notes it REPLACES current records. This distinguishes it from siblings like export_zonefile and set_records, providing a specific verb and resource.

  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?

  It recommends considering export_zonefile first as a backup, which is an explicit alternative action. It also clearly explains the two-call confirmation workflow. However, it does not explicitly exclude other alternatives like set_records for incremental changes, so it lacks full exclusion guidance.

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