Server Quality Checklist

Tool Scores

• extract_with_schemaC
  2.8/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 only says 'Extract structured data' — it doesn't reveal whether it executes live HTTP requests, how it handles multiple URLs, whether output is validated/returned against the schema, or what happens on failure. For a data-extraction tool with zero annotation coverage, this is a significant transparency gap.

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

  Conciseness3/5

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

  The description is a single efficient sentence with no wasted words, which is good for conciseness. However, the brevity masks missing critical context; it is underspecified rather than appropriately concise, so it doesn't earn full marks for effective structure.

  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 tool with 3 parameters, nested schema objects, no output schema, and no annotations, this description is markedly incomplete. It fails to explain the relationship between prompt and schema, the behavior with multiple URLs, expected output format, or error handling. An agent cannot fully know how to construct a correct call or interpret results from this description alone.

  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 schema already documents all three parameters with descriptions. The description's 'using a JSON schema' merely echoes the schema parameter's purpose without adding syntax, format, or interaction details — e.g., how 'prompt' modifies the schema-driven extraction. 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.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb (Extract), a resource (structured data), and a mechanism (using a JSON schema), giving the agent a basic sense of what the tool does. However, it doesn't differentiate from the sibling 'extract_data' — with two extraction tools present, the description leaves the agent unsure how extract_with_schema differs from extract_data beyond the name's hint about schema-driven extraction.

  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 is given on when to use this tool versus siblings like extract_data, scrape_page, or batch_scrape. There is no when/to-use, when-not-to-use, or alternative routing. The name and description imply a schema-based extraction use case, but the agent must infer the selection criteria entirely.

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

• screenshotB
  3.1/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 'stealth browser' which hints at anti-detection behavior, but it does not disclose other relevant traits such as how the page is loaded (e.g., JavaScript execution), what happens on failures, or any return format. This leaves significant gaps in understanding the tool's runtime behavior.

  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?

  The description is a single concise sentence with no wasted words. It is front-loaded with the core action. However, it lacks the substance to fully support other dimensions, but as a concise statement it is efficient and appropriate for the tool's simplicity.

  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. It fails to explain what the screenshot output looks like (e.g., image format, whether it returns binary data or a URL), or any additional context about usage, limitations, or integration with other tools. For a tool with four parameters and no output schema, this is a clear gap.

  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 input schema provides 100% coverage for all parameters with clear descriptions (url, width, height, fullPage). The tool description itself does not add any additional parameter semantics beyond what the schema already states, so the 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 tool takes a screenshot of a webpage using a stealth browser. This specific verb+resource combination ('take a screenshot of a webpage') clearly distinguishes it from sibling tools like scrape_page or extract_data, which focus on data extraction rather than visual capture.

  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?

  There is no guidance on when to use this tool versus alternatives (e.g., scrape_page for text extraction). It does not mention any prerequisites, limitations, or typical use cases. The context 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.

• extract_dataB
  3.2/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full burden. The phrase 'using LLM' is genuinely useful behavioral context — it signals non-determinism, cost, and latency. However, nothing is disclosed about failure behavior, result format, rate limits, or the read-only nature of extraction beyond what the verb 'extract' implies.

  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?

  The description is a single tight clause with the verb front-loaded and zero filler words. It is appropriately brief for a tool whose parameters are already well-documented in the schema, though it could afford a bit more substance.

  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 two-parameter tool with complete schema coverage and no output schema, the description is mostly adequate on inputs. But it does not address the ambiguity with 'extract_with_schema', nor does it clarify what a successful extraction returns. These are notable gaps for a tool of moderate complexity.

  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%, with both 'urls' and 'prompt' already described in the schema ('URLs to extract data from' and 'Instructions for what data to extract'). The tool description adds nothing beyond this, so it sits at the baseline of 3.

  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 a specific verb ('extract'), resource ('structured data from webpages'), and method ('using LLM'), so the core purpose is clear. However, it does not distinguish itself from the sibling 'extract_with_schema', which likely exists precisely for schema-driven extraction. Without differentiation, an agent cannot tell which variant to pick.

  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 usage guidance is provided at all. The description does not say when to choose this tool over the closely related siblings (scrape_page, batch_scrape, extract_with_schema), nor does it mention any exclusions or prerequisites such as LLM cost or token limits.

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

• scrape_pageA
  3.5/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 only states the basic extraction action and does not explain output format, handling of JavaScript-heavy pages, what 'main content' means, or any limitations. This is a significant gap for a scraping tool.

  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 concise sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or filler.

  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 2-parameter tool with no output schema, the description covers the basics. However, it lacks context about how this tool compares to sibling tools like extract_data and extract_with_schema, and does not hint at what the returned content might include, leaving some ambiguity.

  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%, with both url and onlyMainContent already described. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.

  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 action ('extract'), the resource ('content'), and the scope ('a single webpage'), which distinguishes it from batch_scrape. It is specific and unambiguous.

  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 'single webpage' implies a single-page use case compared to batch_scrape, but there is no explicit guidance on when to use this tool versus alternatives like extract_data or extract_with_schema. No exclusions or alternative recommendations are provided.

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

• batch_scrapeA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action, offering no information about failure handling, rate limits, concurrency, return format, or whether partial failures are tolerated. This is a significant gap for a batch 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 a single, front-loaded sentence that conveys the core functionality without any wasted words. It is appropriately concise for the tool's simplicity.

  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 the simple schema, the lack of annotations and output schema means the description must explain return values and operational nuances. It does not, leaving an agent uncertain about response format, error behavior, or batch limits. The description is incomplete for a batch tool.

  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 schema already documents both 'urls' and 'onlyMainContent'. The description adds no additional parameter semantics beyond what the schema provides, matching the baseline of 3.

  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 'Scrape multiple URLs in a single request' clearly states the verb (scrape), the resource (multiple URLs), and the batching aspect, which distinguishes it from siblings like scrape_page (single page) and extract_data (extracting specific data). The purpose is immediately clear.

  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 usage for scenarios involving multiple URLs in one request, which provides clear context. However, it does not explicitly mention when not to use it or name alternatives, so it falls slightly short of a 5.

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