Server Quality Checklist

Tool Scores

• browser_handle_dialogC
  2/5.0
  Behavior1/5

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

  The description adds no behavioral detail beyond the annotations. Annotations already flag destructiveHint=true and readOnlyHint=false, but the description does not explain what 'handling' entails, potential side effects, or requirements like promptText. It neither contradicts nor enriches the annotations.

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

  Conciseness2/5

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

  The description is a single vague phrase that under-specifies the tool. It is not a case of efficient brevity but rather a failure to convey necessary information; every word merely repeats the name.

  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 that handles browser dialogs, the description omits crucial context such as when a dialog appears, what happens when accept is true or false, and how promptText is used. The schema covers parameter names but not the overall usage context, leaving the agent under-informed.

  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% for both parameters ('accept' and 'promptText'), so the schema carries full parameter semantics. The description adds nothing, but with complete schema coverage, a baseline of 3 is appropriate.

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

  Purpose2/5

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

  The description 'Handle a dialog' simply restates the tool name and title, providing no specific verb or resource scope. It does not indicate whether the tool accepts, dismisses, or otherwise interacts with the dialog, nor does it distinguish it from sibling 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?

  There is no guidance on when to use this tool relative to alternatives, such as when a JavaScript dialog blocks navigation or when to supply promptText. The description offers no context, exclusion criteria, or alternative tool suggestions.

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

• browser_console_messagesC
  2.9/5.0
  Behavior2/5

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

  The description adds little beyond the annotations. It omits critical behaviors such as level filtering (which includes more severe levels) and the distinction between messages since last navigation versus the whole session. The phrase 'all console messages' is inaccurate for non-default settings, though it does not contradict the readOnlyHint.

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

  Conciseness4/5

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

  The description is a single concise sentence with no redundancy. However, it is so brief that it sacrifices useful context, making it less effective than a slightly longer description would be.

  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?

  The tool has moderate complexity with three parameters including an enum, but the description fails to mention the filename saving option, the severity level semantics, or what the return value looks like. With no output schema, the agent is left without essential context.

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

  Parameters3/5

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

  Schema coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional meaning or context about the parameters, aligning with the baseline score of 3.

  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 returns console messages, using a specific verb and resource. However, it does not distinguish this tool from siblings like browser_network_requests, and the word 'all' is slightly misleading given the 'all' parameter defaults to false.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention filtering by level, saving to a file, or any exclusions or prerequisites.

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

• browser_evaluateC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. It does not disclose that evaluating JavaScript may have side effects, alter page state, or require permissions, even though annotations already flag destructiveness. The description is silent on what actually happens when the tool runs.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it may be slightly too terse for a tool of this complexity, but it earns its place as a clear summary.

  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 (arbitrary JavaScript execution, destructive potential, no output schema), the description is incomplete. It lacks information about when to choose this tool over browser_run_code_unsafe, safety considerations, return behavior, or side effects. The description alone is not sufficient for an agent to use it correctly in varied contexts.

  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 four parameters. The description's phrase 'on page or element' provides a minimal hint that aligns with the target/element parameters but adds no meaningful semantics beyond the schema, so baseline 3 is appropriate.

  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 uses a specific verb 'Evaluate' with the resource 'JavaScript expression on page or element', clearly conveying the tool's purpose. It is distinct from most sibling tools, though it does not explicitly differentiate itself from browser_run_code_unsafe, preventing a top 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 given on when to use this tool versus alternatives such as browser_run_code_unsafe. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer usage solely from the purpose.

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

