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 carries the full burden and does so thoroughly: it enumerates every return status (acknowledged, action with all terminal values, values for done), explains the navigation/origin rules that terminate a prompt, the timeout default, the tab-activation and window-restore side effects, the immediate failure on error pages/about:blank, and the keystroke-visibility caveat. This is unusually rich behavioral disclosure.

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?

Front-loaded with the core purpose, and nearly every clause carries distinct behavioral information that an agent needs. The weakness is structural: it is one dense paragraph with heavy parentheticals instead of being grouped into purpose, inputs, returns, and caveats, which hurts scannability.

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?

There is no output schema, yet the description still documents the return contract in detail, along with failure conditions, security constraints, and tab/window side effects. Nothing an agent needs in order to invoke this 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 baseline is 3, but the description adds real meaning for the fields parameter by explaining its behavioral consequence (card vs. dialog) and its limited value visibility to the page. It also frames the action return values against the field input. It does not add much beyond the schema for title or timeout, keeping it below 5.

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: "Ask the user to do something or give information," and then pins down the two concrete modes (card without fields, dialog with fields). An agent immediately knows this is an agent-initiated prompt to the human. It never names a sibling (e.g. browser_handle_dialog or browser_solve_captcha), so the differentiation is implicit rather than explicit.

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?

Gives clear context for when to use it and how the two modes differ (simple Done/Skip confirmation vs. field collection), plus a prerequisite ("the tab must show a page that loaded") and a security condition (only ask for secrets belonging to the page the tab is on). There are no explicit exclusions or named alternative tools, so it stops short 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 and delivers: auto-scroll into view, real mouse events that work on SPA/CSP-strict sites, modal-dialog-first text resolution, and a detailed failure contract (ok:false, error 'covered', covered_by, maybe_landed). This is unusually rich disclosure of behavior an agent cannot infer from the schema.

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

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

