Server Quality Checklist

Tool Scores

• browser_handle_dialogD
  1.6/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds nothing about the tool's behavior beyond that. It does not explain what happens when a dialog is handled, whether it types prompt text, or how it interacts with the page.

  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 very short, but it is under-specified rather than concise. A single vague sentence is not appropriately structured to convey essential information.

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

  Completeness1/5

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

  This tool has two parameters and no output schema, but the description provides almost no context about its operation, return values, or scenarios. It is inadequate for an agent to correctly invoke the 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?

  The input schema already provides full descriptions for both parameters (accept and promptText), so the baseline is 3. The description adds no additional semantic meaning to the parameters.

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

  Purpose1/5

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

  The description 'Handle a dialog' is essentially a restatement of the tool name and annotation title. It provides no specific verb or details about what handling entails, making it a tautology rather than a clear purpose statement.

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

  Usage Guidelines1/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 or how it compares to sibling tools. No exclusions, prerequisites, or alternative tool mentions are provided.

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

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context, such as the default behavior of returning only messages since the last navigation (unless all=true) or the ability to save to a file. This is a significant gap given the schema's richness.

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

  Conciseness3/5

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

  The description is a single short sentence, making it very concise. However, it is so terse that it omits key behavioral details, and the lack of structure means it doesn't front-load helpful information. It's not verbose, but it's minimally functional.

  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 three parameters, a required parameter, and no output schema, the description should explain return behavior and filtering semantics. It only says 'Returns all console messages' without mentioning level filtering, the 'all' flag, or file output, leaving the agent under-informed for correct invocation.

  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 input schema fully explains each parameter. The description itself adds no parameter-level meaning beyond what the schema provides, which aligns with the baseline 3 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 uses a clear verb and resource ('Returns all console messages'), which distinguishes it from sibling tools like browser_network_requests. However, 'all' is slightly ambiguous because the tool can filter by level and time scope, so it's not fully 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?

  No usage guidance is provided. The description doesn't mention when to use this tool versus alternatives like browser_network_requests, nor any scenario-specific advice. Users must infer its purpose solely from the name and brief description.

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

• browser_clickC
  2.9/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 further behavioral context. It does not say whether the click can trigger navigation, whether permission is required beyond the 'element' parameter, or what side effects might occur.

  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 with no redundancy or fluff. It is maximally concise and front-loaded.

  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, no output schema, and potentially destructive behaviors, the description is too sparse. It fails to mention important context like using a snapshot for target selection or the need for user permissions, making the tool under-described for its complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is adequately described in the schema. The description itself adds no extra meaning beyond what the schema provides, hence the 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 'Perform click on a web page' clearly states a specific action (click) on a resource (web page), which is unambiguous. However, it does not differentiate from sibling tools like browser_evaluate or browser_run_code_unsafe that could also simulate clicks, so it lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description does not mention the need for a page snapshot to obtain target references, nor does it clarify when a click is appropriate compared to other interaction tools.

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

• browser_dragC
  2.9/5.0
  Behavior2/5

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

  The annotations already flag this as destructive with readOnlyHint=false, so the agent knows it is a mutating action. However, the description adds no further behavioral context, such as the sequence of mouse events, potential navigation triggers, or element visibility requirements. It provides no additional transparency 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, direct sentence that immediately states the action without extraneous words. It is well-structured and front-loaded, making it easy for the agent to parse.

  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 having annotations and a detailed schema, the description itself is minimal. It does not explain the mechanics of the drag-and-drop, whether both elements must come from the same snapshot, or any post-conditions or side effects. The potential complexity of the action is not addressed, leaving the description incomplete for practical 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?

  The input schema provides full descriptions for all four parameters, including the distinction between target references and human-readable descriptions used for permission. With 100% schema coverage, the description does not need to add parameter semantics, and it does not, aligning with the baseline 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 uses a specific verb 'drag and drop' and identifies the resource as 'two elements', clearly communicating the core action. However, it does not explicitly differentiate from the sibling tool browser_drop, which could also be interpreted as a drop action, so it lacks explicit sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no information on when to use this tool versus alternatives such as hover, click, or browser_drop. It does not mention prerequisites, exclusions, or scenarios where drag-and-drop is appropriate, leaving the agent without guidance on tool selection.

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

