Server Quality Checklist

Tool Scores

• web_fetchC
  2.8/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It only mentions fetching and optional extraction, but says nothing about caching (despite bypass_cache parameter), content truncation (max_chars), output format (output_format), or error behavior. The term 'return its content' is vague and omits behavioral details that would help an agent understand side effects or limits.

  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 sentence that is front-loaded with the core action and includes a useful qualifier. No wasted words; appropriate length for the content provided.

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

  Completeness1/5

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

  Given 5 parameters, no schema descriptions, and no annotations, the description is drastically incomplete. It fails to cover output format, caching, truncation, or any operational constraints. An agent cannot safely invoke this tool correctly without additional undocumented knowledge.

  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 explain any parameters beyond the vague reference to extraction. It does not clarify what url, max_chars, bypass_cache, or output_format do, leaving the agent to rely solely on parameter names and defaults, which are insufficient for correct usage.

  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?

  Clearly states a specific action (fetch a URL), the resource (URL), and the outcome (return its content) with an optional behavior (extracting the main article). This distinguishes it from sibling tools like web_search (search) and web_crawl (multiple pages).

  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?

  No guidance on when to use this tool instead of alternatives like web_crawl or web_extract. The 'optionally extracting the main article' hint is only about a parameter, not about selecting this tool over others. Lacks exclusions or recommended contexts.

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

• web_extractC
  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, but it only states the core action. It doesn't describe behavior for selectors that match nothing, whether the page must be pre-fetched/cached, rate limits, or error handling. For a network tool this is a notable gap.

  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?

  A single efficient sentence with zero filler, front-loading the core purpose and mechanism. It earns its length, though it could have used its brevity to add a critical detail about the rules format.

  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?

  The output schema covers the return format, but the tool has two required parameters, one of which (rules) has an unspecified format, no usage guidance relative to siblings, and no behavioral expectations. For a 2-param tool this is thin — the agent lacks enough to invoke it correctly on the first try.

  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?

  Schema description coverage is 0%, so the description must compensate. It tells us the tool uses CSS selectors (hinting at the rules parameter) and that url is the target page, but it doesn't specify the rules string format — is it a JSON mapping of field names to selectors, a list, or a single selector? This ambiguity puts the burden on the agent to guess.

  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 verb (extract) + resource (web page) + mechanism (CSS selectors), and the phrase 'structured data' signals it differs from simply fetching raw content. This conceptually distinguishes it from siblings like web_fetch and web_crawl, which an agent could infer even without explicit sibling comparison.

  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?

  No guidance on when to use web_extract versus web_fetch or web_search. The description doesn't state when extraction is preferable to a raw fetch, whether extraction works on JS-rendered pages, or any conditions under which a sibling should be chosen instead.

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

• web_searchC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure on its own. It reveals that Bing is tried first, DuckDuckGo is a fallback, and no API key is needed—useful behavioral traits. However, it does not describe the output format (beyond 'structured results'), error behavior, pagination, or rate limits. It adds some value but is not comprehensive, so a 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.

  Conciseness5/5

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

  Two sentences with zero filler. The core action is front-loaded, then the fallback and no-key facts are added efficiently. Every word earns its place; this is a model of concise writing.

  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 has 4 parameters (1 required), no annotations, and an output schema, the description is incomplete. It fails to explain parameter meanings/format, does not guide tool selection relative to siblings, and does not describe the structure of results explicitly. While the output schema may cover return format, the absence of usage guidance and parameter semantics leaves an agent under-informed.

  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%, so the description must compensate for all parameter ambiguity. It does not mention query, region, max_results, or safe_search at all. An agent gets no hint about what 'region' expects (e.g., language/country code) or the meaning of safe_search beyond its name. This is a significant gap.

  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 ('Search') and resource ('the web'), and adds 'return structured results,' which is specific and distinguishes it from fetch/crawl/extract siblings. However, it does not explicitly name any sibling or contrast with alternatives, so it does not fully earn a 5.

  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?

  No explicit guidance on when to use this tool versus the sibling tools (web_fetch, web_crawl, web_extract). There is no mention of prerequisites, exclusions, or scenarios where this tool is inappropriate. The context is only implied by the name, so the description does not help an agent decide between alternatives.

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

