Server Quality Checklist

Tool Scores

• download_mediaA
  3.8/5.0
  Behavior3/5

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

  Discloses that browser cookies handle authentication automatically, a key behavioral trait. But with no annotations, fails to address potential side effects like file overwriting, disk space usage, or error handling. Moderate added context over minimal structured fields.

  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?

  Three concise sentences with no redundancy. Front-loaded with verb 'Downloads'. Each sentence adds value: purpose, usage context, authentication advantage.

  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 simple two-parameter tool with no output schema, description covers main purpose and usage context. Missing information on return value (e.g., saved file paths) and potential limitations (browser state dependency). Adequate but not exhaustive.

  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 baseline is 3. Description adds no additional meaning about URL format or output_dir behavior beyond schema descriptions. Merely reinforces surrounding 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?

  Description clearly states it downloads files from URLs using saved browser sessions. It specifies resource (files) and mechanism (browser sessions). Mentions relationship to auth_fetch, distinguishing from sibling fetch tool. However, lacks explicit differentiation from general download tools or caveats.

  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?

  Explicitly recommends use for downloading files from auth_fetch results. Highlights automatic authentication as key advantage. No explicit 'when not to use' or alternative tools, but sibling context provides implicit distinction.

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

• close_browserA
  4.1/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. It explicitly discloses a key behavioral trait: login sessions are saved and reused. This goes beyond the simple action by explaining the persistent effect. However, it does not mention other potential behaviors like confirmation dialogs or error states.

  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. The first sentence front-loads the core action, and the second adds a valuable behavioral detail. Every word earns its place.

  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?

  Given the tool's simplicity (no parameters, no output schema) and the richness of the description (clear action plus saved sessions), the description is fully complete for an AI agent to understand what the tool does and its side effect.

  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?

  There are no parameters (0), and schema coverage is trivially 100%. The description correctly implies that no input is needed. For zero-parameter tools, the baseline is 4, and the description meets that by not adding unnecessary 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?

  The description clearly states the action ('Closes the browser window') and specifies the resource (browser window). It is a specific verb+resource pair that leaves no ambiguity, and it naturally distinguishes from sibling tools which deal with fetching, downloading, or listing.

  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. It does not mention prerequisites (e.g., a browser must be open) or when not to use it (e.g., when you want to discard sessions). The description is purely declarative without usage context.

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

• list_pagesA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the behavior: listing open tabs with URLs and titles. It does not mention edge cases (e.g., no open tabs), but for a simple read operation, this is adequate.

  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, clear sentence with no unnecessary words. It is front-loaded and efficient.

  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?

  Given the tool has no parameters, no output schema, and is a simple list operation, the description is complete. It explains the tool's purpose and output adequately.

  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?

  There are no parameters, and schema coverage is 100% (trivially). According to the rubric, no parameters set a baseline of 4. The description does not need to add parameter 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?

  The description clearly states 'Lists all open tabs in the browser with their URLs and titles,' providing a specific verb and resource. The sibling tools (auth_fetch, close_browser, download_media) have distinct purposes, so no confusion.

  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 or when not to use this tool, nor does it mention alternatives. However, the sibling tools are sufficiently different that usage context is implied.

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

• auth_fetchA
  4.5/5.0
  Behavior5/5

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

  No annotations provided, so the description carries full burden. It explains the tool opens a browser window, requires user interaction (login, click capture), returns cleaned HTML with noise stripped and media preserved, and directs to download_media for image/file downloads. All behavioral traits are disclosed.

  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 paragraph but covers all key points without redundancy. Each sentence contributes meaning. Could be slightly more structured but remains efficient.

  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 complexity of an auth-fetching tool, the description explains the user interaction flow, output format (cleaned HTML), and references a sibling tool (download_media). No output schema exists, but description provides enough for agent to understand usage.

  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%. Description adds context for 'url' (the URL to fetch) and 'wait_for' (optional CSS selector for SPAs). This adds value beyond schema definitions.

  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 fetches web page content using a real browser and returns cleaned HTML. It distinguishes from siblings by specifying it is for pages requiring login or returning empty HTML, and lists examples like Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page.

  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?

  Explicitly states 'MUST be used instead of Fetch/web_fetch when the page requires login or returns empty/minimal HTML' and 'Do NOT suggest copy-paste or PDF export — use this tool first.' It outlines a workflow but does not explicitly exclude use cases for simple public pages where a simpler tool suffices.

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