Server Quality Checklist

Tool Scores

• browser_clickC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the action ('click') but doesn't describe what happens after clicking (e.g., page navigation, event triggers, error handling). It mentions using a 'ref from snapshot' but doesn't explain how snapshots relate or if this requires prior browser_snapshot calls. For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core action ('Click an element on the page') and specifies methods. Every word earns its place with no redundancy or fluff, making it highly concise and well-structured for quick understanding.

  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 browser interaction tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error cases, dependencies on other tools (e.g., browser_snapshot), or what the tool returns. For a mutation tool in a browser context, more detail is needed to ensure safe and correct usage.

  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 50% (2 of 4 parameters have descriptions: ref and selector). The description adds value by explaining the purpose of ref ('from snapshot') and selector ('CSS selector'), which clarifies beyond the schema's basic descriptions. However, it doesn't cover button or doubleClick parameters, leaving half the parameters without semantic context in either schema or description, resulting in a baseline score.

  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 ('click') and target ('element on the page'), specifying two methods ('ref from snapshot' or 'CSS selector'). It distinguishes from siblings like browser_hover (hovering) and browser_press_key (keyboard input), though not explicitly. However, it doesn't fully differentiate from browser_click_text (which may be for text-specific clicking), leaving some ambiguity.

  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 when to choose ref vs. selector, or when to use browser_click_text instead. The description implies usage for clicking elements but offers no context on prerequisites, such as needing a browser session or snapshot, or exclusions for non-interactive elements.

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

• browser_consoleC
  2.9/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 states the tool reads messages but doesn't describe what happens if no messages exist, whether it returns historical or real-time data, or any limitations (e.g., rate, format). The mention of 'clear' in the schema hints at side effects, but the description doesn't address this.

  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 no wasted words. It front-loads the core purpose ('Read console messages') and specifies details ('log, warn, error') concisely.

  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 and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., message list format, timestamps), behavioral aspects like side effects from 'clear', or integration with browser state. For a tool with potential side effects and undefined output, this is inadequate.

  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 the single parameter 'clear'. The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high 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 verb ('Read') and resource ('console messages') with specific types mentioned ('log, warn, error'). It distinguishes from siblings like browser_click or browser_navigate by focusing on console output, though it doesn't explicitly differentiate from all browser tools.

  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 active browser session), exclusions, or related tools like browser_evaluate for executing code that might produce console output.

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

• browser_hoverC
  2.9/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 describes the hover action and its effects (triggering UI states), but lacks critical behavioral details such as whether this requires the element to be visible, if it waits for hover effects to complete, error handling, or performance implications. This is a significant gap for a browser interaction 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 that front-loads the core action ('hover over an element') and immediately explains the purpose ('to trigger tooltips, dropdown menus, or hover states'). There is no wasted verbiage, and every word contributes to understanding the tool's function.

  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 interactions and lack of annotations or output schema, the description is incomplete. It fails to address key contextual aspects like what happens after hovering (e.g., does it return success/failure, wait for effects), error cases (e.g., if element not found), or integration with sibling tools. This leaves gaps for effective agent use.

  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%, with both parameters ('ref' and 'selector') clearly documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as usage examples or constraints. Baseline 3 is appropriate as the schema handles the heavy lifting.

  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 'hover over' and the resource 'an element', specifying the action and target. It distinguishes from siblings like 'browser_click' by focusing on hover interactions rather than clicks, though it doesn't explicitly name alternatives. The purpose is specific but could be more differentiated.

  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 mentions triggering tooltips, dropdown menus, or hover states, which implies usage for UI interactions, but provides no explicit guidance on when to use this tool versus alternatives like 'browser_click' or 'browser_press_key'. There are no exclusions or prerequisites stated, leaving the agent to infer context.

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

