Server Quality Checklist

Tool Scores

• check_domain_availabilityA
  4.1/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations: it mentions the return of price in micro-units of the returned currency and explicitly notes that the answer may not be definitive, which relates to the FAST vs FULL distinction. The readOnlyHint and openWorldHint annotations are consistent and complemented by this added nuance.

  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, focused sentence that front-loads the core purpose and appends essential return-value details. It is concise with no filler, earning a high score for efficiency.

  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 simple tool scope, presence of an output schema, and annotations covering safety and open-world behavior, the description provides sufficient information: what it does, what it returns, and key unit caveats. No critical gaps for an agent to 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?

  The input schema already provides full parameter descriptions for both 'domain' and 'check_type' (including the FAST/FULL enum values). The description does not add new parameter-level semantics beyond what the schema offers, so it meets the baseline but does not exceed 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 uses a specific verb ('Check whether') and identifies the resource ('a domain is available to register'), clearly distinguishing it from sibling DNS management tools. It states the primary function in a single, unambiguous sentence.

  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 purpose makes the primary use case obvious, but the description provides no explicit guidance on when to choose this tool over alternatives or when to prefer FAST vs FULL. The schema describes the check_type options, but the description itself does not elaborate on usage context.

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

• delete_dns_recordA
  4.2/5.0
  Behavior4/5

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

  The description goes beyond annotations by emphasizing the 'ALL' scope of deletion and introducing the dry_run preview mechanism. This complements the destructiveHint annotation by explaining exactly what will be destroyed and how to preview 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?

  Two concise, front-loaded sentences clearly communicate the action, scope, and the dry_run option. 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?

  The description is sufficient for a destructive, bulk-delete tool, covering the core behavior and safety preview. Complete schema and annotations (destructiveHint) round out the context, though it could mention reversibility or prerequisites.

  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?

  All parameters are fully described in the input schema (100% coverage), so the description does not need to repeat them. The baseline of 3 applies since the schema handles the heavy lifting.

  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 that this tool deletes ALL DNS records of a given type and name for a domain, using specific verbs and scope. This distinguishes it from sibling tools like add_dns_record, replace_dns_records, and list_dns_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 a clear usage context: when you need to remove all records of a type and name, with a dry_run preview option. It does not explicitly mention alternatives or when not to use it, but the context is clear enough to guide selection.

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

• replace_dns_recordsA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and idempotentHint=true, and the description confirms overwriting. It adds value by clarifying that ALL matching records are replaced and by highlighting the dry_run=true preview option, providing context beyond the 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 overwrite warning, then the use case and dry_run note. Every word earns its place with zero 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?

  Given the 7-parameter schema and absence of an output schema, the description adequately covers the tool's purpose, destructive nature, use case, and preview option. It could mention response/error behavior, but annotations and schema fill most gaps, making it sufficiently complete for safe 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%, so all parameters already have clear meanings. The description adds no significant parameter semantics beyond what the schema provides; it only mentions type+name and dry_run, which are already covered.

  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 DNS records of a given type+name, using the PUT method. This specific verb+resource+scope distinguishes it from siblings like add_dns_record or delete_dns_record.

  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 explicitly says 'Use it when exactly one record should exist and duplicates must be removed,' giving a clear when-to-use condition. However, it does not explicitly name alternative sibling tools or state when not to use it, so it falls short of a 5.

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

• add_dns_recordA
  4.4/5.0
  Behavior4/5

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

  The description adds behavioral nuance by explaining the PATCH method and the non-overwriting property, which goes beyond what the annotations convey (readOnlyHint=false, idempotentHint=false). It does not describe failure modes or response shape, but the annotations already cover the low-risk safety profile, and there is no contradiction.

  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 with zero fluff. The first sentence states the primary action and its key behavioral constraint; the second identifies the alternative. Information density is high with no redundant phrasing.

  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 has 6 parameters, all documented, and a clear description with sibling differentiation, it is almost complete. No output schema is present, but the description explains the semantic intent, and annotations cover mutation flags. A slight gap is the lack of expected return value or error conditions, but these are not essential for a straightforward create-like operation.

  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 full coverage of all 6 parameters with individual descriptions, so the description need not repeat them. The description adds no parameter-specific detail, but the schema already fully documents fields like domain, record_type, data, ttl, and priority.

  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 ('Add a DNS record') and differentiates it from the sibling tool by specifying 'without overwriting existing records of the same type (PATCH)'. It also names the alternative tool to imply the intended usage scope.

  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?

  Explicit guidance is provided: use this tool to add a record while preserving existing ones, and use 'replace_dns_records instead when exactly one record should exist'. This gives the agent a direct decision rule between the two tools.

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

• list_dns_recordsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the description's added value lies in explaining the filtering behavior, especially the requirement that name filtering requires a record_type. This is useful behavioral context beyond the 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?

  Two concise sentences deliver purpose and key constraint without wasted words. Front-loaded verb 'List' immediately conveys the action.

  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 simplicity, the presence of an output schema, and annotations, the description is fully adequate. It covers the core operation, filters, and the coupling between parameters, leaving no significant gaps.

  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 covers all parameters with descriptions, so baseline is 3. The description adds the semantic constraint that 'name' filtering requires 'record_type', which is not fully explicit in the schema alone. This enriches understanding of how parameters interact.

  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 action ('List DNS records') and its scope ('for a domain'), with optional filters. It distinguishes from sibling tools that add, replace, delete, or check availability, because none of those perform listing.

  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 makes evident this is a read-only listing tool, and the sibling set clarifies alternatives (mutations and availability check). It doesn't explicitly state 'use this instead of X', but the context is clear enough.

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