Server Quality Checklist

Tool Scores

• web_crawl_get_pageB
  3.2/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. It states a read operation but does not disclose session prerequisites, error behavior, or cache persistence. No contradiction, but it leaves significant behavioral ambiguity for an agent.

  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 one concise sentence with no redundant words, and the title adds useful context. However, it is slightly under-specified, lacking parameter-level guidance that could be structured without bloat.

  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 tool is simple, but the description omits crucial context: whether a web_crawl must be active, what happens if the URL is not cached, and the exact return format. Without annotations or an output schema, the description is inadequate for safe and effective use.

  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 schema has no description for the 'url' parameter (0% coverage), and the description does not explicitly explain that the URL must refer to a previously crawled page. It offers only a vague implication via 'discovered during a web_crawl call,' which is insufficient to fully understand parameter semantics.

  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 uses the specific verb 'Fetch' and resource 'cached page content discovered during a web_crawl call,' clearly distinguishing this from siblings like web_scrape (live scraping). The title reinforces the purpose: retrieving markdown for a previously crawled page.

  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 after a web_crawl to retrieve cached content, but it does not explicitly mention when to avoid this tool or offer alternatives. The context is reasonably clear but relies on inference from the sibling tool names.

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

• web_diffB
  3.2/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 transparency burden. It discloses a key behavioral trait: it returns only a short snippet, not full content, for cost efficiency. It also implies statefulness by referencing 'the last check.' However, it does not explain what constitutes a change, how state is stored, or behaviors around forceBrowser or ignoreRobots parameters, leaving meaningful gaps.

  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, directly stating purpose, return behavior, and the cost rationale. Every clause adds value, with no redundancy or filler. It is front-loaded with the core function and efficiently communicates the essential information.

  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 tool has 4 parameters, no output schema, and no annotations. The description covers the return type (changed boolean and snippet) but omits meaningful detail about how state is tracked, what parameters like forceBrowser and ignoreRobots do, and the structure of the snippet. Given the tool's complexity, the description leaves too many operational aspects unexplained.

  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 only 25% (only 'selector' has a description). The tool description adds meaning to the selector param by referencing 'subtree,' but it provides no explanation for url, forceBrowser, or ignoreRobots. With low coverage, the description fails to compensate for the undocumented parameters, leaving their semantics unclear.

  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 function: checking whether a page or subtree has changed since the last check. It uses a specific verb ('Check') and resource ('page or subtree'), and the return type (changed=true/false) further clarifies the purpose. However, it does not explicitly differentiate itself from sibling tools like web_check or web_scrape.

  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 'so repeated monitoring stays cheap' implies this tool is intended for repeated/watchful usage, offering a mild usage guideline. It does not explicitly state when to use this tool over alternatives, nor provide exclusions or when-not-to-use scenarios. The usage context is implied rather than explicitly stated.

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

• web_crawlA
  3.5/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. It discloses the BFS algorithm, depth/page limits, return types, and the caching side effect. However, it omits important behaviors such as whether robots.txt is respected by default (relevant to ignoreRobots) and does not mention error handling or output structure.

  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-load the main action and return information without redundancy. Every phrase contributes to understanding the tool's function and its relationship to web_crawl_get_page.

  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 8 parameters, no annotations, and no output schema, the description is under-specified. It gives a high-level overview but omits key details such as the exact return format, robots.txt policy, and parameter behaviors for contentDepth and ignoreRobots, making it insufficient for reliable autonomous invocation.

  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 63%, but the description only partially compensates for undocumented parameters. It clarifies startUrl as the seed, but contentDepth and ignoreRobots are not explained anywhere, leaving the agent to guess their semantics. The description adds little meaning beyond the schema fields.

  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 identifies the tool as a BFS crawler starting from a seed URL with depth/page limits, returning titles, link structures, and excerpts. It also mentions caching full markdown for web_crawl_get_page, which distinguishes it from sibling tools like web_scrape and web_check.

  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 intended use is implied by the BFS crawl description and the caching note for web_crawl_get_page, suggesting a two-step workflow. However, it does not explicitly compare against alternatives or state when not to use this tool, so the guidance is only partial.

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