• browser_screenshotC
  2.9/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 capturing the 'visible page area' which adds some context about scope, but fails to address critical aspects like whether this requires specific permissions, if it's a blocking operation, what happens on failure, or what the output format is (e.g., base64 string, file path).

  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 that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  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 screenshot tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It lacks information about return values, error conditions, dependencies (e.g., requires an open browser page), and behavioral details. The description alone doesn't provide enough context for reliable use.

  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 50% (only 'quality' has a description), and the description adds no parameter information beyond what's in the schema. It doesn't explain what 'format' controls or provide context for 'quality' values. Since schema coverage is moderate, the baseline is 3, but the description doesn't compensate for the gaps.

  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 ('capture') and resource ('screenshot of the visible page area'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'browser_snapshot' which might have overlapping functionality, 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?

  No guidance is provided on when to use this tool versus alternatives like 'browser_snapshot' or other browser tools. The description only states what it does, not when it's appropriate or what prerequisites might be needed (e.g., requiring an active browser page).

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

• browser_selectC
  2.9/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 mentions the action ('Select') but lacks details on prerequisites (e.g., requires a loaded page), side effects (e.g., might trigger page changes), error handling, or response format. This is inadequate for a tool with potential UI interactions.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

  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 (with no annotations and no output schema), the description is insufficient. It doesn't cover behavioral aspects like error cases, dependencies on other tools (e.g., browser_snapshot for 'ref'), or what happens after selection. This leaves significant gaps for an AI agent to use it correctly.

  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 5 parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how parameters like 'ref' or 'selector' interact, or which parameter takes precedence). Baseline 3 is appropriate as the schema handles parameter 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 verb ('Select') and resource ('an option from a dropdown/select element'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_click_text, which might also interact with UI elements, though the specific focus on dropdowns/selects is implied.

  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. For example, it doesn't clarify if this should be used instead of browser_click for dropdowns, or how it relates to browser_type for text input. The description only states what it does, not when it's appropriate.

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

• browser_tabsC
  2.9/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 mentions actions but lacks behavioral details: it doesn't specify permissions needed, side effects (e.g., closing tabs is destructive), rate limits, or what 'focus' entails (e.g., brings tab to foreground). For a multi-action tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

  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 and front-loaded, stating the core purpose in a single, efficient sentence. Every word earns its place, with no redundant or vague phrasing. It effectively communicates the tool's scope 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 tool's complexity (multiple actions with different behaviors) and lack of annotations or output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances (e.g., what 'list' returns, how 'focus' works). For a tool with no structured support, more context is needed to guide effective use.

  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 (action, tabId, url) with descriptions and enum values. The description adds no additional parameter semantics beyond implying that actions map to parameters (e.g., 'create' uses url, 'close/focus' use tabId). This meets the baseline of 3 when schema does the heavy lifting.

  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 specific verbs (list, create, close, focus) and resource (browser tabs), making it immediately understandable. It distinguishes from siblings by focusing on tab management rather than navigation, interaction, or content extraction. However, it doesn't explicitly differentiate from all siblings (e.g., browser_navigate also deals with tabs).

  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, appropriate contexts, or comparisons with sibling tools like browser_navigate (which might handle tab navigation differently). The agent must infer usage solely from the action list without explicit direction.

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

• browser_textC
  2.9/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. It mentions extraction but lacks details on permissions needed, rate limits, error handling (e.g., if selector fails), or output format (e.g., plain text vs. structured). For a tool interacting with a browser, this leaves critical gaps in understanding its operation.

  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 that front-loads the core action ('extract raw text content') and includes optional scoping. There's no wasted verbiage, 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?

  Given the complexity of browser interactions and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like error conditions, performance implications, or return values, which are crucial for an agent to use this tool effectively in a dynamic environment.

  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%, with clear parameter descriptions in the schema (e.g., 'CSS selector to scope text extraction'). The description adds minimal value beyond this, as it only implies the 'selector' parameter without explaining syntax or use cases. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 ('extract') and resource ('raw text content') with optional scoping ('from the page or a specific element'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like browser_snapshot (which might capture visual content) or browser_evaluate (which might execute scripts), leaving room for ambiguity in a crowded toolset.

  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 many sibling tools (e.g., browser_snapshot for screenshots, browser_evaluate for script execution), there's no indication of scenarios where text extraction is preferred or excluded, such as for accessibility vs. visual rendering tasks.

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

• browser_typeC
  2.9/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 mentions the core action but lacks behavioral details: it doesn't specify whether typing simulates human-like keystrokes or instant insertion, whether it waits for the element to be interactable, what happens if the element isn't an input, error conditions, or performance implications. For a mutation tool with zero annotation coverage, this is inadequate.

  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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral traits (e.g., interaction timing, error handling), usage context relative to siblings, or return values. Given the complexity of browser automation and rich sibling set, more guidance is needed for effective agent use.

  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 4 parameters (ref, selector, text, clear). The description adds no parameter-specific information beyond implying 'text' is typed into an 'input element', which is already clear from 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.

  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 browser_press_key (which might simulate keyboard input) or browser_select (which might handle dropdowns), leaving some ambiguity about when this specific text-typing tool is preferred.

  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 multiple browser interaction siblings (e.g., browser_press_key for keyboard events, browser_click for clicking, browser_select for dropdowns), there's no indication of when text typing is appropriate versus other input methods or what prerequisites exist (e.g., needing a focused input element).

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

• browser_scrollB
  3.1/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 mentions 'works with virtual scroll containers used by social media sites', adding some behavioral context about compatibility. However, it lacks details on permissions needed, error handling, rate limits, or what happens if parameters conflict (e.g., using 'toElement' with 'position'). For a tool with 5 parameters and no annotations, this is insufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and efficiently lists key features without redundancy. Every sentence adds value: the first covers the main action and parameter types, the second adds compatibility context.

  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 5 parameters, 80% schema coverage, no annotations, and no output schema, the description is moderately complete. It covers the tool's purpose and some behavioral context but lacks details on return values, error cases, or parameter interdependencies, which are important for a scrolling tool with multiple options.

  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 80%, providing a baseline of 3. The description adds minimal value beyond the schema: it mentions 'pixel offsets' (implied by 'amount'), 'scrolling to elements' (implied by 'toElement'), and 'named positions' (implied by 'position'), but doesn't clarify interactions between parameters or provide additional syntax details.

  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 ('scroll') and target ('the page or an element'), distinguishing it from non-scrolling siblings like browser_click or browser_type. However, it doesn't explicitly differentiate from other scrolling-related tools (none exist in the sibling list), so it's not a perfect 5.

  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 mentions 'supports pixel offsets, scrolling to elements, and named positions' and 'works with virtual scroll containers', which implies usage contexts but doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., browser_navigate for page changes) or when not to use it. No sibling-specific comparisons are made.

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

• browser_navigateB
  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 action but doesn't cover critical aspects like whether navigation blocks until completion, error handling for invalid URLs, side effects on page state, or performance implications. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 wasted words. It's front-loaded with the core action and context, making it easy to parse quickly. Every word earns its place without being overly verbose or under-specified.

  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's complexity (navigation is a mutation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or behavioral constraints like rate limits or permissions. For a browser interaction tool, this leaves critical 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 both parameters (url and waitUntil) thoroughly. The description doesn't add any parameter-specific details beyond what the schema provides, such as URL format examples or waitUntil behavior nuances. 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 specific action ('Navigate to a URL') and resource ('in the active browser tab'), distinguishing it from sibling tools like browser_click or browser_type which perform different browser interactions. It precisely communicates what the tool does 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 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 active browser tab), exclusions, or compare it to sibling tools like browser_tabs for tab management. 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.

