Server Quality Checklist

Tool Scores

• batch_dnsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'multiple DNS lookups in a single operation,' implying batch processing, but lacks details on performance traits (e.g., rate limits, error handling for partial failures), authentication needs, or output format. For a tool with 3 parameters and no annotations, this leaves significant gaps in understanding its 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?

  The description is a single, efficient sentence: 'Perform multiple DNS lookups in a single operation.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for the tool's complexity, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the tool's complexity (3 parameters, batch operation) and lack of annotations and output schema, the description is incomplete. It doesn't address key aspects like error handling, output structure, or performance implications, which are crucial for a batch tool. The description alone is insufficient for an agent to fully understand how to use this tool effectively.

  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%, meaning all parameters are documented in the input schema. The description adds no additional meaning about parameters beyond the general batch operation context. Since the schema handles the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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's purpose: 'Perform multiple DNS lookups in a single operation.' It specifies the verb ('perform'), resource ('DNS lookups'), and scope ('multiple...in a single operation'), which is clear and specific. However, it doesn't explicitly distinguish this batch operation from the sibling 'dns_lookup' tool, which likely handles single lookups, missing 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.

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tools (dns_lookup, dns_trace, reverse_dns) or clarify scenarios like handling bulk queries versus single lookups. Without such context, users must infer usage, which is inadequate for effective tool selection.

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

• dns_lookupC
  2.9/5.0
  Behavior2/5

  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 retrieving various record types but fails to describe critical behaviors like error handling, rate limits, authentication needs, or what happens if a record type is unsupported. For a tool with multiple parameters and no annotations, this leaves significant gaps in understanding how it operates.

  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, efficient sentence that front-loads the core action ('perform DNS lookup') and includes key details (domain, record types). There is no wasted text, and it directly communicates the tool's function without redundancy or unnecessary elaboration.

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

  Completeness2/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 (4 parameters, no output schema, no annotations), the description is incomplete. It lacks information on output format, error conditions, performance characteristics, and how it differs from sibling tools. Without annotations or output schema, the description should provide more context to guide effective use.

  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 schema fully documents all four parameters. The description adds minimal value beyond the schema by listing example record types (A, AAAA, MX, TXT, etc.), which aligns with the enum in the schema. No additional syntax, format details, or constraints are provided, meeting the baseline for high schema coverage.

  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 verb 'perform DNS lookup' and resource 'domain' with specific examples of record types (A, AAAA, MX, TXT, etc.). It distinguishes the core lookup function from siblings like batch_dns (batch operations), dns_trace (tracing), and reverse_dns (reverse lookups), though it doesn't explicitly name these alternatives. The purpose is specific and actionable.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus sibling tools like batch_dns, dns_trace, or reverse_dns. It lacks context about use cases, prerequisites, or exclusions, such as when to choose batch_dns for multiple domains or reverse_dns for IP-to-domain lookups. Usage is implied but not explicitly stated.

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

• reverse_dnsB
  3.2/5.0
  Behavior2/5

  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 the core function but lacks details on error handling (e.g., for invalid IPs), rate limits, network dependencies, or what happens on timeout. For a network tool with potential failures, this is a significant gap in transparency.

  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, efficient sentence with zero waste—it directly states the tool's purpose without fluff. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly and understand the core functionality.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a network tool. It doesn't cover behavioral aspects like error responses, return format (e.g., hostname string or structured data), or network constraints. For a tool with potential complexity in DNS resolution, this leaves critical gaps for an agent to use it effectively.

  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 schema already documents both parameters ('ipAddress' and 'timeout') clearly. The description implies the 'ipAddress' parameter but adds no extra meaning beyond what the schema provides, such as format examples (IPv4 vs. IPv6) or timeout implications. Baseline 3 is appropriate as the schema does 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 the specific action ('Perform reverse DNS lookup') and the resource ('IP address'), with the goal of finding the hostname. It directly distinguishes from sibling tools like 'dns_lookup' (likely forward lookup) and 'dns_trace' (likely diagnostic tracing), making the purpose unambiguous and well-differentiated.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'batch_dns' (for multiple lookups) or 'dns_lookup' (forward DNS). It states what the tool does but offers no context about appropriate scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

• dns_traceB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions the action ('Trace') but does not disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list of DNS servers, timing). For a tool with no annotation coverage, this is a significant gap in 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?

  The description is a single, efficient sentence that is front-loaded with the core purpose. There is no wasted language, and it directly communicates the tool's function without unnecessary elaboration.

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

  Completeness2/5

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

  Given the tool's complexity (tracing DNS paths), lack of annotations, and no output schema, the description is incomplete. It does not explain what the output contains (e.g., steps in resolution, error handling), behavioral aspects, or how it differs from siblings in practical use. This leaves gaps for an AI agent to understand the tool fully.

  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 schema already documents both parameters ('domain' and 'recordType') with descriptions and enum values. The description does not add meaning beyond what the schema provides, such as explaining parameter interactions or usage nuances. Baseline 3 is appropriate 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.

  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 purpose with a specific verb ('Trace') and resource ('DNS resolution path'), specifying the scope ('from root servers to the final result'). It distinguishes from siblings like 'dns_lookup' (likely a simple lookup) and 'reverse_dns' (reverse resolution) by emphasizing the tracing of the full resolution path.

  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 tracing DNS resolution paths, but does not explicitly state when to use this tool versus alternatives like 'dns_lookup' or 'batch_dns'. It provides context (tracing from root to final result) but lacks explicit guidance on exclusions or specific scenarios where this tool is preferred over others.

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