Server Quality Checklist

Tool Scores

• extract_by_selectorB
  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 full burden for behavioral disclosure. It does not mention whether the tool is read-only, error handling, rate limits, or what happens with no matches. The description gives limited behavioral insight beyond basic functionality.

  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: the first defines the tool's purpose, and the second provides a concrete example. No unnecessary words or redundancy.

  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?

  Despite having 5 parameters and no output schema, the description lacks details on return format, error cases, or typical usage patterns. The example is helpful, but overall completeness is low for a data extraction tool that returns results.

  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 coverage is 100%, so the baseline is 3. The description adds value by showing an example of the 'attribute' parameter and briefly explaining 'render' options, but most parameter meaning is already clear from the schema.

  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 function: extract specific data from a page using CSS selectors, returning text or attribute values. It effectively differentiates from sibling tools like 'extract_links' and 'fetch_page' by specifying selective extraction via selectors.

  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 an example of using the 'attribute' parameter but does not explicitly state when to use this tool versus its siblings or when not to use it. The usage context is implied but not clearly delineated.

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

• extract_linksB
  3.4/5.0
  Behavior2/5

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

  No annotations provided, so the description must disclose behaviors. It mentions URL resolution and same-domain filtering but omits critical details like error handling, performance impact of 'render' modes, or what happens if no links are found.

  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 covering the core purpose and optional restriction. No unnecessary words, front-loaded with the main action.

  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?

  Missing output schema and no description of return format. Behavioral and edge-case details (e.g., empty results, error states) are absent. Sibling differentiation is adequate but incomplete for an agent to fully assess suitability.

  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 coverage is 100% with detailed descriptions. The description adds value by explaining 'resolved to absolute URLs' and 'restrict to same domain', but doesn't go beyond the schema's own documentation significantly.

  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 it extracts hyperlinks from a web page, resolves them to absolute URLs, and optionally restricts to same domain. It effectively distinguishes from sibling tools like crawl_site (multi-page) and extract_by_selector (CSS-based).

  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 extracting links from a single page but lacks explicit guidance on when to use this vs. siblings (e.g., craw_site for multiple pages). No mention of prerequisites or when not to use.

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

• crawl_siteA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description should fully disclose behavior. It mentions returning a short content summary and staying on the same domain, but does not explicitly state that the tool is read-only or discuss rate limiting, authorization, or potential side effects. The lack of such details leaves some ambiguity.

  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 extremely concise: only two sentences that convey the essential purpose, behavior, and default constraint. No unnecessary words or redundant repetition.

  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 complexity (8 parameters, no output schema), the description covers the core functionality and default behavior. It does not describe error handling or output structure beyond a 'short content summary,' but the format parameter addresses output style. Slightly lacking in completeness but adequate.

  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 coverage is 100%, so the input schema already describes all parameters adequately. The description adds no extra parameter-specific meaning beyond what the schema provides. Baseline score of 3 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 states the verb 'crawl' and the resource 'website', specifying recursive behavior, depth and page limits, and domain restriction. It differentiates from sibling tools like fetch_page (single page) and extract_by_selector (targeted extraction).

  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 implies when to use this tool (multi-page, domain-restricted crawling) but does not explicitly contrast with siblings or state when not to use it. The context of staying on the same domain is helpful but could be more explicit.

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

• fetch_pageA
  4/5.0
  Behavior4/5

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

  The description discloses the automatic use of a headless browser for JavaScript-heavy pages, a key behavioral trait. However, since there are no annotations, it could further clarify that it is a read-only operation.

  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 purpose and output formats, with no extraneous information.

  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 adequately covers the return value (readable content in three formats) and highlights JS rendering. It does not mention edge cases or error handling, but for a simple fetch tool it is sufficient.

  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 coverage is 100%, so the baseline is 3. The description adds no additional parameter details beyond what the schema already provides.

  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 fetches a single web page and returns content in multiple formats. It distinguishes itself from sibling tools like crawl_site (multiple pages) and extract_by_selector (specific elements).

  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 single-page content retrieval but does not explicitly mention when to use this tool versus siblings like crawl_site or extract_links. No alternatives are suggested.

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