Server Quality Checklist

Tool Scores

• take_screencastA
  3.9/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true and destructiveHint=false, indicating safe operation. The description adds valuable behavioral context beyond annotations: adaptive frame rates (100ms, 200ms, 500ms intervals), output formats (PNG as individual frames, WebP as animated with 4-second pause), and format-specific details. It does not contradict annotations, as 'capture' aligns with read-only 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 appropriately sized and front-loaded, starting with the core purpose. It efficiently covers key behavioral traits in two sentences without redundancy. However, it could be slightly more structured by separating format details into distinct points for clarity.

  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 (9 parameters, no output schema) and rich annotations, the description is mostly complete. It explains adaptive frame rates and format behaviors, which are critical for usage. However, it does not cover all contextual aspects like error handling or performance implications, leaving minor gaps.

  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%, so the schema fully documents all 9 parameters. The description adds minimal parameter semantics, mentioning PNG and WebP formats and adaptive frame rates, which relate to 'format' and 'duration' parameters but do not provide significant additional meaning beyond the schema. Baseline 3 is appropriate given high schema coverage.

  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 purpose: 'Capture a series of screenshots of a web page over time, producing a screencast.' It specifies the verb ('capture'), resource ('web page'), and output ('screencast'), distinguishing it from sibling tools like 'take_screenshot' (single screenshot) and 'capture_console' (different resource).

  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 through details like adaptive frame rates and format options, suggesting when to use it for time-based captures. However, it lacks explicit guidance on when to choose this tool over alternatives like 'take_screenshot' or 'capture_console', and does not mention prerequisites or exclusions.

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

• capture_consoleA
  4/5.0
  Behavior4/5

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

  Annotations already indicate read-only, non-destructive, and open-world traits, but the description adds valuable behavioral context: it specifies that the tool captures console messages over a duration, returns all messages during that time, and includes defaults (e.g., 4 seconds). This enhances understanding beyond annotations without contradiction.

  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 front-loaded with the core purpose in the first sentence, followed by key parameters and return behavior in a second sentence. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.

  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 moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It covers purpose, key parameters, and output behavior, though it lacks details on error handling or specific use cases. With no output schema, it adequately explains returns, but could be slightly enhanced for full completeness.

  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?

  With 100% schema description coverage, the schema fully documents all parameters. The description adds minimal semantics by mentioning the URL, optional JS command, and duration with default, but does not provide additional meaning beyond what the schema already covers, such as explaining the waitUntil parameter or JS command usage.

  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 specific action ('capture console output'), target resource ('from a web page'), and distinguishes from siblings by focusing on console messages rather than visual captures like take_screencast or take_screenshot. It uses precise language that defines the tool's unique function.

  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 capturing console output from web pages but does not explicitly state when to use this tool versus alternatives like take_screencast or take_screenshot. It provides some context with parameters but lacks explicit guidance on scenarios or exclusions, leaving usage somewhat inferred.

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

• take_screenshotA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations by specifying tiling behavior (1072x1072 chunks), optimization for CLI tools, and the purpose of verifying web page updates, though it doesn't cover rate limits 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?

  The description is front-loaded with the core purpose, followed by usage guidelines and technical details, all in three concise sentences with zero wasted words, making it easy to scan and understand quickly.

  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 moderate complexity, rich annotations, and full schema coverage, the description is mostly complete. It lacks details on output format (e.g., base64 vs. file paths) since there's no output schema, but otherwise covers purpose, usage, and key behaviors adequately.

  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%, so the schema fully documents all 6 parameters. The description adds minimal parameter semantics by mentioning tiling and optimization, but doesn't provide additional details beyond what the schema already covers, meeting the baseline for high schema coverage.

  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 purpose with specific verbs ('capture', 'tiles') and resources ('web pages'), distinguishing it from sibling tools like capture_console and take_screencast by focusing on static screenshot functionality rather than console logs or video recordings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool ('after performing updates to web pages to ensure your changes are displayed correctly') and provides context about its optimization for CLI coding tools, giving clear guidance without mentioning alternatives directly but implying its niche use case.

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