• web_scrapeA
  3.8/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 explains the output format (markdown vs. schema fields) and the smart fetch strategy ('Tries a plain HTTP fetch first and only launches a browser if the page needs JS to render'). It does not mention robots.txt enforcement or timeout behavior, but the core behavior is well disclosed.

  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 main action ('Fetch a URL and return clean content'), and every clause adds meaningful behavior. No fluff or redundancy; it is an exemplary concise description.

  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?

  For a tool with 6 parameters, no output schema, and no annotations, the description covers the essential context: primary use, output formats, and the JS-rendering fallback. It omits details like default robots.txt behavior and error handling, but it is sufficiently complete for an experienced agent to invoke the tool correctly in most scraping scenarios.

  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 67%, so the description should add some semantic value. It does clarify the 'format' parameter by saying 'markdown by default' and introduces the 'CSS-selector schema' concept. However, it does not describe 'selector', 'forceBrowser', or 'ignoreRobots', though those do have schema descriptions. Overall, it adds moderate value beyond the schema.

  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 function: 'Fetch a URL and return clean content', with a specific output mode (markdown or CSS-selector schema). It distinguishes itself from siblings by focusing on single-page scraping, but it does not explicitly name alternative tools like web_crawl_get_page, so it falls just short of 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 Guidelines3/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 (for fetching and cleaning a webpage's content), but it offers no explicit comparison to alternatives, no exclusions (e.g., when to use web_crawl instead), and no mention of prerequisites or limitations. The usage context is clear but not fully elaborated.

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

• web_session_closeA
  3.8/5.0
  Behavior3/5

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

  The description discloses that the tool deletes persisted cookies and storageState, which is a specific destructive side effect. However, it does not mention reversibility, permission requirements, or behavior when the session does not exist, leaving some gaps given the absence of annotations.

  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 verb 'Delete' and precisely states the action and target. Every word contributes.

  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?

  For a tool with one parameter and no output schema, the description covers the core functionality and the parameter. It lacks usage context and error behavior, but it is sufficient for basic selection and invocation.

  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 fully documents the sessionId parameter with a clear description, and the tool description reinforces its role by saying 'for a given sessionId.' No additional semantic value is added beyond 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 uses a specific verb ('Delete') and specifies the exact resources affected ('persisted cookies and storageState') for a given sessionId. This clearly distinguishes it from siblings like web_scrape or web_interact, which perform different actions.

  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 does not explicitly state when to use this tool versus alternatives, though the title and action imply 'when you are done with a session.' No alternatives or exclusions are mentioned.

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

• web_checkA
  3.9/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 transparency burden. It discloses the core return behavior (pass/fail and evidence snippet) and that the whole page is not returned, which is useful. But it does not mention potential side effects, network behavior, permissions, or the purpose of forceBrowser and ignoreRobots, leaving significant behavioral gaps.

  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, information-dense sentence that leads with the verb 'Verify' and includes the key differentiator (not returning the whole page, pass/fail, evidence snippet). There is no wasted text.

  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?

  With no output schema and no annotations, the description must cover usage, behavior, and parameters. It explains the output format and assertion categories, but lacks guidance on when to use over siblings, nuances of selector and boolean flags, and failure behavior. It is minimally adequate for a 6-parameter tool but not complete.

  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 only 33%, and the description partially compensates by grouping assertion types (text present/absent, element present/absent, exact text match), adding meaning to the assertion enum. However, it does not explain the selector scoping, forceBrowser, or ignoreRobots, so it only partially covers the parameter space.

  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 what the tool does: verify page properties such as text presence, element presence, and exact text match. It distinguishes itself from siblings by explicitly noting it returns just a pass/fail and an evidence snippet rather than the whole page, aligning with scraping tools in the sibling set.

  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 its use for verification checks rather than content retrieval with the phrase 'without returning the whole page.' However, it does not explicitly name alternative tools or state when not to use it, making the guidance clear but not fully explicit.

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

• web_interactA
  3.9/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. It does disclose the default return type ('text accessibility snapshot') and provides guidance on the screenshot parameter ('only when you actually need to see pixels'). However, it does not mention potential side effects, execution behavior, error handling, or session persistence, leaving some ambiguity for a tool that performs live page interactions.

  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 exactly two sentences, front-loaded with the primary purpose and method, followed by crucial output and performance guidance. Every word earns its place; 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 no output schema and 6 parameters, the description covers the core purpose and default output, but omits details on action sequence semantics, session handling, ignoreRobots, and potential failure modes. It is sufficient for basic understanding but lacks the depth needed for fully complex interaction scenarios.

  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 only 33%, so the description must compensate. It names the allowed action types (click, fill, select, press, waitFor) and explains the screenshot default, which adds useful semantics. Yet it does not describe the structure of action objects, the url parameter, ignoreRobots, or other key fields beyond what the schema already provides. The partial compensation justifies a mid-range score.

  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 verb and resource: 'Run a sequence of actions... on a live page.' It also distinguishes itself from siblings by mentioning 'reaching content behind interaction' and returning a 'text accessibility snapshot,' making it clear this tool is for interaction rather than simple scraping or crawling.

  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 for when to use the tool: 'for testing flows or reaching content behind interaction.' It implies it should be used when page interaction is required, as opposed to static scraping. However, it does not explicitly name alternatives or specify 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.