• browser_file_uploadC
  2.9/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond the annotations. While annotations indicate destructiveHint=true and readOnlyHint=false, the description does not explain the implications of uploading files, such as triggering file selection dialogs or potential overwrites. It also omits the cancellation behavior mentioned in the schema.

  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 concise sentence that directly communicates the core functionality. It is front-loaded and contains no unnecessary words, making it highly efficient.

  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?

  Despite the tool's simplicity, the description lacks essential context. It does not explain return behavior, interaction with the page, or prerequisites. The cancellation behavior is only documented in the schema, not the description, leaving the overall picture incomplete for an agent.

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

  Parameters3/5

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

  The input schema already provides a complete description of the 'paths' parameter, including that omitting it cancels the file chooser. The tool description repeats no parameter details and adds no extra semantics. Given the high schema coverage, a baseline score of 3 is appropriate.

  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 function: 'Upload one or multiple files'. It includes a specific verb and resource, making the purpose evident. However, it does not distinguish itself from sibling tools, though no sibling appears to offer the same upload functionality.

  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?

  There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as needing a file input element on the page. The description only states what it does, not how to use it effectively.

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

• browser_navigateC
  2.9/5.0
  Behavior2/5

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

  Annotations already mark the operation as destructive (destructiveHint=true), but the description adds no further behavioral context—e.g., that navigation replaces the current page, may trigger network requests, or require page load waits. It simply restates the obvious action.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with zero wasted words. However, it is so terse that it borders on under-specification, making it less useful than a slightly more detailed description.

  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 simple one-parameter tool and annotations covering the safety profile, the minimal description might suffice for basic use. However, the large sibling set (navigate_back, click, find) would benefit from at least a brief mention of forward navigation or page loading, which is missing.

  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?

  The schema fully documents the only parameter 'url' with a description. The tool description repeats 'to a URL' but adds no additional meaning beyond what the schema already provides.

  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 'Navigate to a URL' clearly identifies the action (navigate) and resource (a URL). It distinguishes from the sibling browser_navigate_back by specifying a destination URL, though it doesn't explicitly name alternatives.

  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 instead of siblings like browser_navigate_back, browser_click, or browser_find. The description is a bare action statement with no context about typical use cases or exclusions.

  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?

  With annotations already declaring destructiveHint=true and readOnlyHint=false, the description adds minimal behavioral context beyond the annotations. It merely states 'editable element' and does not disclose consequences like replacing existing text, triggering key handlers, or submission behavior. No contradiction with annotations, but also no added value.

  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 concise sentence that front-loads the core purpose. It is appropriately sized and contains no filler or redundant 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 tool has 5 parameters and no output schema, the description is too sparse. It does not explain what happens after typing (e.g., whether focus is required, whether existing content is cleared, or how the 'submit' parameter affects behavior). Most of the burden falls on parameter descriptions, but the overall tool context remains incomplete.

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

  Parameters3/5

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

  Schema coverage is 100%, with all five parameters having descriptions. The tool description itself adds no parameter details beyond what the schema provides, so the baseline score of 3 applies.

  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 function: 'Type text into editable element' uses a specific verb ('Type') and resource ('editable element'). It is not a tautology and is understandable on its own, though it does not explicitly differentiate from sibling tools like browser_fill_form or browser_press_key.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when a different tool might be more appropriate. Usage is only implied by the tool's name and description.

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

