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

No annotations are present, so the description carries the full burden. It transparently states the tool returns info and pre-filled URLs, implies a read-only, non-mutating nature, and explains the community-contribution context. It does not explicitly rule out side effects, but nothing suggests any, and the description is honest about its purpose and output.

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

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

The description is a single well-structured paragraph that front-loads the core purpose, then provides actionable usage criteria and parameter mapping. Every sentence earns its place; there is no fluff or repetition. It is detailed but appropriately sized for the tool's complexity.

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

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

The tool has no output schema, so the description must explain what it returns and how to use it. It does: 'Returns Browser MCP info and pre-filled URLs' and 'offer the returned submit_url to the user'. Combined with the thorough usage triggers and parameter guidance, an agent has everything needed to call it correctly and handle the result.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds meaningful context: it explains how title and body are URL-encoded into the submit link, elaborates the intent enum values with examples ('wish' = feature request, 'bug' = something broken), and clarifies the optionality and default for intent. This goes beyond the schema's raw definitions.

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

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 ('Browser MCP info and pre-filled URLs'), and clarifies it is for feedback submission. It clearly differentiates from all sibling browser manipulation tools by its unique informational/feedback role, making it unmistakable.

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

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

The description gives explicit, enumerated triggers ('Call this PROACTIVELY whenever...') with concrete user-language examples and maps them to the intent parameter. It also instructs what to do with the output ('offer the returned submit_url'), providing complete when-to-use guidance without needing to reference alternatives.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the visible side effect (overlay dialog), the ability to include input fields, and the return of user responses. However, it does not mention that the tool likely blocks or waits until the user responds or the timeout elapses, which is important behavioral context for an automation agent.

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

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

The description is three concise sentences with no filler. The core behavior is front-loaded, useful examples follow, and the return behavior is stated briefly. Every sentence earns its place.

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

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

The tool has four parameters and no output schema, and the description covers the main interaction and return value. However, the return is only described as 'user responses' without clarifying the shape (e.g., object keyed by field names), and the waiting/timeout behavior is absent. For a blocking interactive tool, this is adequate but incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds minimal value by mentioning input fields and returning responses, but it does not provide extra semantic depth such as example values or the response shape, 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.

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

The description clearly identifies a specific action: showing an overlay dialog to request user action or information, with concrete examples (credentials, 2FA, CAPTCHA, OAuth consent). It is not a tautology and goes beyond the tool name, though it does not explicitly differentiate itself from sibling tools like browser_handle_dialog or browser_solve_captcha.

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

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

The description gives a clear sense of when to use the tool: whenever the agent needs the user to perform an action or supply information. However, it offers no explicit exclusions or alternatives, which matters given overlapping siblings like browser_solve_captcha and browser_handle_dialog; the CAPTCHA example could confuse an agent into choosing this over an automated alternative.

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

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

With no annotations, the description carries the behavioral burden and it does well by disclosing auto-scroll behavior, real mouse events, and compatibility with Angular/React SPAs and CSP-strict sites. It does omit details like handling of multiple selector matches or post-click waiting, but the disclosed behavior is meaningful.

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

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

Two dense sentences front-load the purpose and then convey selector syntax, behavioral traits, and compatibility examples with no filler. Every clause contributes to correct usage.

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

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

For a single-parameter click tool with no output schema, the description is nearly complete: it tells the agent what selector syntax to use, that scrolling is automatic, and how the event is dispatched. It could be slightly more complete by noting what happens after the click (e.g., waiting or return value), but this is a minor gap.

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

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