• browser_file_uploadC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=true, but the description adds no additional behavioral context such as file chooser behavior, side effects, or failure modes. It merely restates the action without revealing what happens beyond the upload.

  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 immediately states the core function with no filler. It is appropriately minimal for a simple tool.

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

  Completeness2/5

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

  For a tool with no output schema and mutating/destructive behavior, the description provides minimal context. It doesn't mention that this operates on the active browser page, potential side effects, or error conditions. The schema and annotations cover some basics, but the description is insufficient for an agent to use confidently.

  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% – the paths parameter is fully documented in the schema, including the 'if omitted' cancellation behavior. The description itself adds no parameter information, so the baseline 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 action ('Upload') and indicates it can handle one or multiple files, differentiating it from siblings like browser_drop. However, it's minimalist and doesn't explicitly state the destination or context beyond 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 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_drop, nor are there any prerequisites or exclusions mentioned. The description simply states the action without operational context.

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

• browser_press_keyC
  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 already indicate destructiveHint=true and readOnlyHint=false, the description fails to mention potential side effects like triggering browser shortcuts or navigating away, which would be useful for the agent.

  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, extremely concise and front-loaded. Every word earns its place with no 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?

  For a tool marked as destructive with no output schema, the description is too minimal. It does not explain what happens when a key is pressed (e.g., key events dispatched, focus requirements, potential side effects), leaving the agent with insufficient context to anticipate the tool's impact.

  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 a clear description for the 'key' parameter including examples. The tool description itself does not add extra parameter information, 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 uses a specific verb 'Press' and resource 'key on the keyboard', clearly indicating the action. It does not explicitly distinguish from sibling tools like browser_type, but the focus on a single key press versus typing text is implicit in the phrasing.

  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 such as browser_type or browser_click. The description simply states what the tool does without specifying context or exclusions.

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

• browser_closeB
  3/5.0
  Behavior2/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 this is a destructive operation. The description adds no additional context about what is destroyed, whether unsaved state is lost, or what happens after closing. Since it adds no value beyond the annotation, a score of 2 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 'Close the page' – only three words, with no filler. It is perfectly concise and front-loaded, making it easy to read and process.

  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 zero-parameter close action, the description is minimally viable. However, it lacks specification of side effects (e.g., does it close the tab or the entire browser?) and return behavior. Given no output schema, more detail would be helpful for complete understanding.

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

  Parameters4/5

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

  The input schema shows zero parameters, and the description doesn't need to explain any. Per the guideline for 0-parameter tools, the baseline is 4, and the description doesn't miss anything.

  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 'Close the page' uses a specific verb and resource, clearly indicating a close operation. It is distinct from sibling tools like browser_navigate or browser_click. However, there is slight ambiguity about whether 'page' means the current tab or the entire browser window, 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 Guidelines1/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 or how it compares to alternatives. It does not mention any exclusions or specific contexts, leaving the agent without decision support for selecting this tool over others.

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

• browser_navigateB
  3.1/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows navigation changes state. However, the description adds no extra behavioral context, such as whether the tool waits for page load, what happens on failure, or whether it operates on the current tab. The description merely restates the title and provides no 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 conveys the essential action without any waste. Every word earns its place, and there is no verbosity or unnecessary detail. This is an ideal length for such a simple tool.

  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 low complexity (1 parameter, no output schema) and the presence of annotations, the description is minimally sufficient. However, it fails to mention whether the navigation is in the current tab, whether it waits for the page to load, or any side effects beyond the destructive hint. These are relevant contextual details that an agent might need to know, leaving a noticeable gap.

  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% coverage with a single parameter 'url' described as 'The URL to navigate to'. The description adds nothing beyond what the schema already provides, so the baseline score of 3 applies. There is no additional semantic meaning offered.

  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 states the action (navigate) and the resource (a URL). It is specific and easy to understand, but it does not explicitly distinguish itself from sibling tool browser_navigate_back, which is a related but distinct action. Since the core purpose is unambiguous, it earns a 4 rather than a 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 provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or situations where browser_navigate_back or other browser tools might be more appropriate. The agent is left to infer usage solely from the tool name and generic description.

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

