Server Quality Checklist

Tool Scores

• navigateC
  2.3/5.0
  Behavior1/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. 'Navigate to a URL' gives minimal information - it doesn't specify what happens after navigation (does it wait for page load?), whether it returns anything, what errors might occur, or any side effects. For a navigation tool with zero annotation coverage, this is inadequate behavioral transparency.

  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 maximally concise at just 4 words. It's front-loaded with the core action and contains zero wasted words. While it may be too brief for adequate tool understanding, it achieves perfect conciseness within its limited scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given a navigation tool with 2 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool returns, how it behaves, what the parameters mean, or how it differs from sibling tools. For a potentially complex navigation operation, this minimal description leaves critical gaps.

  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?

  With 0% schema description coverage for 2 parameters, the description provides no information about what 'url' or 'page_id' mean, their formats, or their relationship. The description mentions 'URL' which aligns with one parameter name, but doesn't explain the 'page_id' parameter at all. The description fails to compensate for the complete lack of schema documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Navigate to a URL' clearly states the action (navigate) and target (URL), providing a basic purpose. However, it's vague about scope - it doesn't specify whether this is browser navigation, application navigation, or something else. It also doesn't distinguish from siblings like 'switch_page' which might serve similar navigation functions.

  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. With siblings like 'switch_page', 'get_pages', and 'new_page' that might relate to navigation or page management, there's no indication of when 'navigate' is appropriate versus these other tools. No context about prerequisites or typical use cases is provided.

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

• clickC
  2.4/5.0
  Behavior1/5

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

  With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether clicking might trigger navigation, require element visibility, have side effects like page reloads, or handle errors. This is inadequate for a mutation tool with zero annotation coverage.

  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, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness1/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a mutation tool with no annotations, 2 parameters at 0% schema coverage, and no output schema, the description is completely inadequate. It lacks essential context like behavioral traits, parameter meanings, and usage scenarios, failing to provide enough information for effective tool invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description adds no parameter semantics beyond the schema. It mentions 'selector' but doesn't explain what a selector is, its format, or the purpose of 'page_id'. With 2 parameters and no schema descriptions, this fails to compensate for the coverage gap.

  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 'Click on an element by selector' clearly states the action (click) and target (element by selector), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'wait_for_selector' or 'get_text' which also involve selectors, missing explicit distinction.

  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 doesn't mention prerequisites (e.g., needing a page loaded), exclusions, or comparisons to sibling tools like 'type' or 'navigate', leaving the agent without context for selection.

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

• new_pageC
  2.6/5.0
  Behavior1/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new browser page' implies a write operation but provides no information about permissions needed, whether this opens a blank page or requires initialization, what happens to existing pages, or any rate limits. This is inadequate for a mutation tool with zero annotation coverage.

  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 maximally concise with a single clear sentence that states the core functionality upfront. There's no wasted verbiage or unnecessary elaboration, making it easy for an agent to parse quickly.

  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 mutation tool with no annotations, no output schema, and undocumented parameters, the description is insufficient. It doesn't explain what happens after creation, what the 'page_id' parameter means, how this interacts with sibling tools, or any behavioral constraints. The agent would have significant gaps in understanding how to use this tool effectively.

  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?

  With 0% schema description coverage for the single required parameter 'page_id', the description provides no information about what this parameter represents, its format, or its purpose. 'Create a new browser page' doesn't mention parameters at all, leaving the agent with no semantic understanding beyond the bare schema structure.

  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 'Create a new browser page' clearly states the action (create) and resource (browser page), making the purpose immediately understandable. However, it doesn't distinguish this tool from its siblings like 'get_pages' or 'navigate', which would require more specific differentiation to earn a perfect score.

  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. With siblings like 'get_pages' (listing existing pages), 'navigate' (loading URLs), and 'switch_page' (changing active pages), there's no indication of when creating a new page is appropriate versus using existing ones or what prerequisites might be needed.

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

