Server Quality Checklist

Tool Scores

• web_scrapeA
  3.8/5.0
  Behavior4/5

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

  The annotation readOnlyHint: true covers the read-only nature, and the description adds behavioral details like truncation (ending with '[truncated]') and the fact that cut-off content cannot be fetched later. It also mentions respecting robots.txt via the parameter description. This goes beyond the annotation, though it could be more explicit about side effects (or lack thereof).

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

  Conciseness2/5

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

  The description is overly verbose and repetitive, repeating the same pattern for max_chars and truncation ('each page separately... 5 links stay under the limit each...'). This could be condensed into a single statement about per-page behavior without the redundant numeric examples. The structure is not poorly organized, but the wordiness hurts usability.

  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 presence of an output schema, the description does not need to explain return values, so it is appropriately scoped. It covers key behaviors like batching, per-page limits, robots.txt, timeout, and link removal. Minor gaps exist (e.g., error handling), but overall it equips an agent with the necessary context to use the tool effectively.

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

  Parameters5/5

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

  Every parameter is thoroughly described in the schema, with examples like 'default and maximum 20000' for max_chars and 'timeout for the whole call' for timeout_ms. The tool description reinforces these semantics, such as the per-page application of max_chars. No parameter lacks context.

  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 primary function: downloading pages and returning main text as markdown. It also specifies parallel fetching and batching, which is a distinctive capability. However, the repeated phrasing about per-page limits slightly detracts from the core purpose statement.

  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 a clear batching instruction ('batch all links you need into one call instead of calling the tool per link'), which is a useful usage tip. However, it does not explicitly contrast with sibling tools like web_search or web_search_images, leaving some ambiguity about when to choose this over alternatives. It lacks guidance on 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.

• web_search_imagesA
  4.4/5.0
  Behavior4/5

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

  The description surfaces behavioral traits beyond the readOnlyHint annotation. It explicitly calls out parallel execution, the all-time default for the date field, and the behavior of query operators ('-'), which is not inferable from the annotations or schema alone. While some rate-limit or pagination details are absent, the description meaningfully enriches the behavioral context for a tool that is already annotated as read-only.

  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 presented in clearly separated paragraphs with a helpful header and line breaks that break down functionality into easily scannable pieces. Each section—purpose, language constraint, freshness, query operators—adds distinct value without tangents. The formatting makes the tool behavior easily discoverable at a glance.

  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 complexities of the tool: parallel queries, the date filter, and query operators. It gracefully relies on the schema for parameters like max_images and timeout_ms, and the presence of an output schema covers return-value expectations. There is just enough added context for correct invocation, and the couple of minor gaps (e.g., total-result cap) are not material to correctness in most scenarios.

  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 for parameters is 100%, and the description complements this by explaining semantics like the interpretation of date values and how the 'queries' array drives parallel execution. It also adds the English-only constraint that is not obvious from the schema. The description would need to add similar value for all parameters, but it already fills gaps in 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?

  The description opens with a specific verb and resource: 'Searches for images by one or more queries, executed in parallel.' It not only states what the tool does but differentiates it from siblings by highlighting parallel execution and the image-specific scope (vs web_search). The purpose is immediately clear even before reading the parameter details.

  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 adds contextual usage guidance, such as 'Queries must be in English ONLY,' the date field usage with explicit values ('d', 'w', 'm', 'y'), and the query operator syntax (site:, quotes, '-'). However, it does not explicitly differentiate when to use this tool versus its siblings (e.g., 'use other tools for non-image searches'), so the exclusions could have been spelled out further.

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

• web_searchA
  4.6/5.0
  Behavior4/5

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

  Annotations already mark readOnlyHint=true, and the description adds meaningful behavioral context: parallel query execution, the English-language requirement, freshness filter semantics, and query operator behavior. 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.

  Conciseness4/5

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

  Purpose is front-loaded and the alternative tool is named early. The later operator list is dense but each element earns its place; only mild redundancy with the schema's date descriptions.

  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?

  With an output schema present, return values need no explanation. The description covers purpose, alternative tools, language guidance, recency filtering, and operator syntax, making it complete for correct invocation.

  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 the baseline is 3. The description adds real value beyond the schema by explaining query operators (site:, filetype:, quotes, minus, intitle:) and giving usage rationale for the 'date' 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?

  States a specific verb and resource: 'Searches the web for one or more queries and returns snippets with links.' Explicitly differentiates from web_search_images, so an agent can distinguish this tool without inspecting schemas.

  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?

  Provides explicit guidance on when to use web_search_images instead, and notes both tools can be called in the same turn. Also gives clear direction on when to set the 'date' field for time-sensitive queries.

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