• browser_resizeB
  3.1/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context. It does not explain potential side effects such as layout changes, viewport impacts, or implications for page interaction tests.

  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 that effectively communicates the action. It is appropriately sized for a simple tool, though it could optionally add context about units or viewport semantics without becoming verbose.

  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?

  While the description covers the basic action, it lacks usage guidelines and behavioral context. The destructiveHint annotation is not elaborated, and there is no mention of return values or side effects, leaving the agent under-informed for a tool that may significantly alter the browser 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 provides full descriptions for both parameters (width and height), achieving 100% schema description coverage. The tool description adds no extra meaning beyond what the schema already conveys, so 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 clearly states the tool's function with a specific verb ('resize') and resource ('browser window'), distinguishing it from sibling tools like navigate, click, or drag. It is unambiguous and directly indicates what the tool does.

  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 merely states the action without any context on applicable scenarios, 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_select_optionB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate the tool is not read-only and is destructive. The description adds no additional behavioral context, such as whether prior selections are replaced, or permission implications.

  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 with no filler, achieving maximum 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?

  For a simple tool with a comprehensive schema and annotations, the description is minimally viable. It lacks usage guidance and deeper behavioral context, but structured data covers parameter semantics and safety. Thus it meets the minimum bar but is not rich.

  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 describes all three parameters with clear descriptions (target, values, element). The description does not add any parameter-specific meaning beyond the schema, so baseline 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 uses a specific verb ('select') and resource ('option in a dropdown'), clearly distinguishing it from siblings like browser_click or browser_type. However, it does not specify that it works on <select> elements or support multiple values, slightly reducing clarity.

  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_click or browser_fill_form. The description simply states the action without contextual cues or exclusions.

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

• browser_evaluateB
  3.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. The description adds minimal behavioral context by mentioning 'on page or element,' but it does not disclose potential side effects of executing arbitrary JavaScript, such as page modifications or navigation.

  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 efficiently conveys the core purpose without unnecessary words. It is front-loaded and easy to parse.

  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 powerful JavaScript execution capability and the presence of a similar sibling (browser_run_code_unsafe), the description is insufficiently contextual. It lacks guidance on behavior, side effects, and relationship to other tools, making it incomplete for an agent deciding between alternatives.

  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 baseline is 3. The description does not add any information about parameter semantics beyond what the schema already provides, such as how `function` should be structured or the role of `filename`.

  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 evaluates JavaScript, with an optional scope ('on page or element'). However, it does not distinguish this from the sibling tool browser_run_code_unsafe, which likely performs a similar function.

  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 usage guidance is provided. There is no indication of when to prefer browser_evaluate over browser_run_code_unsafe or other browser tools, leaving the agent without decision support.

  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.2/5.0
  Behavior3/5

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

  Annotations already indicate this is not read-only and is destructive (readOnlyHint=false, destructiveHint=true). The description adds no additional behavioral context, but it is consistent with the annotations. No contradictions, but also no extra value beyond the annotation safety profile.

  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 with zero filler words. It communicates the core action effectively and is immediately understandable.

  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?

  This tool has a complex nested schema and is part of a large sibling set, but the description gives no context about behavior beyond 'fill fields'. No output schema exists, and important details like whether existing values are cleared, whether the form is submitted, or how to target elements are absent. The schema covers parameters, but the description lacks operational 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?

  The schema provides 100% coverage with descriptions for all fields, including target, name, type, and value. The description itself adds no additional parameter information, so it earns 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 uses a clear verb ('Fill') and specifies the resource ('multiple form fields'), which states the tool's function. However, it does not differentiate from sibling tools like browser_type or browser_select_option, which also interact with form fields.

  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. The description only states what it does, not when to prefer it over browser_type for a single field or browser_select_option for dropdowns. There are no exclusions or explicit use cases.

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

