Server Quality Checklist

Tool Scores

• one_searchB
  3.2/5.0
  Behavior3/5

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

  The description states it returns SERP results (url, title, description), which is helpful. However, with no annotations, it lacks details on pagination, rate limits, or blocking behaviors. It adequately covers the basic return value but could be more transparent.

  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 with two sentences, front-loading the purpose. Every sentence adds value with 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?

  Given the absence of an output schema and the presence of 5 parameters (including enums for categories and timeRange), the description does not fully explain the usage of these parameters or the structure of the response beyond basic SERP fields. It feels incomplete for an agent to use effectively.

  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?

  Input schema coverage is 100%, so the schema already describes all parameters. The description adds no extra meaning beyond what the schema provides.

  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 searches and retrieves content from web pages and returns SERP results with URL, title, and description. It is specific but does not explicitly distinguish itself from sibling tools like one_map or one_scrape.

  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 provided on when to use this tool versus alternatives. No when-not-to-use or prerequisite information is given.

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

• one_extractA
  3.5/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. 'Returns cleaned text blocks' hints at preprocessing but does not detail cleaning steps, error handling, or auth needs.

  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 concise sentences, front-loaded with action, then output. No wasted words.

  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 tool (1 param, no output schema), description adequately covers purpose and output. Lacks details on cleaning specifics, error handling, or limits.

  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 covers parameter with 100% coverage. Description adds value by specifying preprocessing and output type ('cleaned text blocks'), going beyond schema's 'extract information'.

  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?

  Description clearly states the verb 'fetch and preprocess' and the resource 'page content from URLs'. Differentiates from siblings: one_map, one_scrape, one_search.

  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 when-to-use or when-not-to-use guidance. Mentions downstream use but lacks context for choosing over siblings.

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

• one_scrapeA
  3.7/5.0
  Behavior4/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 notably discloses support for navigation timeout, TLS verification control, full-page screenshots, bounded pre-scrape actions, and the gating of executeJavascript. It does not mention error behavior or return structure, but these are less critical 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 concise at two sentences, front-loaded with the core purpose, and every clause adds value (outputs, timeout, TLS, screenshots, actions). There is no fluff or redundancy.

  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?

  Given the tool's complexity (7 parameters, no output schema, no annotations), the description provides a good overview of capabilities but lacks details on return value structure, error handling, or pagination/navigation behavior. It is adequate but has clear gaps, especially regarding what the returned data looks like for each format.

  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?

  Since schema description coverage is 100%, the baseline is 3. The description adds some context by mentioning 'bounded pre-scrape actions' and the executeJavascript requirement, which aligns with the actions and allowExecuteJavascript parameters. However, it does not add significant syntax or format 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.

  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 ('Scrape a single webpage') and its outputs ('markdown, HTML, links, or a screenshot'), which distinguishes it from the sibling tools by focusing on single-page scraping. It is a specific verb+resource statement, though it does not explicitly contrast with siblings like 'one_extract'.

  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 scraping a single webpage and mentions the prerequisite for executeJavascript ('only when allowExecuteJavascript is true'). However, it does not explicitly state when to choose this tool over alternatives such as one_extract, one_search, or one_map, nor does it provide exclusion criteria.

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

• one_mapA
  3.9/5.0
  Behavior3/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 does disclose the core mechanism—loading a page in the browser and extracting links from its HTML—but it omits important details such as whether the crawl is recursive, whether subdomains are included by default, or any performance/rate implications.

  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 immediately conveys the main action and mechanism. It contains no filler, repetition, or unnecessary detail.

  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?

  The description is minimal but sufficient for a simple one-page link extractor. However, with no output schema, it leaves ambiguity about return format and whether discovery is recursive or limited to the initial page, which is important for a mapping tool with four parameters.

  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 description does not need to add much parameter detail. It simply reinforces 'starting point' for the url parameter and adds no new meaning 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 states a specific action: discover URLs from a starting point by loading a page in the browser and extracting HTML links. This clearly distinguishes it from sibling tools like one_extract, one_search, and one_scrape, which focus on other tasks.

  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 gives clear context that this tool is for mapping/discovering URLs from a starting page, which implies when it should be selected. However, it does not explicitly mention alternatives or state when not to use it, so it falls 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.