• browser_hoverB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=true, which is surprising for a hover action, but the description adds no context about side effects, timing, or whether hover can trigger navigation or state changes. The description does not go beyond the obvious act of hovering, leaving behavioral ambiguity.

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

  Conciseness4/5

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

  The description is a single short sentence with no wasted words, making it easy to scan. However, it is arguably too terse to fully convey the tool's purpose and usage context, though conciseness itself is strong.

  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 simple hover action, the description is minimal, but the annotations (destructiveHint=true) and lack of output schema create a need for additional behavioral context. The description does not explain what happens after hovering, potential delays, or failure conditions, leaving the agent under-informed for a tool that could have side effects.

  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 'target' and 'element' described in the schema. The description itself adds no parameter details, but because the schema fully documents parameters, a baseline score of 3 is appropriate.

  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 'Hover over element on page' uses a specific verb (hover) and resource (element on page), clearly distinguishing it from sibling tools like browser_click, browser_drag, and browser_drop. It is immediately obvious what action this tool performs.

  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, such as when hovering is needed to trigger tooltips or reveal menus. No exclusions or prerequisites are mentioned, so an agent must infer usage solely from the name.

  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.1/5.0
  Behavior2/5

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

  Given that annotations already indicate destructiveHint=true, the description adds no extra behavioral context. It does not mention side effects like triggering shortcuts, submitting forms, or keydown/up events. The agent gains no insight beyond the name and annotations.

  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 sentence with no unnecessary words. It is perfectly concise, though brevity comes at the cost of usefulness.

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

  Completeness3/5

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

  For a simple one-parameter tool, the description is minimally adequate, especially with annotations and schema covering the basics. However, it fails to disambiguate from similar browser tools or mention any caveats, leaving the agent without full context.

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

  Parameters3/5

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

  Schema coverage is 100% and the parameter description ('Name of the key to press or a character to generate, such as ArrowLeft or a') is clear. The description does not add further parameter details, but the schema carries the burden adequately.

  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 action ('Press a key on the keyboard'), which is specific and distinct from siblings like browser_type (typing text) and browser_click. It lacks explicit differentiation from alternatives, but the verb+resource is unambiguous.

  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 browser_type, browser_fill_form, or other keyboard-related actions. There are no exclusions or contextual hints, leaving the agent to infer usage from the tool name alone.

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

• browser_clickB
  3.2/5.0
  Behavior3/5

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

  Annotations include destructiveHint: true and readOnlyHint: false, which already disclose that the tool may have side effects. The description adds no additional behavioral context, such as potential navigation or permission requirements. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It is concise, though it omits many details. The schema fills the gaps, so the brevity is acceptable.

  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?

  The description is minimal for a tool with 5 parameters and many siblings. While schema and annotations provide valuable structured information, the description lacks usage context, side effects, and alternative mentions, making it adequate but incomplete.

  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?

  The input schema provides 100% coverage with descriptions for all five parameters. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.

  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 resource (web page). It is a specific verb+resource combination, but it does not differentiate from sibling tools like browser_hover or browser_type, lacking explicit scope or selector details.

  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, no prerequisites, and no conditions. It simply states the action, 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.

• browser_fill_formB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation nature is conveyed. The description adds no extra behavioral context, such as permission requirements, side effects, or whether existing values are overwritten, but it does not contradict the annotations either. With annotations covering the safety profile, a 3 is appropriate.

  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 five-word sentence: 'Fill multiple form fields'. It has zero filler or redundancy and immediately communicates the core purpose, earning a top score for conciseness.

  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?

  The tool has a complex nested schema that is well-documented, but the description offers no usage context, alternative references, or expected return behavior. With no output schema and minimal description, the context is only moderately 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?

  The schema has 100% description coverage for the 'fields' parameter and its nested properties (name, type, value, target, element). The description itself adds nothing beyond the schema, so the baseline 3 is warranted.

  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 uses the specific verb 'Fill' with resource 'multiple form fields', clearly indicating a batch operation. It's distinguishable from siblings like browser_type (which likely fills a single field) but doesn't explicitly reference those alternatives. Overall, purpose is clear and specific.

  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 context on when to choose this tool over browser_type, browser_select_option, browser_click, or other sibling tools. There is also no mention of prerequisites or exclusions, leaving the usage guidance entirely absent.

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

• browser_select_optionB
  3.4/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context such as side effects (e.g., triggering change events), permission requirements, or what happens with multiple values. The description does not contradict the annotations, but it fails to disclose anything beyond them.

  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, focused sentence with no unnecessary words. It is perfectly front-loaded and earns its place.

  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 destructive browser interaction with no output schema, the description is too thin. It does not mention error scenarios, handling of multiple values, or the need for the target to be a select element. The schema and annotations are helpful, but the description leaves significant gaps for a tool that modifies page state.

  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?

  The input schema has comprehensive descriptions for all three parameters, so the baseline is 3. The description adds no extra parameter meaning beyond clarifying the tool targets a dropdown, but this is marginal since the schema already covers the target and values.

  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 'Select an option in a dropdown' clearly specifies the verb (select) and resource (option in a dropdown), distinguishing it from sibling interactions like browser_click or browser_type. It is specific and unambiguous.

  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?

  Usage context is implied by the tool name and description ('select' implies dropdowns), but there is no explicit guidance on when to use this vs. alternatives like clicking the dropdown, nor any exclusions or prerequisites. This mirrors the 'implied usage' level.

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

