Server Quality Checklist

Tool Scores

• browser_clickC
  2/5.0
  Behavior2/5

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

  Annotations declare readOnlyHint=false and destructiveHint=true, which already tell the agent this is a mutating and potentially destructive action. The description adds no behavioral context beyond a generic 'click' – it does not mention possible navigation, form submission, or other side effects that would be useful beyond the 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.

  Conciseness2/5

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

  The single-sentence description is extremely concise but under-specified. It provides no structure or front-loading of key details like the required target parameter, and its brevity stems from omission rather than efficiency.

  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 5 parameters and no output schema, the description should explain how to specify the target (e.g., referencing the page snapshot) and what the click action accomplishes. The description is too skeletal to give an agent enough context to invoke it correctly, even though the schema covers parameter 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?

  Schema description coverage is 100%, so all five parameters (button, target, element, modifiers, doubleClick) are fully documented in the schema. Per the rubric, a high coverage baseline of 3 applies. The description adds no parameter 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.

  Purpose2/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' states a verb and resource but is vague: it does not specify what is clicked (target element) or how it differs from sibling tools like browser_hover or browser_drop. It is close to a tautology of the name 'browser_click' with only a generic 'web page' context.

  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 versus alternatives such as browser_double_click (if it existed) or browser_hover. No mention of scenarios or exclusions, so an agent receives no help in selecting the right action.

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

• browser_handle_dialogC
  2.2/5.0
  Behavior2/5

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

  The description adds no behavioral context beyond what the annotations already state. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not explain what destructive behavior may occur, whether dismissing a dialog can lose input, or any side effects of handling the dialog.

  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 short, but the brevity comes from under-specification rather than conciseness. 'Handle a dialog' is a placeholder-level phrase that does not earn its place by adding meaningful 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?

  Even though the schema covers parameters and annotations cover safety, the description lacks essential context about dialog behavior, such as which dialog types are supported, what happens when accept is false, and what the promptText field is used for in practice. This is particularly important because no output schema exists.

  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 accept and promptText are already clearly documented. The description itself adds no parameter information, but the schema carries the full burden adequately, justifying the baseline score of 3.

  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' is a near-verbatim restatement of the tool name and title. It does not specify what handling involves, such as accepting, dismissing, or providing prompt text, nor does it distinguish itself from the broader set of 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 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 does not say when to use this tool, when not to use it, or how it relates to sibling tools like browser_click, browser_evaluate, or browser_snapshot.

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

• browser_navigateC
  2.6/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 description's job is reduced. However, the description adds no additional context about side effects (e.g., page load waits, redirects, script execution). It simply restates the action without elaborating on consequences or what happens after navigation.

  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, extremely concise and front-loaded. It wastes no words, though it is minimal. This is acceptable for a simple tool, though it could be slightly more informative 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?

  With no output schema and only one parameter, the description should clarify what happens after navigation (e.g., waits for load, returns status). It does not mention any behavior post-navigation, nor does it clarify the openWorldHint (e.g., potential for leaving the current page context). The description is insufficient for an agent to fully understand the tool's effects, despite the annotations providing some safety signals.

  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 URL parameter is fully documented in the schema. The description adds no further meaning beyond what the schema provides. Baseline 3 is appropriate when schema handles parameter semantics.

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

  Purpose3/5

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

  The description states the verb 'Navigate' and the resource 'URL', which is clear and specific. However, it does not differentiate from sibling tools like browser_navigate_back or browser_click, making the purpose somewhat generic. It is not a pure tautology, but it offers little 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 such as browser_navigate_back or browser_click. There is no mention of prerequisites, typical use cases, or conditions under which this tool is preferred. The agent must infer usage from the name alone.

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