• browser_networkB
  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. It mentions reading and filtering network requests, but fails to disclose key behavioral traits: whether this requires specific permissions, how requests are stored/retrieved, potential rate limits, or what 'clear requests after reading' entails (e.g., if it affects other tools). The description is minimal and lacks 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 extremely concise and front-loaded: two short sentences that directly state the purpose and key functionality. Every word earns its place with no redundancy or fluff, 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?

  Given no annotations and no output schema, the description is incomplete for a tool with potential complexity. It doesn't explain what 'network requests' includes (e.g., types, timing), how results are returned, or error conditions. For a tool that might involve monitoring dynamic page behavior, this leaves significant gaps for an agent to operate effectively.

  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 both parameters (filter as URL regex pattern, clear as boolean to clear after reading). The description adds marginal value by mentioning filtering, but doesn't provide additional semantics beyond what's in the schema (e.g., regex examples or implications of clearing). Baseline 3 is appropriate as the schema does the heavy lifting.

  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: 'Read network requests made by the page' specifies the verb (read) and resource (network requests). It distinguishes from siblings like browser_navigate or browser_click by focusing on network monitoring rather than page interaction. However, it doesn't explicitly differentiate from all siblings (e.g., browser_console might also involve network aspects).

  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 provides some implied usage context with 'Filter by URL pattern,' suggesting it's for analyzing network traffic. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., browser_console for logs or browser_snapshot for page state). No when-not-to-use scenarios or prerequisites are mentioned, leaving gaps for an agent to infer.

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