The schema already covers the selector parameter at 100%, so the baseline is 3. The description adds value by giving concrete selector examples (#my-button, a.btn-primary, button:text(Get started)) and clarifying that CSS and text-based formats are supported, which aids correct parameter construction beyond the schema's description.

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

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

The description begins with a specific verb and resource — 'Click an element on the page' — and further specifies CSS/text selector support and worded examples. This clearly distinguishes it from sibling tools like browser_double_click and browser_click_xy, which involve different actions or coordinate-based clicks.

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

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

It gives useful context such as auto-scrolling and real mouse events for SPAs/CSP sites, which implies when the tool is valuable, but it does not explicitly state when to use this tool instead of browser_double_click, browser_hover, or browser_click_xy. No exclusions or when-not-to-use guidance is provided.

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

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

With no annotations provided, the description carries the full disclosure burden. It reveals two important behavioral traits: 'raw viewport coordinates' (meaning no scrolling or element lookup) and 'fully trusted mouse events' (which bypass some event trust restrictions). It also warns about unusual cases like Azure portal dialogs, Knockout-bound divs, and canvas UIs. However, it does not mention edge cases such as coordinates outside the viewport or page movement after a screenshot.

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

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

The description is three sentences with zero filler. It front-loads the 'ESCAPE HATCH' label, then gives a crisp when-to-use and how-to workflow. Every sentence contributes purpose, usage context, or procedural guidance.

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

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

For a two-parameter tool with no output schema, this description is complete. It covers what the tool does, when to use it, how to get coordinates, and how to combine it with browser_screenshot. The omission of rare edge cases is acceptable because the tool is intentionally simple and the use case is clearly scoped.

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

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

The input schema already has 100% coverage for both x and y, so the baseline is 3. The description adds value beyond the schema by explaining how to derive coordinates—'take a screenshot, read the button's position, click its center'—and explicitly emphasizing CSS pixel units and the viewport origin. This practical guidance helps the agent invoke the tool with meaningful inputs.

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

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

The description clearly identifies the tool as an escape hatch that clicks at raw viewport coordinates in CSS pixels with fully trusted mouse events. It explicitly contrasts this with selector-based strategies, naming the exact resource and action, so an agent can distinguish it from browser_click and other sibling click tools.

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

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

The description explicitly states when to use it: 'when a visible button resists every selector strategy' and provides a concrete workflow with browser_screenshot. It doesn't name the preferred alternative (browser_click) explicitly, but the 'escape hatch' framing and 'resists every selector strategy' strongly imply the fallback nature, which is enough guidance without being fully explicit.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds one important behavior: session ownership limits which tabs can be closed. However, it does not mention what happens on success or failure, whether closing is irreversible, or whether the tab's resources are also released. For a destructive action, some additional context would be valuable.

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

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

Two short sentences with no filler. The core action is front-loaded, and the session ownership limitation is stated as a separate, important constraint. Every word earns its place.

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

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

This is a simple single-parameter tool with no output schema. The description covers what the tool does and the key limitation an agent must respect. It is mostly complete for a focused close operation, though it could briefly note what happens when the tab ID is invalid or stale.

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

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

Schema description coverage is 100%, and the tab_id parameter is already described clearly as 'Tab ID to close (get from browser_list_tabs)'. The description reinforces the parameter's role but does not add significant meaning beyond the schema. Baseline 3 applies.

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

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

The description states a specific action ('Close'), a specific resource ('a browser tab'), and the method ('by ID'). It clearly distinguishes this tool from siblings like browser_switch_tab and browser_list_tabs, so an agent can immediately understand its role.

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

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

The description makes the tool's purpose obvious: call it when a specific tab should be closed. It also provides a meaningful constraint: only tabs owned by the current session can be closed. It does not explicitly name alternatives or describe when not to use it, but the narrow scope makes the usage context clear.

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

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

With no annotations to lean on, the description does extra work by disclosing a side effect ('Installs a lightweight interceptor on first call') and the bounded nature of the result ('last N console messages'). This goes beyond a bare read-operation description, though it could clarify interceptor persistence or message format.

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

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

Two tight sentences with no filler. The primary action and resource appear first, followed by a critical behavioral caveat and a clear output summary.

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

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

For a one-optional-parameter, no-output-schema tool, the description covers the essential behaviors: what is returned, how many messages, and the install-on-first-call side effect. Minor gaps like exact message object shape or lifecycle of the interceptor are not blocking for correct invocation.

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

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

The schema already documents the single 'count' parameter with default and meaning. The description adds no new parameter-level details, but that is acceptable because schema coverage is 100%, so it does not need to compensate for missing documentation.

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

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

The description uses the specific verb 'Get' with a clear resource: console.log/warn/error messages from the page. It is instantly distinguishable from all sibling browser tools, none of which target console messages.

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

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 recent page console messages are needed. However, it gives no explicit when-not-to-use conditions or alternatives, relying on the agent to infer the use case from the tool's purpose.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is heuristic-based, how it locates close affordances, the effect of scope values (non_critical preserves form inputs, aggressive dismisses everything), and that it returns a list of what was dismissed. This is strong transparency, though it could have noted potential edge cases like shadow DOM or unclosable overlays.

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

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

The description is compact and front-loaded: purpose, heuristic mechanism, usage examples, and return value are each covered in a few tight sentences. There is no filler or redundant restatement.

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

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

Given no annotations and no output schema, the description covers the key decision factors: what the tool does, when to use it, how it behaves heuristically, and what it returns. The main gap is not explicitly excluding native JavaScript dialogs, which could cause confusion with the sibling browser_handle_dialog, but overall an agent can invoke it correctly.

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

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 and the schema already explains both scope and max_passes. The description adds useful context for max_passes ('some overlays reveal others when closed') and reinforces the scope trade-off, but it does not carry the parameter-documentation burden.

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

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

States a specific verb and resource: dismiss visible popups, modals, tooltips, banners, and 'Are you sure?'-style overlays in one call. The heuristic details (finding close affordances via aria-label, text, or ×) distinguish it from related siblings like browser_handle_dialog, which handles native dialogs.

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

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

Provides clear usage context: 'Use when a flow is interrupted by unexpected dialogs' with concrete examples such as cookie banners, onboarding tooltips, and Meta Ads draft-confirm prompts. It does not explicitly state when not to use it or mention alternatives for native dialogs, but the described conditions are unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden and does well by explaining that this is a 'true' double-click involving two trusted press/release pairs and escalating clickCount. This adds meaningful detail beyond the tool name, though it does not mention potential side effects or error behavior.

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

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

The description is two sentences long, front-loads the primary action and behavioral detail, then immediately gives a concrete usage scenario. Every sentence earns its place with no redundancy or filler.

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

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

For a simple tool with one well-documented parameter and no output schema, the description provides everything an agent needs to decide when to use it and what it will do. The example and contrast with single-click behavior make the context complete.

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

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

The input schema already covers the only parameter, selector, with 'CSS or text selector', so schema coverage is 100%. The description adds no additional semantic detail about the selector format, so 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.

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

The description clearly states the tool performs a genuine double-click on an element, using specific verbs and resource ('double-click on an element'). It distinguishes itself from sibling tools like browser_click and browser_right_click by describing the internal behavior of two trusted press/release pairs with escalating clickCount.

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

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

The description explicitly says when to use this tool: for open-item actions where two single clicks would trigger inline-rename instead, with the concrete OWA month view example. This effectively routes the agent to this tool rather than using browser_click twice or another click variant.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that strategy 2 intercepts the native OS file-chooser without showing the dialog, and it states the file constraints (regular files inside working directory, refusal of folders/symlinks/hardlinks pointing outside). It could mention failure behavior when both strategies fail, but it covers key traits well.

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

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

The description is somewhat long but every sentence contributes value, and the structure is logical (purpose, strategy 1, strategy 2, constraints). It is front-loaded with the primary usage, and the details are organized in a readable list format.

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

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

Given the absence of annotations and output schema, the description is quite complete. It covers the tool's purpose, usage, both strategies, and constraints. It omits only minor details like error handling or preconditions (e.g., active browser session), which are implied by the sibling toolset and not critical for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema by explaining the selector's dual role (drop-zone target or button opening the dialog) and by clarifying that file paths must be regular files inside the working directory. This is additional context the schema does not provide.

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

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

The description clearly states the tool's purpose: uploading a file when browser_upload_file fails. It also distinguishes it from the sibling browser_upload_file and details two distinct strategies, leaving 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.

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

The description explicitly specifies when to use this tool ('when browser_upload_file fails') and provides a clear decision path between the two strategies, including the condition for each. It also names the alternative tool, making usage guidance unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It discloses the handler wrapping behavior (which causes top-level return to fail) and the alias acceptance. This gives useful insight into how the tool processes input, though it does not warn about potential side effects or security implications of executing arbitrary JavaScript.

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

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

The description is a single, focused sentence that front-loads the core purpose and then immediately addresses the most critical usage pitfalls. Every word earns its place, with no fluff or redundancy.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential aspects: what it does, the parameter name, the expression requirement, and the wrapping behavior. It does not specify the return value, but that is not necessary given the lack of an output schema. The description is sufficient for correct invocation.

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

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

The schema already describes the code parameter as an expression with IIFE guidance, achieving 100% coverage. The description adds value by clarifying the alias (script) and explaining the consequence of using top-level return, which is not in the schema. This extra semantic detail helps the agent avoid common mistakes.

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

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

The description clearly states the tool executes JavaScript in the current page, with a specific verb and resource. It distinguishes itself from siblings like browser_fetch or browser_console_logs by its purpose, and the prominent IMPORTANT note adds specificity.

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

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

The description provides critical usage instructions: the correct parameter name (code, not script) and the requirement that the input be an expression, not statements. It also warns about the top-level return error. However, it does not explicitly state when to use this tool versus alternatives like browser_fetch or browser_evaluate (if such existed), so it lacks 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.

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

No annotations are provided, so the description carries the full burden. It discloses the scrolling behavior, the auto-detection of the scrollable ancestor, the deduplication of rows, and the reached_end flag. It also explains the underlying virtualisation problem. It doesn't mention side effects like page scroll position changes or network requests, but for a read-only extraction tool the disclosed behavior is substantial and accurate.

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

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

The description is a single dense paragraph that front-loads the core behavior and the when-to-use guidance. It's longer than ideal but every sentence earns its place: the virtualisation explanation justifies the tool's existence, and the selector guidance is actionable. The structure could be improved with a short 'When to use' lead-in, but it's well-organized.

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

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

For a tool with 6 parameters, no annotations, and no output schema, the description covers the core scenario well: what it does, when to use it, what to pass, and what you get back (deduplicated rows + reached_end). It doesn't describe the exact return format or error cases (e.g., what happens if the selector matches nothing), but the description is complete enough for an agent to select and invoke the tool correctly in the common case.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds context for the key parameter (selector) with examples and explains the auto-detection behavior for container. However, it doesn't add much beyond the schema for wait_ms, max_rows, scroll_step, and stable_rounds, which are already well-described. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Read EVERY row'), a resource (long/virtualised lists), and the mechanism (scrolling until no new rows appear). It explicitly distinguishes itself from browser_get_page_content, which is the key sibling it competes with. The examples (mail lists, invoice tables, search results) make the target use case unmistakable.

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

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

The description explicitly says 'Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport' and explains why (virtualised UIs keep only ~7 rows in the DOM). This is a clear when-to-use directive with a named alternative. It also tells the user what to pass (CSS selector of one repeating row) and what to expect (deduplicated rows plus reached_end).

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool navigates to a settings page and reads a token, but it does not mention side effects like leaving the current page, authentication requirements, or behavior when the provider is not supported or not logged in.

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

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

The description is a single concise sentence with no filler. The action and purpose are front-loaded, and it earns its place by stating both what happens and why.

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

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

With no output schema, the description should clarify what the tool returns or whether it only navigates and leaves reading to the agent. It also omits prerequisites like authentication. For a tool that extracts a token, this is a meaningful gap.

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

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

The schema already fully describes the single 'provider' parameter with 100% coverage. The description adds minor context by tying the provider to its API settings page, but it does not significantly extend the schema's meaning. Baseline 3 is appropriate.

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

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

The description states a specific action ('navigate to a provider's API settings page') and the intended outcome ('read its API token from the page'). This clearly distinguishes it from generic sibling tools like browser_navigate, though it could be more explicit about whether the token is returned directly or just made available on the page.

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

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

There is no guidance about when to use this tool versus alternatives such as browser_navigate, browser_get_page_content, or browser_fetch. The intended use is inferable from the name and description, but no conditions, prerequisites, 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.

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

With no annotations provided, the description carries the full disclosure burden. It usefully discloses that the request runs from the extension background and is exempt from CORS/CSP restrictions. However, it does not mention response format, error behavior, authentication needs, or potential side effects of methods like POST/PUT, which would add meaningful behavioral context.

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

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

Three sentences with no filler. The first sentence states the core behavior and the CORS exemption, the second gives the usage condition, and the third provides practical examples. Every sentence earns its place.

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

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

The schema fully documents the four parameters, and the description supplies the essential selection context. The main gap is the lack of return-value or error-handling details, especially since there is no output schema, but for a straightforward HTTP fetch tool the expected response is largely implied.

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

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

Schema description coverage is 100%, so the structured schema already documents url, body, method, and headers. The description adds no additional parameter-level meaning, but the fields are self-explanatory and the baseline of 3 applies because the schema handles parameter documentation.

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

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

The description states a specific verb and resource: 'Make an HTTP request from the extension background'. It also highlights the key differentiator, 'NOT subject to CORS', which distinguishes it from page-context fetch and other browser tools. It does not explicitly name a sibling alternative, but the purpose is clear and actionable.

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

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

The description gives explicit usage guidance: use this when page-context fetch would be blocked by CORS or CSP, and provides concrete examples like Google, Stripe, and Slack APIs. It clearly identifies the condition that selects this tool, even though it does not list alternative tools or exclusion cases explicitly.

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

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

With no annotations, the description carries the full burden and it delivers meaningful behavior: auto-scrolling, focusing the element, and working on CSP-strict sites via the Chrome Debugger API. It doesn't mention potential side effects like overwriting existing values or triggering events, but the disclosed traits go well beyond a minimal description.

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

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

The description is efficient: a one-line purpose, two capability notes, and a two-item routing sentence. Every sentence earns its place, and the core action is front-loaded before alternatives.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential use context: why it exists, what behaviors it performs, technical limitations it handles (CSP), and alternatives for edge cases. Minor gaps like error behavior or event triggering are not critical for a fill operation, so this is almost fully complete.

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

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

Schema coverage is 100%, with both 'selector' and 'value' already documented. The description repeats the selectors info but adds little beyond what the schema states. Baseline 3 applies because the schema does the heavy lifting and the description does not materially enhance parameter understanding.

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

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

The description opens with a clear verb and resource: 'Fill a form input field with a value.' It explicitly differentiates from nearby siblings by naming browser_set_date for date inputs and browser_set_combobox for autocomplete/combobox controls, so an agent can tell them apart without opening schemas.

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

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

The description provides explicit routing: 'For date inputs use browser_set_date, for autocomplete/combobox use browser_set_combobox.' It also clarifies the accepted selector types (CSS and text-based), helping the agent decide when this tool is appropriate. This is direct when-to-use guidance with named alternatives.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the constraint that the site must be open in a tab, which is valuable, but doesn't disclose the return format (e.g., JSON structure) or potential errors beyond refusal. 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.

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

The description is two sentences long with no fluff. The core action and constraint are front-loaded, and the prerequisite is placed second. Every word contributes to understanding.

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

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

For a single-parameter read operation with no output schema, the description covers the essential context: what it does, the prerequisite, and the limitation. Minor gaps like error handling or return format are not critical given the low complexity.

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

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

The schema description for the 'domain' parameter is already detailed, including the example and the note that it must match an open tab. The description reiterates the domain scope but adds little new semantic meaning beyond the schema, so a baseline 3 is appropriate given 100% coverage.

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

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

The description specifies the verb 'get' and the resource 'cookies for a site', and clearly indicates the domain scope (site itself, parent domain, or subdomain). However, it doesn't explicitly contrast with the sibling browser_set_cookies, which could cause slight ambiguity, though the action is distinct enough.

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

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

The description explicitly instructs to navigate to the site first and warns that cookies for non-open sites are refused. This provides clear conditions for use and implies when it should not be used, effectively guiding the agent on prerequisites.

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

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

With no annotations, the description carries the behavioral burden. 'Read' communicates a non-mutating operation and 'from the current page' gives scope, but the description does not disclose return format, behavior for missing keys, or origin/security constraints. For a simple getter this is acceptable but not comprehensive.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, and the optional parameter behavior is explained immediately and clearly.

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

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

For a tool with one optional parameter, no output schema, and no annotations, the description covers selection and invocation adequately. The only notable gap is the lack of explicit mention of return shape or missing-key behavior, but overall it is sufficiently complete for a simple localStorage reader.

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

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

Schema description coverage is 100%, and the schema already documents the key parameter exactly as the description does. The description adds no new meaning beyond the schema, so it meets the baseline but does not exceed it.

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

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

The description states a clear verb and resource: 'Read localStorage from the current page.' It is immediately distinguishable from sibling browser_set_local_storage because the verb 'Read' directly contrasts with 'set.' The optional-key behavior is also stated precisely.

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

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

The description provides clear context: reading from the current page, with 'Pass key for a specific value, or omit for all.' It does not explicitly name alternatives or exclusion criteria, but the read-vs-set distinction is obvious from the sibling set_local_storage tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' reasonably signals a non-destructive read, and the use-case context adds some value. However, it does not disclose the crucial behavioral detail of whether 'get' returns a tab reference for subsequent use or also activates/switches to the tab — a meaningful ambiguity given browser_switch_tab exists as a sibling.

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

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

A single sentence with the core action front-loaded ('Get the most recently opened tab') and the use case appended as a tight parenthetical. Every word earns its place; there is no filler, repetition, or schema echo.

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

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

For a zero-parameter tool this is mostly adequate — it covers what the tool does and when to use it. But with no output schema and no annotations, the description is the sole source of the return contract, and it leaves unspecified whether the result is a tab ID, a tab handle, and whether the active tab changes. Some guidance relating it to browser_switch_tab or browser_list_tabs would close the gap.

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

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

The tool has zero parameters, so the baseline is 4 — there is nothing the description needs to explain about inputs. The description adds useful context about what the returned entity represents (the most recently opened tab) and when the call is relevant, which is more than the empty input schema alone could convey.

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

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

The description states a specific verb and resource — 'Get the most recently opened tab' — and adds a concrete use case (links opening new tabs, OAuth popups). It is unambiguous about what is retrieved. However, it does not explicitly differentiate from closely related siblings like browser_switch_tab or browser_list_tabs, leaving the agent to infer the distinction.

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

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

The parenthetical gives explicit usage context: 'useful after clicking links that open new tabs, OAuth popups, etc.' This tells the agent the trigger condition for choosing this tool. It stops short of naming alternatives or exclusions, such as pointing to browser_switch_tab for already-known tabs or browser_list_tabs for enumerating tabs, so it lacks the when-not guidance of a 5.

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

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

With no annotations, the description carries the full burden. It transparently discloses the 30000-character cap, the truncation flag and total_chars field, and the fact that truncation is never silently mistaken for a full page. It also mentions the selector's failure behavior indirectly via the schema, but the description itself does not repeat that. It lacks details on error handling (e.g., page not loaded) but covers the most important behavioral quirk.

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

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

Two sentences, front-loaded with the primary purpose, then a targeted usage tip, then a crucial behavioral note. No fluff, every clause earns its place. The structure leads with the core action and immediately addresses the most common pitfall (large pages).

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

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 ones, the description covers the essential usage scenarios, the truncation behavior, and the selector's purpose. The output schema is absent, but the description explains what the response includes (text/HTML, truncation metadata), so an agent has enough to call it correctly and interpret results.

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

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, but the description adds genuine value: it explains why the selector exists (to handle very large pages) and gives a concrete size example, and it clarifies the truncation semantics for max_chars. This goes beyond what the schema states, making the tool easier to use correctly.

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

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

States a specific verb ('Get') and a precise resource ('content of the current page as text or HTML'), and it is immediately distinguishable from sibling tools like browser_screenshot (image capture), browser_extract_list (structured data), or browser_fetch (network request). No ambiguity about what this tool does.

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

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

Provides clear contextual guidance on when to use the selector parameter ('read one part of a large page instead of all of it') and explains the rationale with a concrete example (big logged-in app HTML exceeding a million characters). It does not explicitly mention when not to use this tool or name alternatives, but the context implies it is the default for reading page content.

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

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

With no annotations, the description carries the behavior-disclosure burden. It discloses the arming-then-returning mode, the blocking wait mode, and the tab-freeze rationale. It does not state what happens if no dialog appears before timeout or whether a result is returned, but these are minor for this tool.

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

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

Two sentences, front-loaded with the core operation and followed by high-value timing guidance. No filler or repetition of schema details.

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

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

For a small, well-schematized tool, the description is largely complete: it explains what 'arm' means, the required call order, and the wait mode. Minor omissions—no-dialog timeout behavior and return value—keep it from a 5.

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

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

The input schema already covers all 4 parameters with 100% description coverage, so the baseline is 3. The description adds a useful temporal constraint for wait (only when the dialog is already opening) but does not materially expand on text, action, or timeout beyond the schema.

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

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

The description uses a specific verb ('Arm...') and identifies the exact resource (next JavaScript alert/confirm/prompt on the active tab). It also states the immediate-return behavior, making it clearly distinct from sibling browser tools like browser_click or browser_ask_user.

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

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

It gives explicit sequencing guidance: call before the click that opens the dialog, because the dialog freezes the tab and prevents further clicks. It also restricts wait=true to the case where the dialog is already opening, which is a clear when-not condition.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does explain the visible effect of hovering and mentions selector support, but it does not disclose what happens if the selector matches nothing, whether the element is scrolled into view, or what the tool returns. These are notable gaps, though the core behavior is clear.

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

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

Two concise sentences deliver the action, purpose, and selector support without unnecessary detail. The primary verb and intended use are front-loaded, making it easy for an agent to scan and understand.

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

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

For a simple two-parameter tool with no output schema, the description combined with the schema is largely sufficient. It explains what the tool does and what the elements are, though a bit more detail about error behavior or post-hover state would make it fully complete.

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

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

The schema already documents both parameters with 100% coverage: `selector` as 'CSS or text selector' and `duration` as 'How long to hold hover in ms'. The description mostly restates the selector information already present, and it adds no additional nuance about the duration parameter or how selectors are resolved beyond what the schema provides.

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

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

The description uses a specific verb ('Hover') with a clear resource ('an element') and states the intended outcomes (`trigger tooltips, dropdown menus, or hover states`). This clearly differentiates it from sibling tools like browser_click, browser_double_click, and browser_right_click, which involve active input rather than hovering.

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

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

The phrase 'to trigger tooltips, dropdown menus, or hover states' gives clear contextual guidance for when this tool should be used. It does not explicitly mention when not to use it or name alternative tools, but the hover-specific purpose is sufficient to guide selection among the browser interaction siblings.

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

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

No annotations are present, so the description carries the full burden. It discloses the output content (URLs and indices) and scope (current page), but it does not mention whether nested frames are included, ordering behavior, or that the indices are meant for later frame selection.

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

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

One concise sentence with no filler. The core action, resource, and output fields are immediately available.

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

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

For a zero-parameter listing tool, this is mostly complete: it says what is listed and what is returned. Minor gaps remain around nested frame handling and the relationship to browser_select_frame, but they do not seriously impair usability.

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

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

The tool has zero parameters and the schema is empty, so there is nothing to explain. The baseline of 4 applies since no parameter semantics are needed.

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

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

The description states a specific verb ('List'), a specific resource ('frames (iframes) in the current page'), and the returned data ('URLs and indices'). This clearly distinguishes it from sibling tools like browser_select_frame and browser_list_tabs.

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

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

The description implies this is a discovery step on the current page, but it does not explicitly say when to use it versus alternatives such as browser_select_frame. No exclusions or direct usage conditions are provided.

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

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

Without annotations, the description bears the full burden. It implies a read-only operation but does not specify scope (e.g., all windows or current window) or any limitations. Basic but adequate.

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

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

The description is a single, front-loaded sentence with no unnecessary words. Every word serves a purpose.

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

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

For a simple tool with no parameters, the description covers the output. However, it does not specify the structure of the returned data (e.g., array of objects), which would be helpful given the absence of an output schema.

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

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

With zero parameters, the schema provides no details. The description adds meaning by specifying the output (URLs and titles), which is valuable beyond the empty schema.

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

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

The description 'List all open browser tabs with their URLs and titles' clearly states the verb (list), resource (browser tabs), and output (URLs and titles), distinguishing it from sibling tools like browser_switch_tab or browser_close_tab.

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

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_switch_tab or browser_get_new_tab. The description only states what it does.

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

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

Discloses default behavior (reuse tab) and a key behavioral trait (no tab spam). However, with no annotations, it could further explain side effects like page load events or dialog handling.

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

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

Two short, front-loaded sentences with no unnecessary words. Every sentence contributes to understanding what the tool does and how to use it.

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

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

Covers the core functionality and parameter usage adequately. Given the simplicity (2 params, no output schema), missing details are minor; however, it could mention prerequisites like page load state.

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

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

Adds value beyond the schema by explaining the rationale for 'new_tab' (keep current page open) and the default reuse behavior. The schema already describes both parameters, so the description enhances context.

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

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

Clearly states the action ('Navigate the active browser tab to a URL') and the resource ('URL'). It is obvious among siblings, though no explicit differentiation is provided.

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

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

Provides guidance on when to use the default behavior vs. 'new_tab=true' ('Reuses the current tab by default ... Pass new_tab=true only when you need to keep the current page open'). Lacks explicit comparison to sibling tools like browser_get_new_tab.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It states that it presses a key and supports modifier keys, which is useful, but it does not disclose that the press targets the currently focused element, whether full keyboard events are dispatched, or what happens with invalid keys.

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

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

The description is two sentences with no fluff. The action and examples are front-loaded, followed by use cases and modifier support, so every sentence earns its place.

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

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

For a simple keyboard tool with full schema coverage, the description is mostly adequate, covering key examples and modifier keys. However, with no annotations and no output schema, it omits important invocation context such as the need to have the right element focused and what the tool returns or does on failure.

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

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

Schema description coverage is 100%, so the schema already documents all parameters clearly. The description only repeats modifier support already visible in the schema and adds no deeper parameter semantics.

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

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

The description opens with a specific verb and object: 'Press a keyboard key', then lists concrete examples and use cases. This clearly distinguishes it from the many mouse-based sibling tools like browser_click, browser_hover, and browser_double_click.

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

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

The description gives clear context for when to use it: submitting forms, navigating dropdowns, and closing dialogs. It does not explicitly state when not to use it or name alternative tools, but the use cases are enough to guide an agent.

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

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

Annotations are absent, so the description carries full responsibility. It discloses it is read-only, cheap, safe, never sends anything by itself, and explains its internal checks (extension version, multiple extensions, optional npm check). This is thorough and leaves no behavioral surprises.

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

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

The description is lengthy but dense and front-loaded with the core instruction (call automatically when blocked). Every sentence adds value: it explains the diagnostic logic, the optional environment variable, and the expected output. It could be trimmed slightly, but the structure is logical and information-dense.

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

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

No output schema is provided, so the description must explain the return value. It does: returns a verdict, concrete fix steps, and a pre-filled GitHub issue link. It also covers the optional check toggle and the multi-extension edge case. Everything an agent needs to decide when to call and what to expect is present.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context about the overall flow and mentions the 'kind' enum implicitly (blocked, broken, etc.) but does not add per-parameter semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific purpose: self-diagnosis + feedback for when Browser MCP itself fails. It clearly distinguishes from sibling tools by focusing on reporting and diagnosing the MCP infrastructure, not on browser actions. The verb 'provide_feedback' combined with the description's explanation of diagnosis makes it unambiguous.

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

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

Provides explicit triggers: call automatically when a tool errors, times out, misbehaves, extension won't connect, capability missing, or before saying 'cannot do X'. Also clarifies it should be called without asking the user, and notes it is safe to call speculatively. No alternative tool is mentioned, but the conditions are exhaustive and actionable.

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

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

No annotations are provided, so the description bears the full burden. It discloses the core behavior (force-detach and re-attach) and the symptom it addresses. However, it does not mention any side effects, such as whether the page state is preserved, whether the tab reloads, or what the return value may be. The description gives enough to invoke it but not full behavioral context.

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

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

The description is a single, well-structured sentence that front-loads the action ('RECOVERY: Force-detach...') and then provides the triggering condition and benefit. It is concise, with no wasted words. Every clause earns its place, conveying purpose, usage, and the contrast with an alternative.

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

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

For a zero-parameter utility tool with no output schema, the description adequately covers the 'what' and 'when'. It explains the specific failure scenario and why this tool is preferred. However, it does not describe what happens after execution (e.g., success signal, page state), which is a minor gap but not critical for a recovery tool that likely returns a simple status. Overall it is complete enough for an agent to decide and invoke.

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

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

The tool has zero parameters, so the schema provides nothing to explain. The baseline for 0 params is 4. The description appropriately avoids adding parameter-related text since there are none, and it adds no irrelevant information. It fully satisfies the requirement for parameter semantics.

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

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

The description states a specific verb ('Force-detach and re-attach'), a specific resource ('Chrome debugger'), and a scope ('current tab'). It also called out as a recovery operation, clearly distinguishing it from the many interactive sibling tools. An agent can immediately understand its purpose without opening the schema.

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

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

It explicitly states when to use it: when interactive tools (click/fill/press_key) start timing out or report ghost-attach, while list_tabs still works. It also provides an alternative (faster than reloading the extension), giving clear decision guidance. No ambiguity about the trigger conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool uses trusted CDP mouse events, that it only opens in-page menus (not Chrome's native context menu), and that web apps may render their own menus. This is significant behavioral context beyond the schema. It could add more about side effects (e.g., whether the right-click triggers other events), but the key limitation is clearly stated.

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

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

Two sentences with no wasted words. The core action and purpose are front-loaded, and the critical limitation (native context menu won't open) is stated 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.

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

For a single-parameter tool with no output schema, the description is quite complete. It explains the purpose, the limitation, and the parameter is fully documented in the schema. The only minor gap is that it doesn't describe what happens after the right-click (e.g., whether a menu appears and how the agent should interact with it), but this is not essential for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter (selector) as 'CSS or text selector'. The description doesn't add any additional meaning about the parameter beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't need to compensate.

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

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

The description clearly states the action (right-click an element) and the resource (an element via CSS/text selector), and distinguishes it from the sibling browser_click and browser_double_click by specifying right-click behavior. It also notes the purpose (opening page-level context menus), which adds clarity. However, it doesn't explicitly contrast with browser_click_xy, which is a coordinate-based click, so it's not fully differentiated from all siblings.

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

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

The description gives clear context for when to use this tool: when you need to open page-level context menus, especially in web apps like OWA or Google Docs. It also provides an important exclusion: Chrome's native context menu does not open via CDP, so this tool won't work for that. It doesn't explicitly name alternative tools for native menus, but the guidance is strong enough for an agent to decide when to use it.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses the default return value (base64 PNG), the conditional side effect (saves to disk if path is provided), and the viewport limitation. It does not mention edge cases like file overwriting or page-load timing, but these are minor for a low-complexity tool.

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

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

The description is a single sentence that front-loads the primary action, then packs the return format and optional side effect. No filler or redundant detail. Every word earns its place.

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

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

For a tool with one optional parameter and no output schema, the description is near-complete: it gives the action, result format, and the effect of the only parameter. It omits trivial details like exact PNG encoding or whether the path can be relative, but nothing essential is missing for an agent to invoke it correctly.

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

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

Schema coverage is 100% and the schema already explains the 'path' parameter clearly. The tool description adds meaningful behavior beyond the schema: if path is provided it saves to disk; otherwise it returns base64. This conditional semantics is essential for correct invocation and is not stated in the schema.

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

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'), a clear resource ('the visible area of the current tab'), and distinguishes itself from all siblings by being the only screenshot-related tool. It is unambiguous and immediately understandable.

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

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

The description implies clear usage context: use when you need a visual capture of the current viewport. It explicitly limits scope to 'visible area', which tells the agent this is not a full-page capture. However, it does not name alternative tools or state when not to use it, but no direct alternative exists among siblings.

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

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

No annotations are present, so the description carries the burden of disclosing behavior. It accurately describes the basic scrolling action but does not explain what happens if both selector and pixel coordinates are provided, or how scrolling interacts with the current scroll position. This leaves some behavioral ambiguity, though the core behavior is clear.

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

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

The description is compact, front-loaded with the primary action, and includes only useful additional context. Both sentences earn their place, with no redundant wording or unnecessary detail.

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

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

For a low-complexity tool with optional parameters and no output schema, the description covers the essential invocation scenarios well. It explains both modes and gives a practical use case. The only minor gap is the lack of explicit guidance on parameter precedence, but this is unlikely to be critical for a scrolling action.

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

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

Schema description coverage is 100%, so the input schema already documents each parameter's meaning. The description adds a high-level mapping between 'element' and selector, and 'pixel amount' and x/y, but does not provide additional detail beyond what the schema already contains. A baseline of 3 is appropriate.

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

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

The description states a specific verb ('scroll') and resource ('the page'), and clearly distinguishes two modes: by element or by pixel amount. It also adds a concrete use case ('reaching elements below the fold'), which makes the tool's purpose immediately identifiable among the sibling browser tools.

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

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

The description gives clear usage context by explaining that scrolling is useful for reaching elements below the fold, which tells an agent when this tool is appropriate. It does not explicitly mention alternatives or when not to use it, but the tool's function is distinct enough among the siblings that this is not a major gap.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It says what the tool does but not what side effects executing JavaScript may have, whether the frame context persists for later commands, or what the return value is. The name 'select_frame' also creates ambiguity about whether this is a temporary execution context or a persistent selection.

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

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

Two short, focused sentences with the primary action front-loaded and the prerequisite in the second sentence. No wasted words or redundancy.

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

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

For a simple two-parameter tool, the description plus schema covers the essentials. However, there is no output schema and no annotation safety profile, so the lack of any mention of return behavior or post-conditions leaves a minor but real gap.

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

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

The input schema already fully documents both parameters, including the meaning of frame_index and the default behavior of code. The description adds a useful link to browser_list_frames but does not substantially expand parameter semantics beyond the schema, so the baseline 3 applies.

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

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

The description clearly states a specific action (execute JavaScript), a specific target (a specific iframe), and the selection mechanism (frame index). It distinguishes itself from the generic browser_execute_script sibling by scoping execution to a frame.

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

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

It explicitly instructs the agent to call browser_list_frames first to find the right index, which is a concrete usage prerequisite. It does not enumerate alternatives or when not to use the tool, but the guidance is clear enough for correct invocation.

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

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

With no annotations, the description carries full burden. It discloses the click-wait-click behavior, failure mode (fails loudly with available options), and the edge case for controlled components (landed: null, maybe_landed: true). This is detailed and transparent, though it doesn't mention potential side effects or permissions, which are likely minimal for a browser action.

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

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

The description is a single dense paragraph that front-loads the purpose, then explains the mechanism and alternative in a logical order. No wasted words; every sentence contributes to understanding when and how to use the tool.

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

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

For a tool with no annotations and no output schema, the description covers the essential aspects: purpose, mechanism, edge cases, and alternative routing. It lacks an explicit statement of return value, but mentions 'landed' and 'maybe_landed' as part of the result, which is sufficient given the tool's likely standard return pattern. Overall it's nearly complete for an agent to use correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: for 'option' it details matching priority (exact value, exact text, partial text), aliases (value, label), and failure behavior. For 'wait' it explains the default and purpose, and for 'selector' clarifies it accepts CSS or text selectors. This adds practical value for correct invocation.

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

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

The description clearly states the tool selects an option from a dropdown and explicitly distinguishes native <select> from custom dropdowns, even naming the sibling browser_set_combobox for autocomplete scenarios. This differentiates it from related tools without needing to inspect schemas.

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

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

It provides explicit when-to-use guidance: for dropdown selection, and explicitly says to use browser_set_combobox for autocomplete. It also explains the mechanism for custom dropdowns (click trigger, wait, click option), giving clear operational context.

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

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

With no annotations, the description carries the full transparency burden. It clearly discloses the internal interaction sequence: click, type query, wait for listbox, click option. It also notes configurable waiting behavior and multi-select. Minor omissions like whether existing selections are cleared before setting values keep it from a 5.

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

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

Three tightly worded sentences front-load the core action, then explain the internal flow, multi-select support, and when to use the tool. There is no redundancy or filler.

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

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

The description covers the operation's workflow, multi-select behavior, and the key alternative comparison. All six parameters are fully documented in the schema. The main gap is the absence of return-value or post-condition information, but that is minor for a UI interaction tool with no output schema.

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

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 every parameter fully. The description adds context about multi-select and the lazy-rendering use case, but does not add meaningful parameter semantics beyond what the structured schema provides. Baseline 3 is appropriate.

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

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

The description names a specific verb+resource ('Set value(s) on an autocomplete/combobox input') and explains the exact multi-step flow it automates. It explicitly distinguishes this from browser_select_option, making its purpose and scope immediately clear.

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

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

Usage guidance is explicit: 'Use when browser_select_option fails because options render lazily after typing.' This tells the agent exactly when to choose this tool over the closest sibling, and the multi-select example adds real context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not mention whether existing cookies are overwritten, how defaults like secure or sameSite behave, or whether the cookie persists beyond the current session.

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

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

The description is a single, direct sentence with no filler, front-loading the key action and scope. It is appropriately concise for the primary purpose statement.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description is under-specified. It omits how to use the bulk 'cookies' parameter, the relationship between url and domain, default flag behavior, and any side effects or prerequisites.

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

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

Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-level meaning beyond what the schema provides, which matches the baseline of 3 for full schema coverage.

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

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

The description clearly states the verb 'set', the resource 'cookies', and the scope 'for a domain'. It also explicitly covers both single and bulk operations ('one or more cookies'), which distinguishes it from the sibling browser_get_cookies without needing inference.

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

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_set_local_storage or browser_get_cookies. No prerequisites, timing, or exclusion conditions are mentioned, so the agent must infer the appropriate context 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.

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

With no annotations provided, the description carries the full disclosure burden and does solid work: tries native value-set, Input.insertText typing, and ARIA-based picker navigation in sequence, with read-back verification. It does not disclose failure behavior, side effects like the calendar widget popping open, or what the call returns, which prevents a 5.

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

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

Two dense sentences with zero filler: the first front-loads the purpose, the covered input types, the strategy sequence, and verification; the second hands the agent the decision rule against browser_fill. Every clause earns its place.

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

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

For a 3-parameter tool with full schema coverage, the combination of strategy, supported frameworks, read-back verification, and the fallback routing to browser_fill is sufficient for an agent to invoke it correctly. The only notable gap is no indication of return/error signals, which is not covered by an output schema.

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

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

Schema description coverage is 100%, so date (ISO string), selector (CSS selector), and skip_picker (skip calendar navigation) are already fully documented. The description adds only a marginal hint about masked vs ISO date format and mostly restates what the schema already conveys, so the baseline 3 applies.

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

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

The description gives a specific verb and resource — 'Robustly set a date input' — and enumerates the concrete input types it covers (native date inputs, masked text inputs, and calendar pickers for MUI, react-datepicker, AntD, Lexical/Meta), making the scope unambiguous. It also explicitly names browser_fill as the sibling it replaces, so an agent can tell them apart without opening either schema.

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

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

It gives an explicit decision rule: 'Use instead of browser_fill when fill fails or for any input that opens a calendar widget,' naming the alternative and the condition that selects this tool. It does not spell out negative exclusions (e.g., defer to browser_fill for plain non-date inputs), so it stops just short of full when/when-not guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the mutation and scope, but does not mention that existing values are overwritten, that localStorage persists, or that this depends on a valid same-origin page context.

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

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

The description is a single active-voice sentence with no filler. The core information—action, resource, and scope—is front-loaded and every word earns its place.

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

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

For a simple two-parameter tool with no output schema, the description and schema cover the essentials. It could mention return behavior or error cases, but the operation is simple enough that the omission is a minor gap rather than a blocker.

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

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

The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds no extra meaning about key format, value serialization, or length constraints beyond what the schema provides.

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

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

The description uses a concrete verb ('Set') with a specific resource ('localStorage key-value pair') and clearly scopes the action to the current page. It is immediately distinguishable from browser_get_local_storage and other browser tools.

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

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

The description gives clear context for when the tool should be used: writing a localStorage value on the current page. It stops short of explicitly naming the reading counterpart or stating when not to use it, so it lacks full routing guidance but is still unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the multi-step approach: auto-click first, screenshot for AI vision, then ask the user. It also names supported CAPTCHA types and notes that it returns detection info and solving status. There is slight ambiguity around how the screenshot and user fallback flow between calls, but the core behavior is transparent.

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

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

The description is four sentences, each earning its place: it names the operation, lists supported CAPTCHA types, outlines the solving flow with a practical detail about Google sign-in, and states the return value. It is front-loaded and free of filler.

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

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

The description covers supported CAPTCHA types, the solving strategy, fallback behavior, and return value, which is strong given there is no output schema. It does not specify the exact shape of detection info or solving status, but the high-level description combined with the well-documented optional parameters is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already explains both parameters and the action enum clearly. The tool description provides useful narrative context about solving strategy but adds no additional parameter-level meaning beyond what the schema already states.

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

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

The description opens with 'Detect and solve CAPTCHAs on the current page', clearly specifying the verb, resource, and scope. It names the specific CAPTCHA types handled, which differentiates it from every generic browser interaction sibling such as browser_click or browser_screenshot.

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

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

The description gives clear context for when to use the tool: whenever a CAPTCHA appears, and it explains the solving order from auto-click to AI vision to human fallback. It does not explicitly name alternatives or state when not to use it, but the specialized purpose makes the intended use obvious.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It states the intended action but does not disclose what happens with an invalid tab_id, whether the browser window is brought to focus, whether the switch triggers navigation or reloads, or what the return behavior is. An agent has limited ability to predict side effects.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the necessary source for the required parameter follows immediately.

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

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

For a single-parameter tool with a fully described input schema, the description provides enough to make the call: what to do and where to get the ID. It could be improved by noting error behavior or return value, but the essential contextual requirements are covered.

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

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

The schema already documents tab_id as 'Tab ID to activate', and the description adds valuable provenance by telling the agent exactly where to get valid IDs. This extra context makes the parameter more actionable than the schema alone.

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

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

The description clearly states the action ('Switch') and the resource ('a specific browser tab'), along with the key requirement ('by ID'). This is distinct from sibling tools like browser_close_tab or browser_navigate, so the tool's purpose is unambiguous.

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

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

The description explicitly tells the agent where to obtain valid tab IDs: browser_list_tabs or browser_get_new_tab. This establishes a clear precondition for use. It does not explicitly call out when not to use the tool or compare it against alternatives, but the usage context is clear enough.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses the mechanism (Chrome Debugger API, programmatic file setting, no dialog), and the hard constraints (regular files only, must be inside the working directory, folders/symlinks/hardlinks pointing outside refused). This goes well beyond the bare 'upload' verb, though it stops short of describing failure/return behavior.

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

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

Four sentences, each earning its place: purpose is front-loaded, mechanism follows, then the sibling routing and constraints. The final sentence is a bit dense with the symlink/hardlink qualifications, but there is no wasteful or redundant content.

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

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

The description covers the essential decision-making: what it does, how it works, the alternative tool, and the path restrictions an agent must respect. With no output schema, a brief note on outcome/error behavior would have made it fully complete, but nothing critical for selecting and invoking the tool correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds genuinely useful semantics on top by constraining what values are valid for file/files: they must be regular files inside the server's working directory, and symlinks/hardlinks pointing outside are refused. This changes how the agent constructs arguments.

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

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

The description states a specific verb+resource: 'Upload a file to a <input type="file"> element on the page.' It targets a precise element type and is clearly distinguished from the sibling browser_drop_file, which handles drag-drop zones. An agent can identify what this tool does without opening the schema.

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

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

The description explicitly names the alternative: 'For drag-drop zones without visible file input use browser_drop_file.' This tells the agent exactly when to choose this tool over its closest sibling, leaving nothing to inference.

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

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

With no annotations, the description carries the behavioral burden. It does disclose the primary behavior: waiting for an element to appear and supporting CSS/text selectors. However, it does not mention what happens on timeout, whether it waits for visibility vs existence, or what the return value/error behavior is.

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

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

The description is a single, focused sentence that front-loads the primary purpose and adds selector-type support without unnecessary detail. Every word earns its place.

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

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

For a simple two-parameter tool with a fully described schema, the description is largely adequate. Gaps remain around timeout behavior and return/error semantics, which an agent would need to know for robust invocation, but the core usage is clear.

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

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 documents both selector and timeout. The description only restates selector types already present in the schema and adds no additional meaning beyond the structured definitions.

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

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

The description uses a specific verb ('wait') and resource ('element to appear on the page'), clearly stating the tool's core action. It also distinguishes itself from the sibling browser_wait_for_network by focusing on DOM elements rather than network activity.

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

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

No guidance is provided about when to use this tool versus alternatives like browser_wait_for_network. The description implies usage ('when you need to wait for an element') but gives no exclusions or decision criteria.

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

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

With no annotations, the description carries full behavioral burden. It does disclose an important trait: 'Monitors real network traffic via Chrome DevTools Protocol.' However, it does not explain behavior on timeout, whether it waits for the first matching request or all requests, or what happens if no request matches. Adequate but with gaps.

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

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

Two sentences, front-loaded with the primary action, followed by the use case and mechanism. Every sentence earns its place with no fluff or repetition.

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

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

For a simple wait tool with 100% schema coverage and no output schema, the description covers what, when, and how. Missing details like timeout behavior and return value are minor given the simplicity, but the lack of annotations means slightly more context would be ideal.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (timeout and url_pattern) with useful descriptions. The tool description adds no extra parameter meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

Description uses a specific verb+resource: 'Wait for a network request to complete.' It clearly distinguishes itself from generic browser_wait by specifying network-level waiting and adds the CDP mechanism. An agent can immediately understand what this tool accomplishes.

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

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

Provides clear context: 'Useful after clicking buttons that trigger API calls - ensures data is loaded before reading the page.' This tells the agent when to use it. It does not explicitly name alternatives like browser_wait or say when not to use it, but the use case is unambiguous enough.

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