• browser_snapshotB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, establishing a safe, read-only operation. The description adds the fact that it captures an accessibility snapshot and is 'better than screenshot', hinting at a structured output, but it does not describe potential behavioral details like response size or whether the snapshot reflects dynamic DOM changes. No contradiction exists, but the additional value is limited.

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

  Conciseness4/5

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

  The description is very short and front-loaded with the verb, making it efficient. However, it uses a comma splice and the comparative 'better' is vague, slightly reducing credibility. It is still concise and avoids unnecessary repetition.

  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?

  There is no output schema, and the description only says it captures an 'accessibility snapshot' without describing the return structure. However, the schema parameters (e.g., 'target' referencing 'the page snapshot') and annotations provide enough context for an agent to understand basic invocation and safety. It is minimally complete but lacks crucial output format details.

  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?

  All four parameters (boxes, depth, target, filename) have thorough descriptions in the schema, providing 100% coverage. The description itself does not mention any parameters or add meaning beyond the schema, so it sits at the baseline of 3 where 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 specifies the action ('Capture accessibility snapshot') and the resource ('current page'), and explicitly positions it against the screenshot sibling by claiming it is 'better than screenshot'. This distinguishes it from browser_take_screenshot. However, 'accessibility snapshot' is not defined, leaving some ambiguity about what the output contains, so it does not reach 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 Guidelines3/5

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

  The only usage guidance is the comparative claim 'this is better than screenshot', which implies use over the screenshot tool. It does not specify scenarios where it should not be used or mention alternatives like browser_evaluate or browser_find. This is implied usage rather than explicit guidance, so it scores a 3.

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

• browser_tabsB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate a destructive, open-world tool. The description adds the action list but discloses no additional behavioral traits like reversibility or side effects of closing/selecting tabs.

  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?

  One sentence, perfectly front-loaded, with zero filler. It directly states the purpose.

  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 multi-action tool with a complete schema and annotations, the brief description is adequate, though it does not describe return values for the list action or edge cases like omitted index for close. Still, given the simplicity, it's mostly 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?

  The input schema provides full descriptions for all three parameters with 100% coverage, so the description adds no extra semantic detail beyond listing actions. Baseline 3 is appropriate.

  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 specifies four concrete operations (list, create, close, select) on browser tabs, clearly identifying a resource and a set of verbs. It distinguishes from sibling tools by focusing on tab management rather than navigation or page interaction, though it doesn't explicitly contrast with browser_close.

  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 about when to use this tool versus browser_navigate or browser_close, and there are no stated conditions or alternatives. The description simply lists actions, 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_closeA
  3.5/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint and openWorldHint, but the description does not clarify the scope of 'close the page'—whether it closes only the current tab, the entire browser, or whether it is reversible. This ambiguity is a significant gap for a destructive 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 only three words, achieving maximum conciseness and immediate clarity. Every word earns its place, and the structure is perfectly front-loaded.

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

  Completeness3/5

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

  For such a simple tool, the description is mostly adequate, but the ambiguity about scope (page vs. browser) and lack of information about side effects or reversibility prevent it from being fully complete. The annotations partially compensate, but the description itself is minimal.

  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 zero parameters, so the schema carries no information. With no parameters to document, the description does not need to add parameter semantics, and the baseline of 4 is appropriate.

  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 uses a specific verb 'close' with a clear resource 'the page', making the tool's purpose immediately obvious. It distinguishes naturally from sibling tools like browser_navigate or browser_click by describing a distinct action.

  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 instance, it does not mention that navigating to another page might be preferable to closing the current page, nor any prerequisites or exclusions.

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