• browser_hoverB
  3.3/5.0
  Behavior2/5

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

  The description adds no behavioral information beyond the annotations already provided. Annotations indicate destructiveHint=true, but the description doesn't explain potential side effects like triggering mouseover events or requiring element visibility. It simply restates the 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 a single concise sentence, 'Hover over element on page', with no redundant words. It is appropriately front-loaded and easy to parse, though sparse in content.

  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 hover action, the description combined with rich schema and annotations is mostly adequate. However, it lacks context about when to use this tool and potential side effects, leaving some gaps in understanding the full implications of the action.

  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 having meaningful descriptions. The tool description itself adds no parameter information, but the schema already provides sufficient meaning, justifying the baseline score of 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 'Hover over element on page' clearly states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like browser_click and browser_drag by naming the specific hover operation.

  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 hover versus other interaction tools (e.g., click, drag), nor any prerequisites such as obtaining a page snapshot first. The description gives no context for selecting this tool over alternatives.

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

• browser_tabsA
  3.5/5.0
  Behavior3/5

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

  The description does not contradict the annotations (destructiveHint: true, readOnlyHint: false) and lists actions that align with those hints. However, it adds no extra behavioral context beyond what annotations and schema already provide, such as what happens when 'index' is omitted or how 'list' returns data.

  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 lists all supported operations. It front-loads the core purpose and contains no fluff or redundant detail.

  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?

  While the schema and annotations provide solid coverage of parameters and safety hints, the description is thin on operational details like return formats, edge cases for 'index', and what 'select' does exactly. There is no output schema to fill this gap. The tool is simple enough to function, but not richly specified as a whole.

  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%, meaning all three parameters are already documented with descriptions in the schema. The description adds no additional parameter meaning beyond restating the action names, 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 clearly states the resource (browser tab) and specific actions (list, create, close, select). This distinguishes it from sibling tools that handle navigation, clicking, or snapshots. The verb+resource structure makes the tool's purpose unmistakable.

  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 like browser_navigate or browser_snapshot. There are no prerequisites, exclusions, or explicit context suggesting typical use cases beyond the bare action list.

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

• browser_typeA
  3.5/5.0
  Behavior3/5

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

  Annotations already mark destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds no behavioral detail, such as whether existing text is replaced or whether input events are triggered, but it does not contradict 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 six-word sentence, immediately stating the action and target. There is no fluff or 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?

  Annotations and schema cover safety and parameter details, but the description lacks usage context, alternative-tool differentiation, and mention of behavioral nuances. It is minimally adequate but not complete for a destructive tool with 5 parameters and no output schema.

  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 100% coverage with descriptions for all 5 parameters, so the baseline is 3. The description itself adds no additional parameter semantics 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 'Type text into editable element' clearly states the action and target resource. It distinguishes itself from sibling tools like browser_press_key and browser_fill_form.

  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 such as browser_fill_form or browser_press_key. There are no prerequisites, exclusions, or context hints.

  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.6/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, so the agent knows it is a safe read-only operation. The description adds the specific wait conditions but does not disclose edge cases like behavior when no parameters are provided or when multiple conditions are combined. This is acceptable but not rich.

  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 action and covers all three use cases. There is no wasted wording or redundant information.

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

  Completeness4/5

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

  For a simple tool with three optional parameters and no output schema, the description is mostly complete. It covers the main functionality, though it leaves ambiguity about how parameter combinations (e.g., text + time) should be handled and what the return value is, so it is not a perfect 5.

  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%: each parameter already has a clear description ('text to wait for', 'time in seconds', 'text to disappear'). The tool description adds minimal extra meaning beyond that, so the baseline 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 what the tool does: waits for text to appear, disappear, or a specified time to pass. It uses a specific verb ('wait') and identifies the resources (text, time), but does not explicitly differentiate it from sibling tools, so it loses one point.

  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 usage context is implied: use this tool when you need to wait for a condition such as text appearing/disappearing or a time delay. However, there is no explicit guidance on when not to use it or mention of alternative tools (e.g., browser_find for checking text presence), so it is not fully explicit.

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

• browser_navigate_backA
  3.8/5.0
  Behavior2/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds no extra behavioral context, such as potential loss of form data or that the current page state is abandoned. It merely restates the core action without disclosing traits 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 short sentence, front-loaded, with no filler words. Every word earns its place.

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

  Completeness4/5

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

  For a parameterless navigation action with no output schema, the description adequately captures the core behavior. It does not mention behavior on empty history or whether it waits for page load, but given the simplicity, it is mostly complete.

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

  Parameters4/5

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

  The tool has zero parameters, so schema coverage is 100% and the baseline is 4. The description correctly contains no parameter details, and none are needed.

  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 ('Go back') and the resource ('previous page in the history'), making it specific and unambiguous. It distinguishes from sibling browser_navigate which goes to a specific URL.

  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 (when you want to go back) but does not explicitly contrast with alternatives like browser_navigate or browser_tabs. It lacks contextual guidance such as 'use this instead of navigating backwards via URL manipulation.'

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