• browser_closeC
  2.7/5.0
  Behavior2/5

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

  Annotations already indicate destructiveHint=true, so the description adds no new behavioral context. It does not disclose that closing a page may lose unsaved data, terminate the current session, or alter navigation history. With the destructive flag set, the description should provide more context but fails to.

  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 one-line description is extremely concise, but it is under-specified rather than efficiently informative. It omits useful context like scope (current page) and consequences, making it short without earning its place through additional value.

  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 action with no output schema, the description should clarify what happens (closes the current tab or browser) and warn about potential data loss. This description provides none of that, leaving the agent with insufficient context to invoke the tool safely and correctly.

  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 is trivially complete. The description adds nothing about parameters, but none are needed, so a baseline score is appropriate since there is no gap to compensate.

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

  Purpose3/5

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

  The description 'Close the page' uses a specific verb and resource, but it is vague about which page is closed (e.g., current tab) and doesn't explicitly distinguish itself from sibling tools like browser_navigate_back. It is not a tautology, but it lacks precision that would help an agent select it correctly.

  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 circumstances (e.g., when done with a page) or exclusions (e.g., use navigate_back to return instead). An agent must infer when closing a page is appropriate.

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

• browser_resizeC
  2.8/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. Annotations indicate destructiveHint=true and readOnlyHint=false, but the description does not clarify the nature of the change (e.g., viewport size affects layout, may cause re-rendering). It merely restates the action without elaborating on side effects or requirements.

  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 sentence with no excess, satisfying conciseness. However, it lacks structural elements like a lead with key info or any breakdown of behavior; it is adequate but adds nothing beyond the bare statement.

  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 tool with full parameter documentation, the description could suffice, but it ignores the destructiveHint annotation and does not mention any return value, asynchronous behavior, or side effects. Given the openWorldHint and destructiveHint, the description should clarify the impact, but it is minimal and leaves the agent to guess.

  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 straightforward descriptions for both width and height, so the schema fully documents the parameters. The description does not add any additional meaning, but since the baseline is 3 for high coverage, this is acceptable.

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

  Purpose4/5

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

  The description clearly states the verb 'Resize' and the resource 'browser window', making the core purpose unambiguous. It does not differentiate from sibling tools like browser_navigate or browser_snapshot, but the intent is specific enough that an agent can likely infer what it does without confusion.

  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 does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage from the name alone. With many browser_* siblings, this is a notable gap.

  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?

  Annotations already mark this as non-read-only and destructive, so the mutation risk is known. However, the description adds no behavioral context beyond the action itself—no mention of side effects, required element states, waiting, or event triggering.

  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 9-word sentence that is easy to scan and front-loads the action. It is concise without waste, though it stops short of adding operational detail that would make it more useful.

  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 description plus schema and annotations cover the basic invocation (source and target elements, destructive nature), the tool lacks any indication of when to use it, prerequisites, or behavioral outcomes. This leaves gaps for an agent deciding between several interaction tools, so it is 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 schema provides descriptions for all four parameters, and the tool-level description adds no parameter details. Given 100% schema coverage, the baseline of 3 applies without any extra semantic enrichment.

  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 states a clear verb phrase 'Perform drag and drop' and identifies the resource as 'between two elements'. This conveys the core action precisely, but does not explicitly distinguish it from the sibling browser_drop or coordinate with browser_click/hover.

  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 about when drag and drop is preferable to alternatives like browser_click, browser_hover, or browser_drop. The description neither states use cases nor excludes alternatives, so an agent must infer applicability from context.

  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?

  Annotations already carry destructiveHint=true and readOnlyHint=false, so the description doesn't contradict them. However, the description adds no additional behavioral context—it doesn't warn that the evaluation can modify the page, require element targeting, or return results in a specific format. With annotations present, the bar is lower, but this desc provides almost no value beyond the bare statement.

  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?

  A single, front-loaded sentence with zero waste. It immediately conveys the core purpose without extraneous detail. Perfectly concise for what it intends to say.

  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 code execution tool, the description is severely under-specified. It doesn't explain return value behavior (no output schema), how to reference elements, when results are saved to file vs returned as text, or any security/side-effect warnings. Siblings like browser_run_code_unsafe hint at a risk distinction, but this desc doesn't provide enough for an agent to use it correctly without opening the schema and guessing.

  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 documents all four parameters (target, element, filename, function). The description adds no extra meaning beyond the schema; it doesn't clarify relationships between parameters or give examples. Baseline 3 is appropriate because the schema handles the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action (evaluate) and the target (JavaScript expression on page or element). It is specific enough to distinguish from navigate/click tools, though it doesn't explicitly differentiate from the sibling browser_run_code_unsafe. The verb-resource pairing 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 gives no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer browser_run_code_unsafe, nor does it mention prerequisites like needing a snapshot or user permission. Agents are left to infer usage purely from the schema.

  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 flag this as a non-read-only, destructive action, so the safety profile is covered. But the description adds no extra behavioral context: it doesn't explain file-chooser behavior, what happens when paths are omitted, or what side effects the upload has. This leaves the operational behavior largely opaque.

  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 focused sentence with no wasted words and is easy to parse. It is appropriately concise, though it borders on under-specification because it carries no context about the file chooser or invocation timing.

  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 one-parameter tool with complete schema coverage and annotations, the definition is minimally viable. However, it misses key operational context: when to call this tool, how the upload target is determined, and how it interacts with the browser's file chooser. The schema hints at cancellation but the overall description leaves gaps.

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

  Parameters3/5

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

  The schema already describes paths as absolute file paths and notes that omitting them cancels the file chooser, with 100% description coverage. The description adds no additional parameter meaning beyond the obvious 'files' connection, 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.

  Purpose4/5

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

  The description states a specific verb and resource: 'Upload one or multiple files.' It clearly identifies the core operation and is distinguishable from sibling tools like browser_drop or browser_fill_form. However, it does not explicitly mention the browser/file-chooser context, which would sharpen the purpose further.

  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 gives no guidance on when to use this tool versus alternatives such as browser_drop, nor does it mention the need for a file chooser to be active. There are no exclusions, prerequisites, or contextual triggers provided.

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