• browser_dragA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description's 'drag and drop' action is consistent with these annotations but adds no extra behavioral context (e.g., triggering mouse events, potential side effects). It does not contradict annotations, so a score of 3 is appropriate.

  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 concise sentence, 'Perform drag and drop between two elements,' with no unnecessary words. It is front-loaded and immediately communicates the core action, earning a high score for conciseness.

  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?

  The tool has 4 parameters but only a minimal description. However, the schema provides detailed parameter descriptions, and annotations cover safety and mutability. The description alone is thin but, combined with structured data, is minimally sufficient for a simple drag-and-drop action. It does not explain return values or edge cases, but for this complexity level, a 3 is fair.

  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 each parameter (startTarget, endTarget, startElement, endElement) having its own description. The tool description does not add any parameter-level meaning beyond the schema. Per the baseline rule, a high-coverage schema yields a 3.

  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 'Perform drag and drop between two elements' clearly states the action (drag and drop) and the resource (between two elements). It is specific and distinguishes from sibling tools like browser_drop (drop without drag) and browser_click (single click).

  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 such as browser_drop or browser_click. It lacks any exclusions, prerequisites, or context indicating when drag-and-drop is the appropriate action.

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

• browser_wait_forA
  3.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnly and non-destructive behavior, so the description does not need to repeat that. It does add the three wait modes (appear, disappear, time), but it omits important details like what happens on timeout, behavior when no parameters are provided, or whether multiple conditions can be combined.

  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 sentence that is concise, front-loaded with the action, and covers all core functionality without any fluff. Every word contributes to meaning.

  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?

  With all parameters optional and no output schema, the description leaves ambiguity about calling with no arguments or with conflicting conditions (e.g., text and textGone together). It does not clarify timeout behavior or default waiting time, making it adequate but not 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?

  The input schema already describes all three parameters with 100% coverage. The description essentially restates the same information without adding new meaning, such as parameter precedence or interactions. It earns the baseline 3 for schema coverage but adds no extra depth.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: waiting for text to appear, disappear, or a time to pass. It uses a specific verb ('Wait') and describes the three distinct conditions, distinguishing it from sibling browser action tools like click or navigate.

  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 implicitly conveys when to use this tool: when you need to wait for a page state or a fixed delay. There are no explicit exclusions or mentions of alternatives, but no sibling tool provides waiting functionality, so the usage context is clear enough.

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

• browser_resizeA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, covering the safety profile. The description adds no extra behavioral context, such as how resizing affects the viewport or subsequent interactions. It meets the baseline but provides no additional value beyond the annotations.

  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, front-loaded sentence that is concise and complete. Every word contributes to the meaning, with no unnecessary detail or repetition.

  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 simple tool with full schema coverage and no output schema, the description is mostly sufficient. However, it omits practical details such as units (pixels) and any constraints on values, leaving a small gap in 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 coverage is 100% with descriptions for both width and height parameters. The description does not add further meaning beyond what the schema provides (e.g., units like pixels or allowed ranges), so the baseline score of 3 applies.

  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 uses a specific verb 'resize' with a clear resource 'browser window', effectively distinguishing it from sibling tools like browser_navigate or browser_take_screenshot. It directly states what the tool does with no ambiguity.

  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 intended usage is clear: use this tool to adjust the browser window's dimensions. No explicit alternatives or exclusions are mentioned, but given that no sibling tool serves a similar purpose, this is acceptable. The context is sufficient for an agent to decide when to invoke it.

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