• browser_snapshotA
  3.9/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it captures an 'accessibility snapshot' and claims it is 'better than screenshot', but it does not disclose return value format or any potential side effects. With annotations covering the safety profile, a score of 3 reflects that the description adds only minimal behavioral context beyond the structured metadata.

  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 immediately states the purpose and includes a comparative benefit. There is no redundant information or filler, and the structure is well-suited for quick reading by an AI agent.

  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 no output schema and only a minimal description. While the parameters are thoroughly documented in the schema and the read-only annotations are present, the description does not explain what the accessibility snapshot will contain or how the agent should interpret the response. This is a gap given the lack of an output schema, but the tool is relatively simple, so the description is minimally viable.

  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 baseline is 3. The description itself does not add any additional meaning to the parameters; the schema already explains boxes, depth, target, and filename. There is no extra context like parameter relationships or common usage patterns, so no credit beyond the baseline.

  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 with a specific verb ('Capture') and resource ('accessibility snapshot of the current page'). It also explicitly distinguishes it from the sibling tool browser_take_screenshot by claiming it is 'better than screenshot', which helps the agent choose correctly between these two related tools.

  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 implies usage for capturing accessibility snapshots and suggests it is the preferred choice over screenshots for that purpose. It provides a clear context but does not explicitly state when not to use it or mention other alternative tools, such as browser_find or browser_evaluate, which might also serve similar inspection needs.

  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/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, so the safety profile is covered. The description adds that the list is numbered and scoped to the page load, but does not disclose additional behavioral details like filtering behavior or return format beyond the schema. This is adequate but not rich.

  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 by a reference to the related tool. Every sentence is necessary and there is no wasted text.

  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 listing tool with no output schema, the description adequately covers what it returns (numbered list) and how to get details via the sibling tool. The schema covers all parameters, so the description is complete enough for an 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 parameters (filter, static, filename) are fully documented in the schema. The description does not add any extra parameter semantics, so the baseline 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 clearly states the tool returns a numbered list of network requests since page load, using a specific verb and resource. It also distinguishes itself from the sibling browser_network_request by explaining that the singular tool is used 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?

  It provides explicit guidance to use browser_network_request with the returned number for full details, establishing a clear workflow. It does not mention exclusions or when not to use this tool, but the context is clear enough for a listing tool.

  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, so the mutation risk is known. The description adds context that the drop is simulated as an external drag, and the 'At least one of paths or data' constraint is useful. It does not describe side effects (e.g., navigation) but with annotations present, this is acceptable.

  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 action and key constraint. Every word earns its place without redundancy.

  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 no output schema, the description combined with the detailed input schema covers the essential semantics: what is dropped, on what, and the required data. It does not explain post-drop behavior, but given the simplicity of the action and existing annotations, this is sufficient.

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

  Parameters4/5

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

  The input schema already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds semantic value by stating the dependency between 'paths' and 'data' (at least one required), which is not enforced by the schema's required array. This extra constraint earns a 4.

  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 ('Drop') and resource ('files or MIME-typed data onto an element'), and clearly distinguishes from sibling tools like browser_drag by noting 'as if dragged from outside the page'. It also conveys essential constraints (must provide paths or data).

  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 phrase 'as if dragged from outside the page' implies when to use this tool vs browser_drag (which is for in-page dragging), and the constraint 'At least one of paths or data must be provided' gives a precondition. However, it does not explicitly reference alternatives or state when not to use 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.2/5.0
  Behavior5/5

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

  Annotations already indicate destructiveHint=true, but the description adds crucial context: code runs in the Playwright server process (not the browser page) and is equivalent to remote code execution. This goes well beyond the structured 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?

  One sentence, front-loaded with the core action, followed by a sharp safety warning. No wasted words; the title and description are efficient.

  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?

  Despite no output schema, the description fully discloses the primary risk and execution environment. It does not explain return behavior, but for a code execution tool, the return is whatever the user's code returns. The warning about RCE is the essential context, and it is present.

  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 code and filename, with detailed examples in the code parameter. The description does not need to add more, so the baseline 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 clearly states the tool runs a Playwright code snippet and explicitly notes it executes arbitrary JavaScript in the server process, distinguishing it from safer alternatives like browser_evaluate. The warning 'RCE-equivalent' makes the purpose unmistakable.

  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 is only for advanced/unsafe scenarios via 'Unsafe' and 'RCE-equivalent', but it does not explicitly mention when to prefer this over browser_evaluate or other sibling tools. No clear alternatives or exclusions are provided.

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