• browser_fill_formC
  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, so the agent knows this is a mutation. The description adds no additional behavioral context, such as how form filling works, whether it triggers events, or how it uses element references from the page snapshot. It relies entirely on annotations and schema.

  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 filler words, and the main action is front-loaded. However, it is so minimal that it borders on under-specification, which is why it does not earn a 5.

  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 a complex nested parameter schema and operates on live browser pages, yet the description provides no usage context. It fails to mention that the tool is for batch operations, how targets are resolved, or any behavior around permissions or field types. The schema compensates for parameter details but not for overall 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?

  Schema coverage is 100% for the single parameter, and the schema provides rich descriptions for each nested field property (target, name, type, value, element). The description 'Fill multiple form fields' does not add any parameter-specific meaning beyond what the schema already offers, 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 uses a specific verb ('Fill') and resource ('multiple form fields'), which clearly conveys the tool's core action. However, it does not distinguish itself from sibling tools like browser_type or browser_select_option, so an agent might need to inspect the schema to know exactly how it differs.

  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. Siblings such as browser_type, browser_click, and browser_select_option perform related actions, but the description does not mention when to prefer one over the other, nor any conditions or prerequisites.

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

• browser_select_optionC
  2.9/5.0
  Behavior2/5

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

  Annotations already signal readOnlyHint=false and destructiveHint=true, but the description adds no behavioral context beyond that—nothing about triggering events, changing form state, or multi-select side effects. With a destructive hint, the absence of any warning or side-effect disclosure is a notable gap.

  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, waste-free sentence that states the core action immediately. It is concise and front-loaded, though it does not use the available space to add valuable context.

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

  Completeness3/5

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

  For a simple tool with a fully described schema and annotations covering the mutation/destructive profile, the description is minimally adequate. It lacks guidance on alternative-tool selection, side effects, and the exact meaning of 'values', which leaves an agent with unanswered questions 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 schema already documents target, values, and element in detail; the description adds no parameter-level meaning. The baseline of 3 applies because schema carries the burden, but the description does not clarify whether 'values' are option labels, value attributes, or indexes.

  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 'Select an option in a dropdown' names a specific verb and resource and clearly identifies the tool's job among a long list of browser interaction tools. It does not, however, name or differentiate itself from close siblings like browser_click or browser_type, which could also be used for dropdown interaction.

  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 about when to choose this tool over browser_click, browser_type, or browser_fill_form, and states no prerequisites or conditions. The intended use is only implied by the tool's purpose, so an agent gets no decision support for selecting among alternatives.

  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/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, which signal that pressing a key can cause side effects. The description adds no further behavioral details, such as whether it sends an event to the current page or triggers navigation. Given the annotation coverage, the description is adequate but not enriched.

  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 efficient sentence that conveys the core purpose without waste. It is front-loaded and earns its place, though it could be slightly expanded to include a usage hint without losing 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?

  Given the tool's simplicity (one parameter fully described in schema, no output schema, annotations covering safety), the description is functionally complete. However, it lacks any mention of when to use it or what happens after pressing a key, which is a minor gap for an agent deciding between this and browser_type.

  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 for the only parameter 'key' with a description ('Name of the key to press or a character to generate...'), which already documents its meaning. The tool description adds no additional context beyond this, 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 'Press a key on the keyboard' clearly states the verb (press) and resource (a key), making the tool's purpose immediately understandable. However, it does not differentiate from siblings like browser_type, which also involves keys, though it is still specific enough to be unambiguous.

  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 versus alternatives. It does not mention that browser_type is for typing text or that this tool is for special keys like arrows or modifiers. The description offers no context for selection, leaving the agent to infer usage from the name and schema alone.

  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?

  Annotations already indicate a non-read-only, destructive-capable action, but the description adds no behavioral context beyond the action itself. It does not explain side effects such as hover states, revealed UI, or potential page changes, even though destructiveHint=true suggests mutating 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 a single, front-loaded sentence with no filler or repetition. It is appropriately sized for a simple two-parameter browser action.

  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 plus schema and annotations are mostly sufficient, but there is no output schema and no explanation of typical use or return behavior. It is adequate, 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?

  Schema description coverage is 100%, so the parameters are fully documented. The description itself adds no parameter semantics beyond the schema, which earns the baseline score.

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

  Purpose5/5

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

  The description states a specific action ('Hover') and a clear resource ('element on page'), which distinguishes it from sibling tools like browser_click, browser_drag, and browser_drop. There is no ambiguity about 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 gives no guidance on when to use hover rather than a click, drag, or other interaction, and does not mention that hovering can be used to trigger tooltips or menus before acting. No when-not-to-use or alternative selection criteria 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_messagesB
  3.4/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, covering the safety profile. The description adds no additional behavioral context such as return format handling, file saving behavior, or any performance implications. For a read-only getter, this is minimally adequate, but it doesn't go beyond what the annotations already imply.

  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 words. Every part states the core action without redundancy. It is appropriately concise for a simple tool and is easy to parse quickly.

  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 three well-documented parameters and clear annotations, the description is almost sufficient. The only missing context is the implicit assumption that it operates on the current browser tab/session, but that is apparent from the tool name and sibling context. The description doesn't need to explain return values since there is no output schema, and the parameters clarify 'all' and 'level'. Overall, it's complete for the tool's simplicity.

  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?

  With 100% schema description coverage, every parameter (all, level, filename) is already documented in the schema. The description does not add any semantic nuance beyond what the schema provides; it simply states the action. Per calibration, the baseline is 3 when the schema carries the parameter documentation, so this 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 states a specific verb ('Returns') and resource ('console messages'), which clearly indicates the tool's function. It doesn't explicitly differentiate among siblings, but the sibling tools are about navigation, network, and interactions, so the purpose is distinct without needing further clarification. The phrase 'all console messages' is clear enough, though it doesn't specify the scope (e.g., current page vs. session) without reading the parameters.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it's for reading console output, nor does it suggest conditions for use (e.g., after a navigation or for debugging). There are no exclusions or references to other tools like browser_network_requests, so an agent would have to infer usage solely from the name and parameters.

  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?

  Annotations already declare the tool non-read-only and destructive, and the description's 'close' action is consistent with that; there is no contradiction. The description adds no further behavioral context, such as that 'list' is read-only or what exactly gets destroyed when a tab is closed, so it does not go 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 with no filler. The operation list is presented immediately and matches the tool's scope, making it appropriately sized for a tool whose parameters are already documented in the schema.

  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 four-action tool, the description is terse and relies heavily on the schema for action-specific requirements such as url for 'new' and index for 'close/select'. It also does not clarify what 'list' returns, but the schema and annotations cover most invocation details, making it minimally complete rather than richly descriptive.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear explanations for all three parameters including the enum meanings and optional-index behavior. The description itself adds no extra parameter meaning beyond what the schema already provides, 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 specific verbs — list, create, close, select — tied to the 'browser tab' resource, so an agent can identify the tool's scope. It is slightly weaker on sibling differentiation because it never distinguishes tab closing from browser_close or tab navigation from browser_navigate, and it says 'create' while the action enum uses 'new'.

  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 by naming tab-level operations, but the description gives no explicit when-to-use or when-not-to-use guidance. With siblings like browser_navigate and browser_close available, the agent must infer that this tool handles tab-level actions while those handle navigation and window-level actions.

  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
  3.6/5.0
  Behavior4/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 crucial context: 'unsafe', 'executes arbitrary JavaScript in the Playwright server process', and 'RCE-equivalent', which goes beyond what annotations convey about the nature of execution and risk.

  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, zero waste, and the key safety warning is front-loaded. Very concise and effectively structured.

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

  Completeness4/5

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

  Given the tool's complexity and lack of output schema, the description sufficiently covers the core behavior and risks. It does not describe the return value, but for an unsafe arbitrary-code tool, that is a minor omission.

  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 code and filename fully documented. The description text does not add anything beyond the schema, so a 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 the tool runs a Playwright code snippet and executes arbitrary JavaScript in the server process, with an explicit 'unsafe' warning. It distinguishes itself from typical browser actions by highlighting RCE-equivalence, though it does not explicitly differentiate from sibling browser_evaluate.

  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 on when to use this tool versus the many sibling tools. It does not mention alternatives or scenarios where this is appropriate or inappropriate, leaving the agent to infer.

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