• get_page_contentC
  2.8/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 full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires a page to be fully loaded, if it works with dynamic content, what happens with authentication-protected pages, or potential rate limits. The description mentions 'current page' but doesn't clarify if this refers to the active browser tab or requires explicit navigation first.

  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 at just 6 words, front-loading the core functionality without any wasted words. Every word contributes directly to understanding what the tool does. The structure is optimal for a simple tool description, though this conciseness comes at the cost of missing important contextual 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?

  Given the complexity of browser automation tools, no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what format the HTML content returns in, whether it includes external resources, how it handles JavaScript-rendered content, or error conditions. For a tool that interacts with browser pages, this leaves too many operational questions unanswered.

  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?

  With 0% schema description coverage and one parameter ('page_id'), the description provides no information about what this parameter means, what format it expects, or whether it's required. The description mentions 'current page' which might imply no parameter is needed, but the schema shows a 'page_id' property. This creates ambiguity about whether the tool works on the current page or requires explicit page identification.

  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 action ('Get') and resource ('current page HTML content'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_text' (which likely extracts text) and 'take_screenshot' (which captures visual content) by specifying HTML content retrieval. However, it doesn't explicitly mention that it fetches from a browser context, which could be inferred from sibling tools but isn't stated directly.

  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 specify if this should be used instead of 'get_text' for raw HTML, whether it requires a page to be loaded first, or if it works with any page state. With multiple sibling tools for page interaction, this lack of comparative context leaves the agent guessing about appropriate usage scenarios.

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

• get_textC
  2.8/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. It states 'Get text content' but doesn't disclose behavioral traits such as what happens if the element isn't found, if it requires a loaded page, or the format of returned text. This leaves significant gaps for a tool with parameters.

  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 wasted words, making it highly concise and front-loaded. It efficiently states the core function without unnecessary elaboration.

  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 no annotations, 0% schema coverage, no output schema, and 2 parameters, the description is incomplete. It doesn't explain return values, error handling, or parameter usage, making it inadequate for effective tool invocation in this context.

  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 0%, so the schema only provides types without meanings. The description doesn't add any semantic information about parameters like 'selector' or 'page_id', such as what they represent or how to use them, failing to compensate for the low coverage.

  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 action ('Get') and resource ('text content from an element'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_page_content' or 'get_pages', which also retrieve content, so it's not fully specific to sibling context.

  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 'get_page_content' or 'get_pages', nor does it mention prerequisites such as needing a page to be loaded. It's a basic statement without context for selection.

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

• switch_pageC
  2.8/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 full burden. It states the action ('Switch to') but doesn't disclose behavioral traits like whether this changes focus in a browser context, if it requires an open page, what happens on failure, or side effects. This is inadequate for a mutation tool with zero annotation coverage.

  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, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's apparent simplicity, earning full marks for conciseness.

  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 tool likely performs a mutation (switching pages), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on behavior, parameters, and context needed for an agent to use it correctly, especially among siblings like 'navigate' or 'get_pages'.

  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 0%, so the description must compensate. It doesn't explain the 'page_id' parameter at all—no mention of what it represents, how to obtain it, or format. The description adds no meaning beyond the bare schema, failing to address the coverage gap.

  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 verb ('Switch to') and resource ('a different browser page'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'navigate' (which might change URL) or 'get_pages' (which lists pages), so it's not fully specific to sibling context.

  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 (e.g., needing an existing page), exclusions (e.g., not for creating pages), or compare to siblings like 'new_page' (for creating) or 'navigate' (for URL changes).

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

• take_screenshotC
  2.8/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. While 'take a screenshot' implies a read operation that captures visual state, it doesn't specify whether this requires page visibility, what format the screenshot returns (image data, file path, etc.), whether it waits for page load, or any performance/rate limit considerations. The description adds minimal behavioral context beyond the basic action.

  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 at just 6 words, front-loading the core functionality with zero wasted words. Every word earns its place by communicating the essential action and target without unnecessary elaboration.

  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 2 undocumented parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (image format, location, etc.), how parameters affect the screenshot (full page vs. element), or any behavioral constraints. The minimal description leaves too many unknowns for effective tool selection and 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?

  The input schema has 2 parameters (page_id, selector) with 0% description coverage, meaning neither parameter is documented in the schema. The description provides no information about these parameters - it doesn't explain what page_id refers to, what selector is used for, or whether parameters are optional/required. The description fails to compensate for the schema's lack of documentation.

  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 action ('take a screenshot') and the target ('current page'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like capturing specific elements versus full pages, which would require sibling tool analysis for full differentiation.

  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 'get_page_content' or 'get_text' for content extraction, or when screenshots are preferable to other capture methods. There's no mention of prerequisites, timing considerations, or comparison with sibling tools.

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

• typeC
  2.8/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 but only states the basic action without behavioral details. It doesn't disclose potential side effects (e.g., triggering events), error conditions (e.g., if selector fails), or performance aspects (e.g., timing), leaving significant gaps for a mutation 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 a single, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

  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 3-parameter mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, parameters, error handling, and expected outcomes, leaving too many gaps for effective agent use despite the concise structure.

  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 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'selector', 'text', or 'page_id' mean, their formats, or how they interact, failing to provide meaningful semantics beyond the bare 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 action ('type text') and target ('into an input element'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'click' or 'get_text' that might also interact with input elements, preventing a perfect score.

  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 offers no guidance on when to use this tool versus alternatives like 'click' for button interactions or 'get_text' for reading input values. It lacks context about prerequisites (e.g., needing a page loaded) or exclusions, leaving usage unclear.

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

• wait_for_selectorC
  2.8/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 waiting for visibility but lacks details on what happens on timeout (e.g., error or return), whether it polls continuously, or if it requires specific page states. This is a significant gap for a tool with potential side effects.

  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 wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.

  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 complexity of a waiting tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return values, or interaction with sibling tools, leaving critical gaps for an AI agent.

  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 0%, so the description must compensate for undocumented parameters. It only implies the 'selector' parameter but doesn't explain 'page_id' (e.g., which page to wait on) or 'timeout' (e.g., default value or units), failing to add meaningful context 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 purpose with a specific verb ('wait for') and resource ('element'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_text' or 'click', which might also involve element visibility, so it misses the highest score.

  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. For example, it doesn't specify if this should be used before interacting with elements (e.g., before 'click' or 'type') or as a standalone check, leaving usage context unclear.

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

• get_pagesB
  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 full burden. It states the action ('List all available browser pages') but doesn't disclose behavioral traits like whether this returns live page objects, requires browser focus, has rate limits, or what format the list uses (e.g., titles, URLs, IDs). This leaves the agent with incomplete operational context.

  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, efficient sentence ('List all available browser pages') that is front-loaded and wastes no words. Every part of the sentence contributes directly to understanding the tool's function.

  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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on return values (since no output schema) and behavioral context, making it minimally viable but not fully informative.

  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 schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate here. A baseline of 4 is given as it meets expectations for a parameterless tool.

  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 'List all available browser pages' clearly states the verb ('List') and resource ('browser pages'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_page_content' or 'switch_page' that also interact with pages, so it doesn't reach the highest score.

  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. With siblings like 'get_page_content' (for content extraction) and 'switch_page' (for navigation), the agent must infer usage context without explicit direction, which is a significant gap.

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