• browser_press_keyB
  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 support for key combinations and modifiers, but fails to describe critical behaviors such as whether this action triggers page navigation, form submissions, or other side effects; whether it requires a focused element; or what happens on error. For a browser interaction tool with zero annotation coverage, this leaves significant gaps in understanding its operational impact.

  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—two sentences that directly state the tool's function and its key features (supported keys and modifiers). Every word earns its place with no redundancy or fluff, making it easy to parse and understand 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?

  Given the complexity of a browser interaction tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on behavioral outcomes (e.g., what the tool returns, error conditions), prerequisites (e.g., needing an active browser session), and how it integrates with sibling tools. For a tool that could have significant side effects, this leaves too much unspecified.

  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 fully documents all four parameters (key, modifiers, ref, selector). The description adds minimal value beyond the schema by listing example keys (e.g., 'Enter', 'Escape') and mentioning modifiers like 'Ctrl+A', but doesn't provide additional syntax, format details, or usage context for the parameters. This meets the baseline of 3 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.

  Purpose4/5

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

  The description clearly states the action ('Press a keyboard key or combination') and the resource (keyboard input in a browser context), making the purpose immediately understandable. It distinguishes itself from siblings like browser_click or browser_type by focusing specifically on key presses rather than mouse clicks or text typing, though it doesn't explicitly name these alternatives.

  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 keyboard interactions in a browser, but provides no explicit guidance on when to use this tool versus alternatives like browser_type (for text input) or browser_click (for mouse actions). It mentions supported keys and modifiers, which gives some contextual hint, but lacks clear when/when-not directives or named alternatives.

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

• browser_waitB
  3.4/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. While it mentions the tool is 'useful for SPAs and dynamic content,' it doesn't describe important behavioral aspects like what happens when the timeout is reached (does it fail? return null?), whether it blocks execution, or potential side effects. The description is insufficient for a mutation/interaction tool in a browser 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 perfectly concise with two sentences. The first sentence clearly states the purpose, and the second provides useful context. Every word earns its place with zero waste or redundancy.

  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 that this is a browser interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (success/failure indicator? element handle?), error conditions, or important behavioral constraints. For a tool that interacts with dynamic web content, more context about outcomes and failure modes is needed.

  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 fully documents all 4 parameters. The description mentions 'element to appear, element to disappear, or a fixed delay' which loosely maps to the 'state' and 'delay' parameters, but adds no additional semantic meaning beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.

  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: 'Wait for a condition: element to appear, element to disappear, or a fixed delay.' It specifies the verb ('wait') and the resources/conditions (element states, delay), but doesn't explicitly differentiate it from sibling tools like browser_find or browser_text that might also involve waiting or element detection.

  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 for when to use this tool: 'Useful for SPAs and dynamic content.' This gives practical guidance about scenarios where waiting is necessary. However, it doesn't specify when NOT to use it or mention alternatives among the sibling tools (e.g., when browser_find might be more appropriate).

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

• browser_evaluateA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core behavior (executing JavaScript and returning results) and hints at use cases, but lacks details on permissions, error handling, execution context (e.g., sandboxing), or side effects like potential page modifications.

  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 usage guidance, with no wasted words. Both sentences earn their place by clarifying intent and application.

  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 complexity (executing arbitrary JavaScript in a browser context) and lack of annotations or output schema, the description is adequate but incomplete. It covers purpose and usage but omits critical behavioral details like safety, return formats, or error conditions, which are essential for such a powerful 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 the 'expression' parameter fully. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in the baseline score.

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

  Purpose5/5

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

  The description clearly states the specific action ('Execute JavaScript in the page') and the resource ('page'), distinguishing it from siblings like browser_click or browser_navigate by focusing on code evaluation rather than UI interaction or navigation.

  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?

  It provides clear context for when to use this tool ('for DOM queries, reading page state, or any operation not covered by other tools'), which helps differentiate it from alternatives. However, it does not explicitly state when not to use it or name specific sibling tools as alternatives.

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

