Server Quality Checklist

Tool Scores

• fetchB
  3/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 disclosing behavioral traits. It says 'Fetch full content', which implies a read-only operation, but it does not explicitly confirm non-destructiveness, mention rate limits, authentication requirements, or potential side effects. The description also lacks context on how 'fresh' and 'max_chars' affect the request, leaving behavioral nuances undisclosed.

  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 sentence that front-loads the core action ('Fetch full content') and wastes no words. It is appropriately sized for the simplicity of the tool, though it could benefit from a bit more detail without harming conciseness.

  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 moderate complexity (4 parameters, 1 required), an output schema, and no annotations, the description is too brief to be complete. It does not explain the purpose or semantics of 'focus', 'fresh', or 'max_chars', nor does it provide enough workflow context beyond the vague 'post-discovery assist'. The agent would struggle to invoke the tool optimally without additional information.

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

  Parameters2/5

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

  The schema description coverage is 0%, so the description must compensate for the missing parameter meanings. It only explains the 'url' parameter as 'known HTTP(S) URL' and provides no explanation for 'focus', 'fresh', or 'max_chars'. These names are somewhat self-explanatory, but 'focus' is ambiguous and 'fresh' could be misinterpreted, making the description insufficient for correct parameter usage.

  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 identifies the tool's action: 'Fetch full content for a known HTTP(S) URL'. This specific verb+resource combination distinguishes it from siblings like 'search' (which likely finds URLs) and 'health' (a status check). The parenthetical 'post-discovery assist' adds context, though it does not explicitly name alternatives.

  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 phrase 'post-discovery assist' implies the tool is intended for use after a discovery step, suggesting when it might be appropriate, but it gives no explicit guidance on when to use it versus alternatives. There are no exclusion criteria or comparisons to sibling tools like 'search'.

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

• searchB
  3.3/5.0
  Behavior3/5

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

  With no annotations present, the description carries the transparency burden. It discloses that searches are orchestrated via Grok as primary and Tavily/AnySearch/Firecrawl as supplements, offering a useful behind-the-scenes behavior. However, it does not state whether the tool is read-only or if any authentication/rate limits apply, though search is typically non-destructive.

  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 entire description is one concise sentence with no filler. It directly communicates the tool's purpose and orchestration behavior, earning every word.

  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 8-parameter complexity and lack of parameter description, a single sentence is insufficient. The description does not cover key usage aspects like acceptable values, relationships between parameters, or filtering behavior, though the output schema covers return shape.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description fails to elaborate on any of the 8 parameters. It does not explain how 'mode', 'depth', 'fresh', or domain filters should be used, leaving the agent to rely solely on parameter names and enums. This is a significant gap for proper tool invocation.

  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 'Orchestrated web search' which clearly identifies the tool's function—performing web searches using multiple providers. It distinguishes from siblings ('health' and 'fetch') by being a search operation rather than health check or URL fetcher.

  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 provides no explicit guidance on when to use this tool versus alternatives. It only implies web search use, leaving the agent to infer that 'fetch' would be for retrieving specific URLs. No exclusions or alternative conditions are mentioned.

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

• healthB
  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 discloses that probes are 'bounded cached', implying safe execution, but does not describe default behavior when probe=false, potential side effects, return format, or whether the operation is read-only. This is minimal behavioral disclosure for a tool with zero annotation support.

  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 sentence that efficiently front-loads the tool's purpose and then clarifies the parameter behavior. Every word contributes to meaning, with no unnecessary elaboration.

  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?

  For a simple one-parameter tool with an output schema, the description covers the core purpose and parameter semantics. However, it lacks explicit usage guidance and default behavior context, making it minimally complete but not thorough.

  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 only defines a 'probe' boolean with a default. The description adds meaning by explaining that setting probe=true triggers 'bounded cached probes', clarifying the effect of the parameter. This goes beyond the schema's bare title and default value.

  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 states 'Provider configuration and circuit health', which clearly indicates the tool's purpose as a health-check resource. It differentiates from sibling tools 'search' and 'fetch' by focusing on health rather than data retrieval, though it lacks an explicit verb like 'get' or 'check'.

  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 mentions 'probe=true runs bounded cached probes', which gives guidance on using the optional parameter but does not explicitly state when to use this tool versus alternatives. The usage context is implied as a health check, but no exclusions or alternative tool references are provided.

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