• browser_snapshotA
  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 safety profile is covered. The description adds 'Capture accessibility snapshot' which is consistent with a read-only operation, and 'better than screenshot' is a comparative statement, not a behavioral detail. It does not describe what the snapshot contains, return format, or side effects, so it adds minimal 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 sentence with zero filler. The primary action and the key comparison are front-loaded. Every word earns its place, and it is appropriately sized for a tool with a clear purpose.

  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?

  There is no output schema and the description does not explain what the snapshot looks like or how to interpret it. An agent is left guessing about the return format (e.g., text of the accessibility tree) and whether it includes selectors or references. While the parameters are documented, the tool's output and typical use cases are under-specified, making it incomplete for a tool that returns a snapshot.

  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%; each of the four parameters (boxes, depth, target, filename) is fully described in the schema. The description adds no parameter information, but since the schema covers everything, 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 states a specific verb ('Capture') and resource ('accessibility snapshot of the current page'), and explicitly contrasts it with a sibling ('better than screenshot'), distinguishing it from browser_take_screenshot without needing to inspect the schema. The title 'Page snapshot' reinforces the intent. No ambiguity about 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 Guidelines3/5

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

  The only usage hint is 'better than screenshot', which implies it is preferred over screenshots for capturing page state, but does not explicitly say when to use this tool versus others (e.g., browser_evaluate, browser_console_messages). It lacks explicit conditions, prerequisites, or exclusions. The hint is clear but underdeveloped.

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