• browser_run_code_unsafeA
  4/5.0
  Behavior4/5

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

  The description explicitly discloses the critical behavioral trait of executing arbitrary JavaScript in the server process, adding the 'RCE-equivalent' warning beyond the annotations' destructiveHint. This provides meaningful context about the tool's power and risk, going beyond the structured annotation flags.

  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 primary purpose and followed immediately by a crucial safety warning. Every word earns its place, with no redundancy or filler.

  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 simple structure (2 params, no output schema) and the presence of annotations and detailed schema, the description provides sufficient context for a risky tool. It covers purpose and danger, though it does not elaborate on return values or side effects, which are not critical given the schema's code example returns a value and the tool's open-ended nature.

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

  Parameters3/5

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

  Schema coverage for parameters is 100%, with thorough descriptions in the schema itself (including a code example and semantics for filename precedence). The tool description adds no additional parameter-level meaning, so it sticks to the baseline of 3 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 uses a specific verb ('run') and resource ('Playwright code snippet'), and clearly distinguishes the tool from siblings by stating it executes arbitrary JavaScript in the Playwright server process, making it RCE-equivalent. This differentiates it from browser_evaluate or other browser-interaction tools.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool versus alternatives like browser_evaluate, but the 'unsafe' and 'RCE-equivalent' warning implies it is intended for advanced or unrestricted scenarios. Usage guidance is implied rather than explicit, so it falls short of providing clear when/when-not direction.

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

• browser_navigate_backA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows it mutates browser state. The description adds no further context beyond the raw action, such as potential loss of form data or behavior when no history exists. This is adequate but not enhanced by the description.

  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 short sentence that fully conveys the function without any unnecessary words. It is front-loaded and immediately clear.

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

  Completeness5/5

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

  Given the tool's simplicity (no parameters, no output schema, annotations present), the description is complete enough. It fully communicates the purpose and behavior, and no additional details are required for a basic browser back action.

  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 zero parameters, so schema coverage is trivially 100%. No parameter documentation is needed. Baseline for 0 parameters is 4, and the description does not need to compensate for missing parameter details.

  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 'Go back to the previous page in the history' is specific and uses a clear verb with a resource (history). It distinguishes from siblings like browser_navigate by explicitly indicating a backward navigation action.

  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?

  Usage is implied through the description and tool name; there is no explicit comparison to alternatives or exclusions. While it doesn't state 'use when you need to return to a previous page', the simple action makes the context obvious from the description.

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

• browser_dropA
  4.2/5.0
  Behavior3/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is partially disclosed. The description adds the 'as if dragged from outside the page' simulation context and the requirement that at least one of 'paths' or 'data' must be provided. However, it does not disclose side effects, permissions, or what happens after the drop, so the added transparency is limited.

  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 long and front-loaded with the core purpose. The second sentence adds a necessary constraint about parameters. Every word earns its place; there is no filler.

  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?

  The description sufficiently explains the tool's behavior for a moderately complex action with nested objects. It covers the main action, the data types, and a key constraint, which is enough for an agent to invoke it. It lacks explicit guidance on return values or when to choose this over alternatives, but these are not critical for a drop operation.

  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 schema covers all four parameters with descriptions, giving a baseline of 3. The description adds a cross-parameter constraint—'At least one of "paths" or "data" must be provided'—which is not present in the schema's required list. This extra semantic clarifies the relationship between the parameters, going beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action: 'Drop files or MIME-typed data onto an element, as if dragged from outside the page.' It specifies the resource (element), the input types (files or MIME-typed data), and the manner (as if dragged from outside), which distinguishes it from sibling tools like browser_drag or browser_file_upload.

  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 the tool—when needing to simulate dropping files or data from outside the page onto an element. It does not explicitly mention alternatives or when not to use it, but the unique 'outside the page' distinction gives enough contextual guidance for an agent to select it over similar tools.

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

• browser_network_requestsA
  4.3/5.0
  Behavior4/5

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

  Annotations already cover read-only and non-destructive behavior. Description adds the temporal scope ('since loading the page') and return format (numbered list), which are useful behavioral details beyond the annotations.

  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 sentences, front-loaded with the core purpose, and a concise pointer to the follow-up tool. Every word earns its place.

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

  Completeness5/5

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

  For a listing tool with good annotations and full schema coverage, the description explains the output format and how to access details, which is complete enough for an agent to select and invoke 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% with detailed descriptions for filter, static, and filename. The description itself does not add parameter-specific information, so baseline 3 is appropriate.

  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?

  Description states 'Returns a numbered list of network requests since loading the page' with a specific verb and resource. It also distinguishes itself from the sibling browser_network_request by explicitly saying to use that tool for full details.

  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?

  Clear context that this tool produces a list to browse, with an explicit instruction to use browser_network_request for full details. It does not list exclusions but the intended workflow is clear.

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