• browser_findA
  4.4/5.0
  Behavior4/5

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

  Annotations already cover readOnlyHint and destructiveHint. The description adds valuable behavior beyond that: it returns 'matching snapshot nodes with a few lines of surrounding context' and displays each under its 'path from the root of the tree.' No contradictions; the extra cost context is helpful.

  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 primary action. Each clause adds value: search target, return format, path display, and cost benefit. No fluff or redundancy.

  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 moderate complexity and the lack of an output schema, the description adequately explains the return format (matching nodes with context) and the specific use case. It does not cover edge cases like no matches, but the cost comparison with browser_snapshot adds useful context that goes beyond the schema.

  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 each parameter fully described (case-insensitive substring, regex flags). The description only reinforces the 'either/or' requirement without adding deeper parameter syntax details, 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?

  The description opens with a specific verb and resource: 'Search the accessibility snapshot... for text or a regular expression.' It also distinguishes from sibling browser_snapshot by noting it is 'cheaper than capturing the whole snapshot,' making the purpose unambiguous.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool: 'when you only need to locate an element and its ref' and frames it as a cheaper alternative to capturing the whole snapshot, which implies browser_snapshot as the alternative. Also instructs to provide either text or regex, not both.

  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 behavioral context by explaining the output includes headers and body, and that setting `part` limits the result to a single part. This goes beyond the annotations without contradicting them, though it does not mention error handling or invalid index 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 the main action, and every word contributes. It avoids redundancy and clearly communicates the core behavior and the key parameter (`part`) without unnecessary detail.

  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?

  With a small parameter set and no output schema, the description covers the essential behavior: what the tool returns, how to specify the request, and how to get a part. It could mention output format or potential errors, but the existing schema annotations and sibling reference make it sufficiently complete for a simple retrieval tool.

  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 parameters are already documented. The description adds meaning by explaining that the `index` comes from browser_network_requests, and that `part` selects a single part. This cross-reference and interpretation adds value beyond the schema's individual field 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 clearly states the tool returns full details of a single network request, or a single part if specified. It uses a specific verb ('Returns') and resource ('single network request'), and distinguishes itself from the sibling tool browser_network_requests by focusing on a single request rather than listing multiple.

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

  Usage Guidelines4/5

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

  The description explicitly instructs to use the number from browser_network_requests, establishing a clear prerequisite and workflow. It does not explicitly mention when not to use it or alternatives, but the reference to the sibling tool provides enough context for appropriate usage.

  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 (readOnlyHint: true, destructiveHint: false) already establish the safety profile. The description adds a non-obvious behavioral constraint: screenshots cannot be used as a basis for actions. This is valuable context beyond the annotations. No contradictions exist.

  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 with zero waste. It front-loads the core purpose and then provides a critical usage distinction. Every word earns its place.

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

  Completeness4/5

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

  For a relatively simple screenshot tool with excellent schema coverage, the description is functionally complete. It covers the main caveat (actions require browser_snapshot) and the schema handles all parameter details. No output schema exists, but the return type (screenshot image) is self-evident from the tool's name and purpose.

  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 all six parameters (type, scale, target, element, filename, fullPage). The description itself adds no additional parameter context, so the baseline score of 3 is appropriate given that the schema carries the semantic 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 uses a specific verb and resource: 'Take a screenshot of the current page.' It clearly distinguishes the tool from browser_snapshot by noting that screenshots cannot be used for actions, which is a key differentiating detail.

  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 guidance: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This directly tells the agent when not to use this tool and names the alternative, making the usage context unambiguous.

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