Server Quality Checklist

Tool Scores

• check_usageB
  3.2/5.0
  Behavior2/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 of behavioral disclosure. It states the tool checks usage and limits, implying a read-only operation, but doesn't specify if it requires authentication, returns real-time data, includes rate limit information, or has any side effects. This leaves gaps in understanding the tool's behavior beyond the basic purpose.

  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: 'Check your current PageBolt API usage and plan limits.' It is front-loaded with the core purpose, has zero waste, and is appropriately sized for a tool with no parameters. Every word earns its place by conveying essential information without fluff.

  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 low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does but lacks details on behavioral aspects like authentication needs or return format. Without annotations or output schema, the description should ideally provide more context on what 'check' entails, but it's adequate for a simple read operation, though with clear gaps.

  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?

  The tool has 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description doesn't need to add parameter semantics, so it appropriately avoids unnecessary details. A baseline score of 4 is applied as it efficiently handles the lack of parameters without redundancy.

  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 purpose: 'Check your current PageBolt API usage and plan limits.' It specifies the verb ('check') and resource ('PageBolt API usage and plan limits'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'list_sessions' or 'list_devices', which might also involve checking or listing resources, though those are more specific to sessions and devices rather than API usage.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as needing an active session or authentication, nor does it suggest scenarios where checking usage is appropriate (e.g., before running resource-intensive operations). With no explicit when/when-not statements or named alternatives, it leaves usage context implied at best.

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

• generate_pdfB
  3.2/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 that the PDF is saved to disk and returns a file path, which is useful. However, it doesn't address critical behaviors like error handling, performance characteristics, file system permissions needed, whether the operation is idempotent, or what happens if the URL is inaccessible.

  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 concise with two sentences that efficiently convey the core functionality and outcome. It's front-loaded with the primary purpose. However, it could be slightly more structured by separating input options from output behavior.

  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 tool with 14 parameters and no annotations or output schema, the description is minimally adequate. It covers what the tool does and the basic output (file path), but doesn't address the complexity of the many configuration options or provide guidance on their interactions. The absence of output schema means the description should ideally explain return values more thoroughly.

  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 already documents all 14 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'custom margins, headers/footers, page ranges, and scaling' - which are already covered in the schema. This meets 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 ('Generate', 'Saves', 'returns') and resources ('PDF', 'URL or HTML content', 'file path'). It distinguishes itself from sibling tools like 'take_screenshot' or 'record_video' by focusing on PDF generation from web content 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare to sibling tools, or specify scenarios where this tool is preferred over others. The agent must infer usage from the purpose alone.

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

• create_og_imageB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return type ('Returns an image') but lacks critical details: whether this is a read-only operation, if it has rate limits, what happens with invalid inputs, authentication requirements, or error behavior. For a 12-parameter generation tool, this leaves 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 perfectly concise - two sentences that directly state the tool's function and return value with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the key capabilities without unnecessary elaboration.

  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 complex 12-parameter image generation tool with no annotations and no output schema, the description is incomplete. While it states what the tool does, it lacks crucial context about the returned image format, error handling, authentication needs, and practical usage scenarios. The high parameter count and generation nature demand more comprehensive guidance than provided.

  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 already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'built-in templates or custom HTML' which aligns with the template and html parameters, but doesn't provide additional semantic context. This meets 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 specific action ('Generate') and resource ('Open Graph / social card image'), distinguishing it from siblings like generate_pdf or take_screenshot. It explicitly mentions both built-in templates and custom HTML options, providing a comprehensive purpose statement.

  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?

  The description provides no guidance on when to use this tool versus alternatives like generate_pdf or take_screenshot. It doesn't mention prerequisites (e.g., Growth plan+ for HTML), typical use cases for social cards, or when to choose templates over custom HTML. The agent receives no contextual usage instructions.

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

• take_screenshotA
  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 of behavioral disclosure. It mentions capabilities like device emulation, ad blocking, and styling, which are useful context. However, it lacks details on performance (e.g., execution time, rate limits), error handling, or side effects (e.g., whether it modifies the input). It adequately describes what the tool does but misses operational nuances.

  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 front-loaded with the core purpose and key features in a single, efficient sentence. It avoids redundancy and is appropriately sized for a complex tool. However, it could be slightly more structured by grouping related features (e.g., separating capture options from styling) for better readability.

  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 high complexity (47 parameters, nested objects) and lack of annotations or output schema, the description does a good job of summarizing capabilities. It covers input types (URL, HTML, Markdown), key features, and output format. However, it could better address behavioral aspects like performance or error cases to be fully complete for such a multifaceted 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 description coverage is 100%, so the schema already documents all 47 parameters thoroughly. The description adds minimal value by listing features like device emulation and styling, which map to some parameters, but does not provide additional syntax or format details beyond what the schema specifies. This meets 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 a specific verb ('Capture') and resource ('screenshot of a URL, HTML, or Markdown content'), distinguishing it from siblings like create_og_image (which creates images from templates) or generate_pdf (which outputs PDFs). It explicitly mentions the output format ('Returns an image'), further differentiating it.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a URL or content, or compare it to siblings like inspect_page (which might analyze rather than capture) or record_video (which captures video). Usage 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.

• run_sequenceA
  4/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 of behavioral disclosure. It reveals important behavioral traits: multi-step execution, single browser session persistence, and that 'Each output counts as 1 API request' (cost/rate limit implication). However, it doesn't disclose other critical behaviors like error handling, timeout defaults, or what happens with authentication/cookies beyond the session_id parameter.

  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 perfectly concise with two sentences that earn their place. The first sentence explains the core functionality, and the second sentence adds crucial behavioral context about API request counting. No wasted words, front-loaded with essential information.

  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 complex tool with 9 parameters, nested objects, no annotations, and no output schema, the description does reasonably well. It covers the multi-step nature, session persistence, and API cost implications. However, it doesn't explain return values or error behavior, which would be helpful given the complexity. The high schema coverage helps compensate for some 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 already documents all parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'navigate pages, interact with elements (click, fill, select), and capture multiple screenshots/PDFs' which loosely maps to the steps parameter actions, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Execute', 'Navigate', 'interact', 'capture') and resources ('multi-step browser automation sequence', 'browser session'). It distinguishes from siblings by emphasizing multi-step execution in a single session, unlike simpler tools like take_screenshot or generate_pdf.

  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 provides clear context about when to use this tool ('multi-step browser automation', 'single browser session', 'capture multiple screenshots/PDFs'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. It implies usage for complex workflows versus simpler single-step tools.

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

• record_videoA
  4.3/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 effectively describes key behaviors: 'Costs 3 API requests. Saves to disk.' It also explains practical constraints like step limits (5-15 ideal, max 50) and performance considerations (zoom adds encoding time). However, it doesn't cover error handling, timeouts, or what happens on failure.

  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 well-structured and front-loaded with the core purpose. The first sentence clearly states what the tool does, followed by key features and best practices. While slightly verbose due to the detailed best practices, every sentence adds value (e.g., cost, saving behavior, usage tips). No wasted words.

  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 high complexity (20 parameters, nested objects) and no annotations or output schema, the description does a good job of providing context. It covers the tool's purpose, key behaviors, usage guidelines, and practical constraints. However, it doesn't explain the output format details (e.g., file location behavior beyond 'Saves to disk') or error scenarios, leaving some 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 already documents all 20 parameters thoroughly. The description adds minimal parameter-specific semantics beyond the schema—it mentions 'pace parameter handles timing' and 'zoom' considerations, but most parameter details are already in the schema. 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.

  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: 'Record a professional demo video of a multi-step browser automation sequence.' It specifies the output format (MP4/WebM/GIF), key features (cursor highlighting, click effects, etc.), and distinguishes it from sibling tools like 'take_screenshot' or 'generate_pdf' by focusing on video recording of sequences.

  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?

  The description provides explicit usage guidelines: 'BEST PRACTICE: Keep videos concise (5-15 action steps). Do NOT add wait steps between every action — the pace parameter handles timing. Only use wait for page loads or narration holds. Do NOT use zoom unless the user explicitly asks for it.' It gives clear when-to-use and when-not-to-use instructions, including alternatives (using pace instead of wait steps).

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

• create_sessionA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well: discloses plan requirements (Starter+), session expiration (10 minutes inactivity, 30 minute hard cap), and that sessions keep browser pages open for reuse. It doesn't mention error conditions or performance characteristics, but covers key behavioral aspects.

  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?

  Well-structured with zero waste: first sentence states core purpose, second explains utility and connection to sibling tools, third covers expiration policy, fourth provides usage context. Every sentence earns its place.

  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 creation tool with no annotations and no output schema, the description does well: explains purpose, usage context, behavioral constraints, and connection to other tools. It doesn't describe the return value format (though mentions session_id) or error conditions, but covers most essential context.

  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 already documents all parameters. The description doesn't add any parameter-specific information beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

  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 creates a persistent browser session for reusing cookies, localStorage, and auth state across multiple screenshot or sequence calls. It specifically distinguishes from siblings like take_screenshot and run_sequence by explaining this is a prerequisite session creation tool.

  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?

  Explicitly states when to use: 'Starter+ plan required', 'useful for AI agent workflows that log in once and then take multiple screenshots of authenticated pages.' It also distinguishes from siblings by explaining the returned session_id should be passed to take_screenshot or run_sequence tools.

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

• destroy_sessionA
  4.4/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 effectively communicates that this is a destructive operation ('destroy', 'frees immediately'), explains the benefit ('free up capacity'), and clarifies timing ('before it expires'). However, it doesn't mention potential side effects or error conditions.

  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 perfectly concise with three focused sentences that each add value: first states the action, second explains immediate effect, third provides usage guidance. No wasted words, and information is front-loaded appropriately.

  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 destructive single-parameter tool with no annotations and no output schema, the description provides good context about purpose, timing, and benefits. It could be more complete by mentioning what happens if the session doesn't exist or if destruction fails, but overall it's quite helpful for the agent.

  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 already documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate but not enhanced parameter documentation.

  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 ('destroy', 'frees') and identifies the resource ('persistent browser session'). It distinguishes from siblings like 'create_session' and 'list_sessions' by focusing on termination rather than creation 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 Guidelines5/5

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

  The description explicitly states when to use this tool ('when you are done with a session to free up capacity') and provides a clear alternative scenario (letting it expire naturally). It also distinguishes from siblings by focusing on session termination rather than other session-related operations.

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

• inspect_pageA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it returns text (not images), is 'fast and cheap,' and has a cost implication ('Costs 1 API request'). However, it doesn't mention potential side effects, error conditions, or performance characteristics beyond speed.

  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 tightly focused sentences with zero waste: first states purpose and output, second provides usage context, third discloses performance/cost characteristics. Every sentence earns its place and information is front-loaded appropriately.

  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 complex tool with 31 parameters and no output schema, the description does well by explaining the core purpose, usage context, and key behavioral traits. However, without annotations or output schema, it could better address what the structured map format looks like or error scenarios given the tool's 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%, so the schema already documents all 31 parameters thoroughly. The description adds no parameter-specific information beyond implying URL/HTML input requirements. This meets the baseline expectation when schema does the heavy lifting.

  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 ('inspect a web page') and output ('structured map of all interactive elements, headings, forms, links, and images — each with a unique CSS selector'). It distinguishes this tool from siblings like run_sequence or record_video by explaining its preparatory role.

  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?

  The description explicitly states when to use this tool ('BEFORE run_sequence or record_video to discover what elements exist on the page and get reliable selectors') and provides a clear alternative use case (fast/cheap text output vs. image-based tools). This gives strong guidance on tool selection.

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

• list_sessionsA
  4.4/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 and does well by disclosing key behaviors: it lists active sessions only, returns specific data (session IDs, creation times, expiry times), and implies it's a read-only operation (no destructive hints). It could improve by mentioning rate limits or authentication needs, but it covers essential traits adequately.

  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 a concise usage guideline. Every sentence earns its place without redundancy, making it efficiently structured and appropriately sized for the tool's simplicity.

  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 low complexity (0 parameters, no output schema, no annotations), the description is nearly complete: it explains what the tool does, what it returns, and when to use it. It could slightly improve by detailing the output format more explicitly, but it's sufficient for effective use.

  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?

  The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds no parameter information, which is fine here as there are no parameters to document, and it appropriately focuses on the tool's purpose and output.

  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 ('List all active persistent browser sessions') and resource ('for your API key'), distinguishing it from siblings like 'list_devices' or 'create_session'. It provides exact scope and purpose without being vague or tautological.

  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 explicitly states when to use this tool ('Useful for checking which sessions are still alive before reusing them'), providing clear context. However, it does not specify when not to use it or name alternatives among siblings, such as 'destroy_session' for cleanup, which prevents a perfect score.

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

• list_devicesA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden. It effectively discloses that this is a read-only listing operation (implied by 'List all available'), though it doesn't mention potential limitations like rate limits, authentication requirements, or whether the list is static/dynamic. The description adds practical context about how the output is used with another 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?

  Two tightly focused sentences with zero waste. The first sentence states the purpose with helpful examples, the second provides crucial usage guidance. Every word earns its place, and the structure is front-loaded with the core functionality.

  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 parameterless read-only tool with no output schema, the description provides excellent context about what the tool does and how to use its output. It could slightly improve by mentioning the return format (e.g., array of strings) or any limitations, but given the simplicity of the tool, it's nearly complete.

  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?

  The tool has 0 parameters with 100% schema description coverage. The description appropriately doesn't waste space discussing nonexistent parameters. It instead focuses on the tool's purpose and output usage, which is the correct emphasis for a parameterless tool.

  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 verb ('List') and resource ('all available device presets for viewport emulation'), with concrete examples (iphone_14_pro, macbook_pro_14). It distinguishes from sibling tools by focusing on device preset enumeration rather than screenshot capture, PDF generation, or session management.

  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?

  The description explicitly states when to use this tool ('Use the returned device names with the viewportDevice parameter in take_screenshot'), providing a clear alternative context. It directly links to a specific sibling tool (take_screenshot) and explains the relationship between tools.

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