• browser_network_requestA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool can return 'full details (headers and body)' or a single part when `part` is set, which is useful behavioral context beyond the annotations.

  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 sentences, no wasted words. The first sentence conveys the core behavior and variable output, and the second provides the necessary prerequisite context. It is well-structured and easily scanned.

  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 three parameters, an enum, and no output schema, the description sufficiently explains return granularity and how to obtain the index. The filename parameter is not mentioned in the description, but the schema documents it, so the description remains adequate.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description enhances the schema by explicitly defining 'full details' as 'headers and body' and reinforcing the index's origin in browser_network_requests, adding value beyond the schema's descriptions.

  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 states the specific action: 'Returns full details (headers and body) of a single network request,' using a clear verb and resource. It differentiates from the sibling browser_network_requests by specifying 'single' and referencing that tool's index.

  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 instruction 'Use the number from browser_network_requests' clearly implies a workflow: first list requests, then retrieve details by index. It provides context for when to use this tool but does not explicitly state when not to use it or name alternatives.

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

• browser_take_screenshotA
  4.4/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing a behavioral limitation: screenshots cannot be used as a basis for performing actions. This is contextual information beyond the structured annotations, though it does not detail output format or 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 two sentences, front-loaded with the primary purpose and immediately followed by a critical usage warning. Every word earns its place; there is no redundancy or extraneous information.

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

  Completeness4/5

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

  Given the tool's moderate complexity (6 parameters, no output schema) and rich annotations, the description covers the core purpose and a key limitation. It does not explicitly state what the screenshot returns or where it is saved, but the schema's filename parameter and the tool's name make this context reasonably implied. The description is sufficiently complete for an agent to select and invoke the tool 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?

  The input schema provides comprehensive descriptions for all six parameters, including enums and defaults, achieving 100% schema coverage. The tool description adds no additional parameter details, so the baseline score of 3 is appropriate since the schema carries the full burden.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Take a screenshot of the current page.' It uses a specific verb and resource, and distinguishes itself from sibling tools by explicitly pointing to browser_snapshot for actions, which prevents confusion.

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

  Usage Guidelines5/5

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

  The description provides explicit when-not-to-use guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This names the alternative tool and clearly delineates when browser_take_screenshot is not appropriate, satisfying the highest bar for usage guidelines.

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

• browser_findA
  5/5.0
  Behavior5/5

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

  The description adds behavioral context beyond the readOnlyHint annotation: it explains the return format (matching nodes with surrounding context and paths) and the cost benefit. It does not contradict annotations and gives users clear expectations of the tool's behavior.

  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 purpose, and every clause adds useful information (return format, context, cost comparison, parameter rules). There is no redundancy or fluff, making it highly efficient.

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

  Completeness5/5

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

  Given there is no output schema, the description sufficiently explains what the tool returns and how it works. It mentions search context, paths, and the fact that it's cheaper than a full snapshot, making it operationally complete for an agent.

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

  Parameters5/5

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

  The schema already describes both parameters thoroughly, and the description further clarifies semantics: text is case-insensitive substring, regex is case-sensitive with flag syntax. It also reinforces the either/or constraint, adding value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool searches the accessibility snapshot for text or regex, with a specific verb and resource. It distinguishes itself from sibling tools like browser_snapshot by highlighting that it's cheaper and yields targeted context.

  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 says to use this tool when you only need to locate an element and its ref, contrasting with capturing the whole snapshot. It also provides the rule to provide either text or regex, not both, which is essential for correct invocation.

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