The opening is front-loaded and crisp, but the 'covered' sentence is a single sprawling construction with deeply nested parentheticals ('...nor does a web component's own button...nor a box with a checkbox, switch or radio role right next to a hidden field...') that is very hard to parse. The information is valuable but the packaging is bloated and structurally poor.

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 exists, so the description must and does explain the failure return shape ('covered', covered_by, maybe_landed). For a single-parameter click tool this is close to complete; only the success-path response and any waiting/timing semantics are unspecified, which are minor gaps.

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. The description exceeds that by enumerating concrete selector formats and giving four worked examples ('#my-button', 'text=Submit', etc.), plus documenting the modal-first text-matching order — meaning well beyond the schema's terse parameter note.

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?

Opens with a specific verb and resource ('Click an element on the page') and immediately clarifies the selector model, which distinguishes it from pointer-coordinate siblings like browser_click_xy. It never names the sibling alternatives (browser_double_click, browser_right_click), so the differentiation is implicit rather than stated.

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?

Offers rich tactical guidance on selector choice (CSS vs text, 'text=Submit' vs 'button:text(Submit)') and modal-priority resolution, which implicitly tells the agent how to invoke it. However, it never states when to choose this tool over browser_click_xy, browser_double_click, or browser_right_click, so alternative-selection guidance is absent.

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 traits: clicks use 'fully trusted mouse events' and target the raw viewport rather than an element. It also flags the coordinate-system trap and the workflow (screenshot first, read position, click center). It stops short of saying what the tool returns or how it reports a mis-click/off-target click.

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?

Front-loads the critical framing ('ESCAPE HATCH') in the first four words, then escalates to the trigger condition and the coordinates caveat. The conversion formula is dense but earns its place; total length is justified for a tool whose main hazard is coordinate misinterpretation.

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, no-output-schema, no-annotation click tool, the description covers the selection context, the coordinate system, and the recommended precondition (screenshot). It omits post-click behavior (waiting, failure reporting, whether it scrolls into view), which would round it out.

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 already 100%, so the baseline is 3, but the description adds genuinely new meaning by warning that coordinates are CSS pixels rather than image pixels and supplying a conversion formula. That is real value beyond the schema's bare 'X coordinate (CSS pixels, from left of viewport)'.

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 ('Click at raw viewport coordinates (CSS pixels) with fully trusted mouse events') and frames itself as an escape hatch distinct from the selector-based browser_click sibling. An agent can immediately tell this apart from browser_click/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?

Gives explicit trigger conditions — 'Use when a visible button resists every selector strategy' — and names motivating cases (Azure portal dialogs, Knockout-bound divs, canvas UIs). It effectively implies 'do not use this when a selector works', but never names the preferred alternative tool outright, so it falls just short of full when/when-not routing.

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, the description carries the full burden and does so richly: it discloses the pre-flight coverage check, the exact failure contract (ok:false with error "covered" and covered_by), that nothing is sent when detection fires early, that remaining presses are aborted on late obstruction, and the maybe_landed:true signal. This is far more behavioral context than a typical definition supplies.

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 purpose is front-loaded, but the body is one sprawling run-on sentence with parentheses nested several levels deep (e.g. the label/shadow-root/role clauses), making the coverage rules very hard to parse. Valuable content is buried in a structure that resists reading rather than a concise statement with the edge cases separated out.

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 no-output-schema tool, the description supplies the return contract (ok:false, covered_by, maybe_landed), the sequencing of events, and the obstruction edge cases, so an agent has what it needs to call and interpret the result. Nothing essential 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 description coverage is 100% for the single 'selector' parameter ('CSS or text selector'), so the schema already documents it. The description refers to 'an element' but adds no selector syntax or matching detail, matching the baseline 3 when the schema does the heavy lifting.

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

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

The opening sentence gives a precise verb+resource: 'True double-click on an element (two trusted press/release pairs with escalating clickCount)'. It further distinguishes itself from a naive two-single-click approach by explaining the inline-rename failure mode, so an agent can separate it from browser_click 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 states when to use it explicitly ('Use for open-item actions (calendar events, file lists) where two single clicks would trigger inline-rename'), with a concrete example (OWA month view). It does not name the sibling tool (browser_click) that should be used otherwise, leaving the exclusion implicit.

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 does so richly: it discloses the file-access prerequisite, the 'Not allowed' -> file-access-off error mapping, two distinct internal strategies (direct file input vs. intercepting the native OS chooser), and filesystem constraints (regular files inside the working directory; folders/symlinks/hardlinks pointing outside refused). This is unusually complete behavioral disclosure.

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?

Every sentence is substantive, but the text is a dense wall of long sentences with embedded parentheticals, and it is front-loaded with a prerequisite rather than the purpose. An agent gets the content but pays a high reading cost and must assemble the purpose itself.

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 does the job of describing returns and error payloads (input, cleared_by_page, seen_in_field, other_file_inputs, file-access-off). It is complete for a complex, multi-strategy tool, though the file vs. files parameters and the exact shape of the success response remain only implicitly 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?

Schema coverage is 100%, so the schema documents file/files/selector; the description still adds real meaning by explaining that selector points at the drop-zone target in strategy 1 but at the button that opens the dialog in strategy 2, and by tying the file argument to the working-directory constraint. It does not clarify the file vs. files (alias) distinction, keeping it below 5.

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 conveys that the tool hands a file to a page and explicitly routes relative to browser_upload_file ("Upload a file when browser_upload_file fails"), so the verb+resource is clear. However, no single crisp purpose sentence leads the text — the opening sentence is a prerequisite about the 'Allow access to file URLs' switch, so an agent must infer the core purpose from later fragments.

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 names the alternative explicitly ("Upload a file when browser_upload_file fails") and gives the selecting condition, plus a prerequisite (the file-URLs switch) and a re-attach caution after cleared_by_page. It stops short of stating when NOT to use it or why the sibling would fail, so the guidance is clear but not fully exhaustive.

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?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the wheel-vs-script scroll method, the hidden/background-tab limitation (no wheel events, IntersectionObserver callbacks or animation frames, so reached_end is false and 'note' explains why), deduplication of row text, and the error case ('no-rows'). This is unusually rich behavioral disclosure well beyond what a bare schema conveys.

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?

Front-loaded with purpose and the alternative, then progressively deeper behavior. It is long but nearly every sentence carries distinct information (scroll method, tab visibility effects, return fields, error code). Dense rather than padded, though the volume is at the upper edge of what is needed.

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 exists, so the description must explain return values, and it does: deduplicated row text, scroll_method (wheel or script), and reached_end semantics (true only at the bottom of a visible page after stable_rounds of no growth). Combined with the error case and hidden-page caveat, an agent has everything needed to call and interpret results 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, but the description adds real meaning: it explains what the selector must match (one repeating row, with per-site examples) and that the container's scrollable ancestor is auto-detected when omitted. The reached_end/stable_rounds coupling is also clarified, tying a parameter to an output semantic.

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 ('Read the rows of a long or virtualised list by scrolling its container') and explicitly scopes it to a class of page. It directly distinguishes itself from the sibling browser_get_page_content, so an agent can choose between them 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?

Explicitly names the alternative ('Use this instead of browser_get_page_content whenever a page shows a repeating list longer than the viewport') and gives concrete trigger examples (Outlook, Gmail mail lists, invoice tables, search results, transaction histories). It also explains why the alternative fails (~7 rows in DOM), which is exactly the routing rationale an agent needs.

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 behavioral burden and largely meets it: it discloses that the tool navigates the browser but returns no content ('It reads nothing itself'), that four providers land on an intermediate settings/app-list page rather than the token page, and that unsupported providers yield 'Unknown provider'. It does not say whether it navigates the current tab or opens a new one, nor anything about failure/timeout behavior, which is a meaningful gap for a state-mutating browser 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?

Four tightly packed sentences, front-loaded with the core action and provider list, then the read-it-yourself caveat, then the edge cases. No filler; every clause carries operational information.

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?

There is no output schema and no annotations, so the description must cover behavior, and it does cover navigation semantics, follow-up actions, and edge cases. The one remaining ambiguity is what the tool itself returns (instructions text, a status, or nothing before the follow-up read), which the description implies but never states outright.

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 lists the accepted provider strings, so the baseline is 3. The description adds genuinely new semantics beyond the schema: the behavior for out-of-list values ('Unknown provider') and the note that several listed providers route to an intermediate page, which affects how the result should be interpreted.

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 resource: 'Open a known provider's API page ... and get instructions for finding or creating its API credentials there.' It enumerates the supported providers and immediately distinguishes itself from sibling tools like browser_navigate and browser_get_page_content, so an agent can select it without reading 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 states when to use it (only for the nine named providers), when not to (any other provider), and names the alternative explicitly: 'Any other provider answers Unknown provider; use browser_navigate and read the page yourself.' It also prescribes the required follow-up step. This is explicit when/when-not/alternative 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 and does so well: it discloses CORS/CSP immunity, that browser cookies are neither sent nor stored, that a token must be passed via headers, and that plain http only reaches 127.0.0.1. It omits error/timeout behavior and the response shape, keeping it just below 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 packed sentences with zero filler; the core capability is front-loaded and each clause adds a distinct constraint (scope, cookie policy, protocol limit).

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 fetch tool with no annotations and no output schema, the description covers the critical behavioral traits an agent needs to call it safely. The one gap is the return value/response format, which nothing else in the structured data supplies.

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 url, body, method, and headers; baseline is 3. The description adds the useful auth hint ('pass a token in headers') tied to the cookie policy, but gives no additional syntax for body/method 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?

States a specific action (make an HTTPS request from the extension background) and immediately distinguishes it from an in-page fetch by noting CORS/CSP bypass. It does not name sibling tools like browser_navigate or browser_execute_script, but the resource and scope are 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?

Gives a concrete when-to-use context ('API calls (Google, Stripe, Slack) where a fetch from the page would be blocked'), which tells the agent the exact scenario this tool exists for. It stops short of naming alternatives or stating exclusions, so it's clear but not fully routing-aware.

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 behavioral burden and does so well: it discloses auto-scroll and focus, that CSP-strict sites are handled via the Chrome Debugger API, that text selectors trigger an implicit click first, and that an unreachable element yields ok:false with error "covered". What is missing is whether the fill replaces or appends existing content and whether the value is set via native setter/input events, which matters for framework-bound forms.

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, front-loaded with the core action, then capabilities, then sibling routing, then the failure contract. Every sentence carries information, though the click-precondition sentence is dense enough that it could be trimmed slightly without losing meaning.

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?

There is no output schema, so the description compensates by documenting the failure shape (ok:false with error "covered"). Combined with capability disclosure and sibling routing, an agent has everything needed to invoke it correctly and interpret 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 baseline is 3, but the description adds real meaning beyond the schema: it clarifies that the selector accepts either CSS or text-based forms and explains the behavioral difference between them (text selectors are clicked first). It does not add anything for value, though that parameter is largely self-explanatory.

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?

Opens with a specific verb+resource (fill a form input field with a value) and immediately carves out territory from siblings by naming browser_set_date and browser_set_combobox as the correct tools for date and combobox fields. An agent can distinguish this from browser_click, browser_select_option, and the other input-related siblings without opening a 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?

Explicit routing is given: date inputs go to browser_set_date, autocomplete/combobox to browser_set_combobox. It also states the precondition for success with text selectors (the element must be clickable at its center) and what happens when it is not, which tells the agent when to expect failure rather than a silent no-op.

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 full burden and does so well: it discloses the non-blocking arm-and-return semantics, the fact that a dialog freezes the tab, and the specific failure mode (tab-not-responding) with a pointer to alternatives. This is the behavioral context an agent needs to avoid a deadlock.

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 and front-loaded: purpose first, then timing, then the conditional, then the failure mode. No filler 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?

Complete for a tool with no annotations and no output schema: timing rules, the blocking/non-blocking distinction, the freeze hazard, and the error path are all covered. Nothing an agent needs to invoke it 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 description coverage is 100%, and the description's guidance on wait essentially restates the schema's own note ('Only use when the dialog is already on its way'). The arming-window timing is useful context, but the per-parameter meaning is already fully documented in the schema, so 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?

States a specific verb ('arm automatic handling') and resource ('next JavaScript alert/confirm/prompt on the active tab'). It is unmistakably distinct from siblings like browser_click or browser_dismiss_overlays, since it handles a dialog that has not yet appeared.

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?

Gives explicit sequencing guidance ('Call this BEFORE the click that opens the dialog') and a conditional branch ('Pass wait=true only when the dialog is already opening'). It also states the when-not case: a dialog already on screen cannot be answered here and yields tab-not-responding.

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 does substantial work: it discloses the 'covered' failure case, the covered_by field, that nothing is sent when coverage is detected pre-move, and that maybe_landed:true is returned when something occludes mid-movement. Missing only success-path detail, but the failure/ordering semantics are unusually well disclosed.

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?

Purpose and selector support are front-loaded in the first two sentences. The final sentence is a dense run-on (awkward phrasing like 'the page may already reacted'), but it earns its length by conveying non-obvious ordering semantics.

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 annotations and no output schema, the description compensates by describing the shape of the failure response (ok:false, error 'covered', covered_by, maybe_landed). An agent has enough to call and interpret results, though success-return behavior is left implicit.

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 both parameters carry descriptions, so the baseline is 3. The description's 'Supports CSS and text selectors' largely restates the selector schema entry and adds no format syntax or duration guidance beyond 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?

States a precise verb (hover) plus resource (element) and names the concrete outcomes it produces (tooltips, dropdown menus, hover states). This clearly distinguishes it from the many click/keyboard siblings such as browser_click 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 implies when to use it by listing the UI behaviors it triggers, but offers no explicit when-not guidance and names no alternative sibling (e.g. browser_click for actual clicks). Usage is inferable but not spelled out.

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?

With no annotations, the description carries the full behavioral burden. It does disclose the most likely source of confusion: the 'active' flag means Chrome foregrounding within its own window, not which tab this session is working in, and it states that other sessions' tabs are excluded. It omits anything about ordering or staleness of the list, but for a zero-parameter read this is solid disclosure.

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 compact two-sentence block, front-loaded with the scope, then the field list, then the disambiguation of 'active'. Every clause earns its place; nothing is padded.

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 exists, so the description must convey the return shape, which it does by naming id, URL, title, and active. Combined with the explicit session-scope exclusion, this is nearly complete for a trivial read; only list ordering/staleness is unaddressed.

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 takes no parameters, so the schema has nothing to document and the baseline of 4 applies. The description correctly adds no parameter noise.

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 (list tabs) plus the exact scope (tabs this session owns, defined as opened or adopted) and enumerates the returned fields (id, URL, title, active flag). This lets an agent separate it from browser_switch_tab, browser_get_new_tab, and browser_list_frames without opening a 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 implies the use case (discover which tabs exist in this session) but never states when to prefer it over alternatives like browser_switch_tab or browser_get_new_tab, nor any exclusions beyond the scope note. Usage is inferable but not guided.

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 does disclose one important behavioral trait: the current tab's page is replaced, so the agent knows navigation is destructive to the existing page unless new_tab is set. Beyond that it says nothing about whether navigation waits for load, how errors are surfaced, or what state is returned after the call, which are the behaviors an agent most needs for a navigation primitive.

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 short sentences, front-loaded with the action, then the default behavior, then the exception. Every sentence earns its place and nothing is padded.

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 an 8-parameter navigation tool with no annotations and no output schema, the description covers the core action and the most consequential flag but omits the post-navigation contract (does it block until load, what is returned) and ignores the complex window-placement surface entirely, leaving that to the schema. Adequate but with clear gaps.

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 property descriptions are unusually detailed (including the multi-lingual window/focus parameters), so the schema does the heavy lifting. The description only adds the reuse-vs-new-tab default, which the new_tab property description already states, 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?

States a specific verb and resource ("Navigate the active browser tab to a URL") and scopes it to the active tab, which implicitly separates it from siblings like browser_get_new_tab, browser_switch_tab and browser_list_tabs. No sibling is named explicitly, so an agent must infer the boundaries rather than being told them.

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?

"Pass new_tab=true only when you need to keep the current page open" is a clear, explicit condition for the main flag, which is genuinely helpful. However, there is no guidance on when to reach for browser_navigate versus alternatives such as browser_switch_tab, browser_get_new_tab or browser_fetch, so tool-level selection is left implied.

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 does so well: it warns that ctrl/meta/alt suppress character typing, that ctrl/meta+a/c/x/v/z/y map to Chrome's own editing commands, and that paste writes the user's real clipboard while copy/cut overwrite it. It also clarifies the return semantics of `shortcut` vs `landed`. These are side effects an agent could not infer from the schema.

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

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

The opening two sentences are well front-loaded, but the middle section is dense and hard to parse, particularly "including on macOS, where Chrome runs no shortcut for a synthetic key without it," which is grammatically tangled. The length is largely justified by the behavioral detail, but the wording needs tightening.

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 6-parameter, unannotated, no-output-schema tool, it covers key usage, modifier semantics, clipboard side effects, and even the shape of the response (`shortcut`, `landed`). It omits prerequisites such as whether the target element must be focused and how unrecognized keys fail.

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 3 baseline applies, and the description adds real meaning beyond the schema's terse "Hold Ctrl/Cmd key" strings: it explains that no character is typed while a modifier is held and that certain modifier+letter combinations dispatch browser editing commands. It does not clarify `code` behavior beyond the schema, keeping it short of a 5.

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 ("Press a keyboard key") and immediately grounds it with concrete key names and the scenarios it serves: submitting forms, navigating dropdowns, closing dialogs. An agent can distinguish this keyboard-input tool from browser_fill, browser_click, or browser_select_option without opening any 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?

Gives clear positive contexts ("submitting forms, navigating dropdowns, closing dialogs") that tell the agent when this is the right tool. It stops short of naming alternatives or when-not conditions (e.g., use browser_fill to enter text, browser_select_option for dropdown values), so the routing guidance is contextual rather than exhaustive.

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 does so: it discloses that nothing is uploaded, that a redacted single line is written per run to ~/.browser-mcp/feedback.jsonl with dedup and retry semantics, that emails and long numbers are stripped, and that BROWSER_MCP_CHECK_NPM controls npm comparison. This is unusually rich behavioral disclosure for a no-annotation 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 purpose and the call-automatically instruction are front-loaded, which is correct. However, the install-checking sentence is a long, heavily parenthesized run-on that packs environment variables, offline behavior, and multi-extension detection into one breath, costing some readability.

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 what would be returned (verdict, concrete fix steps, pre-filled issue link), the privacy model, local logging behavior, and the env-var toggle. An agent has everything needed to call it correctly and to relay its 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 coverage is 100%, which sets the baseline at 3, and the description goes beyond it by explaining that what_happened, attempted, and worked are sanitized (emails and 6+ character numbers replaced) before logging or inclusion in the issue link — a processing detail absent from the schema. It does not otherwise elaborate on the enum or url/tool fields, so it stops short of a 5.

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 opening states a specific dual function ('Self-diagnosis + feedback in one call') and then enumerates exactly what the self-diagnosis does: check extension version, detect duplicate connections, return a verdict, fix steps, and a GitHub issue link. No sibling tool overlaps this role, so the agent can identify it immediately.

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 trigger conditions ('the moment Browser MCP itself gets in your way: a tool errors or times out, a tool does something other than what it promised, the extension will not connect, a capability you need plainly does not exist') and even an imperative to call it automatically without asking. This is as close to unambiguous routing as it gets.

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 and does so well: it discloses the 'covered' failure contract (ok:false, covered_by), that nothing is sent when coverage is detected up front, that remaining presses/clicks are aborted if it arrives later, and the maybe_landed:true signal. This is exactly the failure-mode detail an agent needs for a click primitive.

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 core purpose is front-loaded in the first clause, but the remainder is a single dense, run-on sentence with em-dash parentheticals that is harder to parse than it needs to be. It is information-dense but not well structured.

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-parameter tool with no output schema, the description is complete: it covers success behavior, the coverage/occlusion failure path with error codes, the abort semantics, and the maybe_landed ambiguity. An agent has everything needed to call 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% for the single 'selector' parameter (CSS or text selector), so the schema already documents it. The description says only 'an element' and adds no selector syntax or format detail 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?

States a specific verb and resource ('Right-click an element') plus the mechanism (trusted CDP mouse events) and the goal (open page-level context menus). It implicitly separates itself from browser_click/browser_double_click via 'right-click' but never names them, so it stops short of full sibling differentiation.

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 note that Chrome's native context menu does not open via CDP is genuinely useful scope guidance, implying this tool only works for in-page menus. However there is no explicit when-to-use vs alternatives statement or routing to a sibling tool, so usage is only implied.

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 does so well: it discloses the return format (base64 PNG or file on disk), the pixel semantics (device pixels), the conditional viewport/dPR extras, and a concrete failure mode with its error string ('window-covered'). It also states a side-effect constraint (Chrome stays where it 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?

Front-loads the core action, then layers return format, coordinate caveat, and error case. Dense but every clause contributes; only the window-covered wording is slightly verbose.

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 exists, so the description must explain returns, which it does (base64 PNG / file, viewport size + dPR). Error behavior and side effects are covered; edge cases like image dimensions or timing are left implicit but not critical.

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 both parameters are already documented, including the user-consent caveat on bring_to_front. The description adds only the consequence of path ('saves to disk') and the coordinate relevance of the output; it does not meaningfully extend parameter semantics, so 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?

States a specific verb and resource ('Take a screenshot of the visible area of the current tab') with a clearly scoped target (visible area, current tab). No sibling tool does screenshots, so it is trivially distinguishable.

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 ties the tool to downstream use ('devicePixelRatio, which browser_click_xy coordinates need') and to the prerequisite for bring_to_front ('only after the user agreed (browser_ask_user)'), giving clear contextual guidance. It stops short of stating explicit when-not conditions or 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?

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 zero annotations, the description carries the full burden and delivers: it discloses the click-reachability check shared with browser_click, the 'covered' error for both trigger and option, the trigger_clicked/maybe_landed/landed:null outcome fields, and the policy that unchecked clicks are not sent. This is unusually rich behavioral context for a mutation-ish interaction tool.

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

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

The purpose and the sibling routing are front-loaded well, but the final sentence is a dense run-on stacking several conditional outcomes ('if it opens a dialog, or the option is not found...') that is hard to parse. Much of the edge-case detail could be a structured table or bullet list rather than prose.

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?

There is no output schema, so the description must convey return semantics, and it does so thoroughly for failure and ambiguity cases (ok:false, covered, trigger_clicked, maybe_landed, landed:null). A canonical success shape is implied rather than stated, which is the only 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?

Schema description coverage is 100%, so the schema already documents selector, option, and wait (including the 300ms default and the alias/match-order rules). The description's parameter-related content largely restates the option semantics ('Read the page before selecting again') already present in 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?

States a specific verb and resource ('Select an option from a dropdown menu') and immediately scopes the resource: native <select> AND custom dropdowns. It explicitly distinguishes itself from the closest sibling by naming browser_set_combobox for the autocomplete case.

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?

Gives one explicit routing rule with its condition: 'For autocomplete (typing filters options) use browser_set_combobox instead.' That is a clear alternative with a selector condition, but there is no broader when-to-use/when-not guidance (e.g., vs browser_click or browser_fill on a select element).

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, the description carries the full behavioral burden and does well: it discloses the one-action-per-call stateful pattern, that 'click_grid' returns no image (a genuinely non-obvious trait), and that 'ask_human' shows nothing itself but returns a message. It doesn't cover failure/detection-negative behavior, permissions, or rate limits, which keeps 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?

Front-loaded with the core verb, then four tight sentences mapping one-to-one to the action enum. There is some duplication between the body text and the 'action' parameter description, but the structure is dense and every sentence carries actionable information.

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-param, no-annotation, no-output-schema tool, the description covers the action state machine and its cross-tool dependencies well enough to drive correct invocation. It could be more complete about what 'detect' reports back and what happens when solving fails, but nothing essential for calling it 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 description coverage is 100%, so the schema already documents 'action', 'grid', and 'cells' thoroughly, including the 0-indexed ordering and the 4x4 fallback rule. The prose largely restates the enum meanings; its added value is sequencing (pass cells together with grid), which is closer to usage guidance than parameter semantics. 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 verb and resource (detect and work through CAPTCHAs on the current page) and then enumerates the four concrete action modes with what each one does. It distinguishes itself from siblings by naming browser_screenshot and browser_ask_user as the tools that complement specific actions.

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?

Each action is given a clear usage context: 'click_grid' requires a prior browser_screenshot because the tool returns no image, and 'ask_human' requires browser_ask_user to actually display anything. What's missing is explicit when-not-to-use guidance (e.g. when to give up and escalate, or when the CAPTCHA is unsolvable), so it stops just short 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 and does well: it discloses that Chrome is not brought in front of the user, that the tab is made active within its window, and it decodes the 'visibility' status semantics. It omits error behavior for invalid tab IDs, but the side-effect profile is unusually well disclosed for an unannotated 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?

Three tight sentences, front-loaded with the core action and ID sourcing before the behavioral nuance. Every sentence earns its place, though the final sentence about visibility is slightly 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 or annotations, so the description must carry the behavioral load, and it largely does—covering tab activation scope, the front-of-screen distinction, and ID provenance. Only the failure mode for an invalid or closed tab ID is left unaddressed.

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 baseline is 3, but the description adds genuine meaning beyond the schema by distinguishing 'active in its window' from 'in front of the user' and explaining what visibility conveys about tab_id's effect.

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+resource ('Switch to a specific browser tab by ID') and immediately differentiates it from siblings by naming where IDs come from (browser_list_tabs, browser_get_new_tab) and clarifying that subsequent tools act on the switched 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?

Gives clear context for when this tool is the right step (after listing/creating tabs, before other tab-scoped tools) and flags the consent prerequisite for bring_to_front via browser_ask_user. It stops short of an explicit 'do not use when...' exclusion, but the routing guidance is strong.

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 does so richly: it names the mechanism (Chrome Debugger API, no dialog), the permission prerequisite, the error mapping ("Not allowed" reported as file-access-off), and the non-obvious cleared_by_page/seen_in_field post-upload behavior. This is well beyond a typical definition.

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?

Every sentence carries usable content, but the structure is not front-loaded: it opens with a browser-extension setting caveat and a long error-mapping sentence before stating the core action mid-paragraph. An agent scanning the first line learns about a toggle rather than what the tool does.

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?

There is no output schema, and the description compensates by explaining the relevant return semantics (ok with cleared_by_page and seen_in_field) as well as the failure signal (file-access-off). Prerequisites, constraints, alternatives and edge cases are all covered for this level of tool 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?

Schema coverage is 100%, so the schema documents file/files/selector including the file_path alias, establishing a baseline of 3. The description adds genuine semantics on top: files must be regular files inside the server's working directory, with folders, symlinks and hardlinks pointing outside refused.

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: "Upload a file to a <input type=\"file\"> element on the page." It further distinguishes itself from the sibling browser_drop_file by routing drag-drop zones without a visible input there, so an agent can pick the right tool 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 gives explicit when-not-use guidance ("For drag-drop zones without visible file input use browser_drop_file") and surfaces the key precondition ("Allow access to file URLs" toggle, including that it also grants broader local-file page access). It also advises re-checking the page before re-attaching when the field is cleared, which is actionable selection 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 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.