• browser_handle_dialogA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses that dialogs block page interaction, which is a key behavioral trait. However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation tool (handling dialogs implies interaction).

  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 appropriately sized with two concise sentences that are front-loaded: the first states the purpose, and the second adds critical behavioral context. Every sentence earns its place without waste.

  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 complexity (handling interactive dialogs), no annotations, and no output schema, the description is somewhat complete but lacks details on return values, error cases, or prerequisites. It covers the blocking behavior but misses other contextual aspects needed for full understanding.

  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 both parameters (action and promptText) with descriptions and enum values. The description does not add meaning beyond what the schema provides, such as explaining when promptText is required or how actions map to dialog types.

  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 ('Handle JavaScript dialogs') and the resources involved ('alert, confirm, prompt'), distinguishing it from sibling tools like browser_click or browser_type. It explicitly mentions the types of dialogs handled, which is more specific than just the tool name.

  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 for when to use this tool ('Dialogs block page interaction until handled'), indicating it's necessary when a dialog appears. However, it does not explicitly state when not to use it or name alternatives among sibling tools, such as for non-dialog interactions.

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

• browser_snapshotA
  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. It discloses that the tool returns 'element refs you can use with click, type, and other tools,' which is useful behavioral context. However, it lacks details on potential side effects (e.g., if it modifies the page), performance implications, or error handling, leaving gaps for a mutation-sensitive operation.

  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 usage guidance in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.

  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 (2 parameters, no output schema, no annotations), the description is mostly complete. It explains what the tool does, how to use the output, and a key parameter behavior. However, it could benefit from mentioning return format details or error cases, slightly reducing 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?

  Schema description coverage is 100%, so the schema fully documents both parameters (selector and compact). The description adds minimal value beyond the schema by mentioning 'compact mode (default) for smaller output - only interactive elements,' which slightly elaborates on the compact parameter's effect. 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 ('Get an accessibility tree snapshot of the page') and resource ('page'), distinguishing it from siblings like browser_screenshot (visual) or browser_text (text extraction). It explicitly mentions the output format ('element refs') and their purpose ('use with click, type, and other tools'), making the tool's function unambiguous.

  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 for when to use this tool ('to get an accessibility tree snapshot') and mentions 'compact mode (default) for smaller output - only interactive elements,' which guides usage. However, it does not explicitly state when not to use it or name alternatives (e.g., browser_screenshot for visual snapshots), keeping it from a perfect score.

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

• browser_click_textA
  4.2/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 behavioral traits: it's CSP-safe (security aspect), prefers deepest matching element (interaction logic), and works on dynamic content. It doesn't cover error handling, performance, or visual feedback, but provides substantial 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 extremely efficient—three sentences that each add distinct value: core functionality, technical context (React/CSP), and behavioral nuance (deepest element). No wasted words, and the most critical information is front-loaded.

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

  Completeness4/5

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

  For a tool with 3 parameters, 100% schema coverage, and no output schema, the description provides excellent context about when and how it works, especially for dynamic content. It doesn't explain return values or error cases, but given the schema completeness and clear behavioral disclosure, it's nearly complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema, but doesn't need to since the schema is comprehensive. 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 ('Click an element') and target ('by its visible text content'), distinguishing it from siblings like browser_click (which likely uses selectors) and browser_find (which finds but doesn't click). It explicitly mentions working on React components and portals, which adds specificity.

  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 for when to use this tool ('Works on React dropdowns, portals, and overlays that may not appear in snapshots'), implying it's better for dynamic content than snapshot-based alternatives. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.

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

• browser_findA
  4.2/5.0
  Behavior3/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 discloses that it returns 'refs' for use with other tools, which is useful behavioral context. However, it doesn't mention potential limitations like what happens if no elements match, timeout behavior, or performance implications of the limit 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?

  Two concise sentences with zero waste. First sentence states purpose and usage, second sentence explains the output's utility. Every word 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?

  Given no annotations and no output schema, the description does well by explaining the tool's purpose, usage context, and how outputs connect to sibling tools. However, for a tool that interacts with a dynamic browser environment, it could benefit from mentioning error cases or performance considerations.

  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 fully documents both parameters. The description adds minimal value by mentioning 'natural language description' for the query parameter, but doesn't provide additional semantics 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 verb ('Find') and resource ('elements on the page'), specifying it uses natural language queries. It distinguishes from siblings like browser_click (which clicks) and browser_text (which extracts text) by focusing on element location for subsequent actions.

  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 ('Find elements on the page using natural language') and provides a clear alternative usage pattern by mentioning that returns are 'refs you can use with click/type', directing to sibling tools like browser_click and browser_type for follow-up actions.

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