• browser_typeA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare the write/destructive nature (readOnlyHint=false, destructiveHint=true), so the description does not need to restate it. The description adds little behavioral context beyond that; it does not say whether existing text is replaced, whether events fire, or whether focus is required, but this is not an annotation contradiction.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with no filler or redundancy beyond the title. The added phrase 'into editable element' carries real scoping value.

  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 complete schema parameter descriptions and annotations covering the safety profile, the minimal description is largely sufficient for correct invocation. It only falls short on explicit sibling differentiation and behavioral nuances such as replace-vs-append behavior.

  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?

  Input schema description coverage is 100%, so all five parameters are already documented with their meanings. The description itself adds no parameter semantics, 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 states a clear action ('Type text') and the resource ('editable element'), so the tool's core purpose is immediately identifiable. However, it does not distinguish this from sibling tools such as browser_fill_form or browser_press_key, so it lacks 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 Guidelines3/5

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

  The description implies when to use the tool: whenever text needs to be entered into an editable element. It provides no explicit context about when to prefer this over alternatives like browser_fill_form, nor any exclusions, leaving usage selection partly to inference.

  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 cover safety (readOnlyHint=true, destructiveHint=false), so the description does not need to repeat those. It does add the behavioral context of what it waits for (text appear/disappear, time passing), but it does not disclose important details such as whether it polls continuously, whether there is a timeout, or what happens if multiple conditions are specified simultaneously. These are behavioral aspects beyond the scope of 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, tightly packed sentence that front-loads the core action and enumerates all conditions with no filler. Every word earns its place, and the structure is easily scannable for an 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?

  For a tool with three optional parameters and no required fields, the description covers the basic use cases (text appear, text disappear, sleep). However, it misses critical edge cases: behavior when multiple parameters are provided (e.g., both text and time), timeout behavior, and what the tool returns after waiting. Given the absence of an output schema, these gaps are meaningful for an agent deciding how to invoke and interpret results.

  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 descriptions are present (coverage 100%) but generic: 'The text to wait for' and 'The text to wait for to disappear' do not clarify which parameter corresponds to appearance vs. disappearance. The tool description explicitly maps text to appearance, textGone to disappearance, and time to 'a specified time to pass', adding meaning that the schema alone does not convey. This enhances parameter understanding.

  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 a specific action ('wait for') with three distinct conditions: text appearance, text disappearance, or a time delay. It uniquely identifies this tool's purpose among the browser sibling tools, none of which handle waiting. The verb-resource pairing is explicit 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?

  The usage context is implied by the tool's unique purpose: it is the only wait-related tool in the sibling list, so an agent understands it is meant for waiting. However, the description provides no explicit guidance on when to choose it over other tools (e.g., after navigation, before assertions) and no exclusions. No alternative tools are mentioned, so there is no routing information.

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