• web_crawlB
  3.3/5.0
  Behavior3/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 does add useful details: concurrent fetching per depth level and robots.txt respect by default. However, it omits important behaviors such as how limits (max_pages, max_depth) are enforced, what happens on redirects or errors, and how same_domain_only is applied. Some behavior is disclosed, but the coverage is partial.

  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 short sentences, with the core purpose front-loaded. The second sentence adds relevant behavioral details without fluff. Every phrase earns its place; no redundancy or filler.

  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?

  For a crawl tool with six parameters, no annotations, and an output schema that is not explained, the description is thin. It does not cover how results are returned, how same-domain restrictions work, error handling, or how the crawl terminates. While the output schema exists, the description still lacks context about default behaviors and edge cases that an agent needs to invoke the tool safely and effectively.

  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 input schema has 0% description coverage, so the description must compensate by explaining parameter roles. The description only vaguely hints at depth and page limits ('respecting depth and page limits') and concurrency ('Fetches pages concurrently'), but does not explicitly define any of the six parameters: seed_url, extract, max_depth, max_pages, concurrency, or same_domain_only. This is minimal compensation for a schema with no descriptions.

  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: 'Crawl a website starting from a seed URL, respecting depth and page limits.' The verb 'crawl' is specific and distinguishes it from siblings like web_fetch (single page) and web_search (query-based). No ambiguity about the resource or scope.

  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 gives no explicit guidance on when to use web_crawl versus alternatives. It does not mention web_fetch, web_search, or other siblings, nor does it state conditions like 'use this for multi-page traversal or when you need to discover links.' The only implicit clue is the word 'crawl,' which is not enough for an agent to reliably choose it.

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

• cache_clearA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden. It discloses the action ('clear') and the return value (count), but does not warn about irreversibility or potential system impact. For a destructive operation, more cautionary detail is expected.

  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 imparts both the action and the return value with no filler. It is perfectly concise for the tool's simplicity.

  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 zero-parameter, simple operation, the description covers the action and result adequately. However, it omits any mention of side effects (e.g., performance degradation, need for re-fetching) or safety warnings, leaving a complete picture slightly lacking.

  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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and no parameter information is omitted since the schema is empty.

  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 a specific action ('Clear') on a specific resource ('all cached entries'), which is distinct from sibling tools like web_search or cache_stats. No ambiguity about the tool's function.

  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 does not mention prerequisites, contexts (e.g., when cache is stale), or warn against misuse. Sibling tool cache_stats exists but no differentiation is offered.

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

• cache_statsA
  4.2/5.0
  Behavior3/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 states the tool 'returns' statistics, implying a read-only operation with no side effects, but it does not explicitly affirm that it does not modify the cache, nor does it mention any access requirements or potential large payloads. The listed return fields add transparency, but the lack of explicit behavioral caveats keeps this at a passing but not exceptional level.

  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 purpose and then lists the specific statistics returned. Every word contributes value; there is no redundancy or filler.

  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 (zero parameters, no annotations) and the presence of an output schema (which likely documents the return format), the description covers the essential behavior. It could be slightly more complete by explicitly stating that this is a read-only inspection and noting any prerequisites, but nothing critical is missing.

  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 is empty (0 parameters), so there are no parameters to describe. Per the rubric, a zero-parameter tool gets a baseline of 4. The description adds no parameter information because none exists, which 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 a verb ('return') and a resource ('cache statistics'), and enumerates exactly what is returned (entry count, total size, TTL, limits). It is unambiguously distinct from sibling tools like web_search or cache_clear, which are about web operations or cache clearing.

  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 indicates the tool is for inspecting cache state, which provides clear context for when to use it (when cache statistics are needed). However, it does not explicitly mention alternatives or exclusions, though the distinct resource and zero parameters make usage fairly obvious without further guidance.

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