• browser_dropA
  4/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 description's burden is lower. However, it adds no extra behavioral context—e.g., that dropping triggers DOM events, may cause navigation, or could require element permission. It simply restates the action without enriching the safety profile beyond 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 with zero fluff; the core action and the mandatory constraint are front-loaded. Every word earns its place, and the structure is immediately scannable.

  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 full schema coverage and an existing annotation set, the description covers the essential invocation logic (the at-least-one requirement) and the two data modes. It doesn't explain return values or side effects, but no output schema exists and the schema already documents all parameters. Minor omissions around element targeting are handled by the schema.

  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%, but the description adds the critical constraint that at least one of 'paths' or 'data' must be provided, and clarifies the two modes (files vs MIME data). This goes beyond the baseline by preventing invalid invocations.

  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?

  States a specific action (drop) on a specific resource (files or MIME-typed data) onto an element, clearly distinguishing from siblings like browser_file_upload (upload via input) and browser_drag (drag within page). The wording 'as if dragged from outside the page' reinforces its unique scope.

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

  Usage Guidelines3/5

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

  The description implies usage for external data drops but never explicitly contrasts it with alternatives like browser_file_upload or browser_drag, nor mentions when NOT to use it. The sibling list provides context but the description itself offers no routing guidance.

  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/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 covered. The description adds the behavioral fact of going back in history, but does not elaborate on side effects (e.g., losing form input, behavior when no history exists). With annotations present, a mid-range score 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?

  A single, front-loaded sentence with zero redundancy. Every word serves a purpose, making it highly efficient and easy to parse.

  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 no-parameter tool with clear annotations, the description is sufficient for most cases. However, it lacks any mention of edge-case behavior (e.g., when there is no previous page), which could be useful, though not critical given the simplicity.

  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 semantic weight. The description does not need to add parameter details, and the baseline for no parameters is 4. No additional parameter information is necessary.

  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 ('go back') and resource ('previous page in the history'), clearly distinguishing this from navigation to a new URL (browser_navigate) and other browser actions. The purpose is immediately apparent.

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

  Usage Guidelines3/5

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

  The description implies usage for moving backward in browsing history, but it does not explicitly state when to use this over alternatives or mention any exclusions. Simple and self-evident, yet lacking explicit guidance.

  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.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already covered. The description adds behavioral context beyond annotations by explaining that the tool can return either full details or a single part, and that the number originates from browser_network_requests. This informs the agent about the tool's flexibility and input source, which is valuable. It does not contradict annotations and enriches the behavioral understanding.

  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 no filler. The core functionality is stated upfront, and the second sentence provides the necessary pointer to the sibling tool. Every word earns its place, making it highly efficient and easy to parse.

  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, a complete schema, and annotations covering safety (read-only, non-destructive), the description is fully adequate. It explains what is returned (full details or a part), how to select the request (using the number from browser_network_requests), and implicitly that output can be text or saved to a file (via filename parameter, though not stated in description, it's in schema). No critical information is missing 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% — every parameter (part, index, filename) has a detailed description in the schema. The description does not add significant new meaning beyond the schema; it merely restates the source of the index and omits the filename behavior (which is already described in the schema). With full schema coverage, a baseline of 3 is appropriate; the description adds marginal value.

  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 function: 'Returns full details (headers and body) of a single network request, or a single part if `part` is set.' It explicitly names the resource (a single network request) and the verb, and distinguishes from the sibling browser_network_requests by telling the agent to 'Use the number from browser_network_requests.' This leaves no ambiguity about what the tool does or how to identify the target request.

  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 gives clear usage context: you must first obtain a request number from browser_network_requests, then pass it as the index. This implicitly tells the agent when to use this tool — after listing requests, to get detailed data for a specific one. It does not explicitly enumerate alternatives or when not to use it, but the relationship to the sibling is clear and the parameter `part` is self-explained in the schema.

  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/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: the list is 'numbered' and scoped 'since loading the page,' which affects how results should be interpreted and how the agent should proceed. It does not disclose every detail, but given the annotations, the added context is meaningfully 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 with zero wasted words. The core action is front-loaded, and the sibling reference is placed immediately after. Every sentence 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 read-only listing tool with full schema coverage and safety annotations, the description is complete. An agent knows what it returns, how the list is numbered, and which sibling to use next. No critical behavioral or operational information 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?

  Schema description coverage is 100%, so the schema already fully documents filter, static, and filename. The description does not add any parameter-level meaning, but it does not need to because the schema carries the burden. This is the appropriate 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 uses a specific verb and resource: 'Returns a numbered list of network requests since loading the page.' It also distinguishes itself from the sibling tool browser_network_request by noting that you should use that tool to get full details. This makes the tool's purpose and relationship to its sibling immediately clear.

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

  Usage Guidelines5/5

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

  The description explicitly states the workflow: call this tool to get a numbered list, then call browser_network_request with the number for full details. This is a clear alternative/usage instruction that tells an agent exactly when to use this tool versus a sibling.

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

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

  While annotations already declare readOnlyHint=true and destructiveHint=false, the description adds a unique behavioral trait: the screenshot cannot be used as a basis for actions. This goes beyond the safety profile, clarifying the utility of the output. It doesn't contradict any 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 with zero fluff. The primary action is front-loaded, and the crucial caveat about not using the screenshot for actions is placed second. Every word earns its place; nothing is redundant.

  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 tool with a rich, fully-documented schema, the description covers all essential context: what it does, when not to use it, and a key limitation. No output schema exists, so return values need not be explained. The description is complete for an agent to call it correctly without further guidance.

  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 detailed descriptions for all six parameters (type, scale, target, element, filename, fullPage). The tool description adds no parameter-specific meaning beyond the schema, so based on the high schema coverage, the baseline 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 states a specific action ('Take a screenshot of the current page') on a clear resource, and explicitly differentiates it from browser_snapshot by noting the latter is for actions. This unambiguously distinguishes the tool from its siblings without needing the schema.

  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 provides an explicit exclusion: 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This names the alternative (browser_snapshot) and the condition under which to use it (when actions are needed), fulfilling the criterion of explicit when-to-use vs alternatives.

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