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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses the failure mode when history is exhausted and that the resulting page is shown/returned ('and show it'). It doesn't state whether the result is a rendered snapshot versus raw text, which is the main remaining behavioral gap.

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, action first, failure condition second, with no filler. Nothing could be removed without losing 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?

No output schema exists, and the phrase 'show it' hints at a returned page view but doesn't confirm what the agent receives or whether a follow-up browser_snapshot is needed. For a zero-param navigation tool this is nearly complete, with only that return-shape ambiguity remaining.

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?

Zero parameters, so the baseline of 4 applies; there is nothing parameter-level that needs explaining and the description correctly stays silent on inputs.

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

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

States a specific verb+resource ('Go back one page in the current tab') and adds scope ('current tab'), which cleanly separates it from siblings like browser_navigate and browser_snapshot. An agent can pick it 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?

Usage is clear context: history back-navigation, plus the failure condition ('no page to go back to') tells the agent when the call is invalid. It stops short of naming alternatives (e.g., use browser_navigate for a fresh URL), so no explicit exclusions.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation/open-world nature is known. The description adds genuinely useful behavior beyond that: the response reports what changed on screen rather than returning a new snapshot, which tells the agent not to expect a full page dump and not to follow up with browser_snapshot reflexively.

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 compact sentences with zero filler: the action first, the constraint second, the response shape last. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

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 only two fully documented parameters, no output schema, and annotations covering safety, the description supplies exactly the remaining pieces an agent needs: the ref-only requirement and the diff-style return behavior. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so both ref and double are already documented in structured fields. The description reinforces the ref-only constraint but does not add syntax or format detail, and the double-click parameter is covered solely by the schema. Baseline 3 is appropriate 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?

States a specific verb (click) and resource (an element by its ref), and enumerates the element types covered: link, button, checkbox, tab, menu item. That enumeration also separates it from siblings like browser_type, browser_select, and browser_key without needing the schemas.

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

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

"Refs only, not CSS selectors or text" is an explicit negative constraint that rules out a common wrong invocation, and the schema points to where refs come from (latest view or browser_find). It stops short of naming which sibling to use for non-click interactions (typing, selecting), so it is clear context but not full alternative 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?

Goes well beyond the readOnly/openWorld annotations by disclosing result caps (up to 15 matches), ordering (nearest first), and the concrete return shape (a view line with its ref and whether it is in view or how many pixels above/below), plus that the ref is directly actionable. That is exactly the behavioral context annotations cannot carry.

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 capability, then the payoff. Dense but not padded; the second sentence doubles as guidance rather than description, which is still earning 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?

With no output schema, the description takes responsibility for explaining what comes back — the view line, ref, and position relative to the viewport — and how to act on it. Nothing needed to call or interpret the tool correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real matching semantics the schema does not: all words must be present, any case, matched against name or text. It stops short of saying how multiple-word queries are tokenized or whether partial-word matches count.

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 (find), resource (elements anywhere on the page, in view or not), and match semantics (name or text containing all words, case-insensitive). An agent can immediately distinguish this from browser_snapshot (full listing) or browser_scroll (positional movement) 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?

Explicitly contrasts with the alternative: use this to reach something off screen that you can name, instead of scrolling through the page. It gives both the when (item is nameable, off screen) and the when-not (don't scroll to hunt for it).

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

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

Annotations already cover read-only and open-world, so the description's job is to disclose mechanics — and it does: pagination via max_chars with each page ending in a continuation offset, plus the plain-text serialization (# headings, - items, | cells). Missing are edge behaviors such as cost of large pages or what happens with a stale/invalid ref.

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

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

Two sentences, front-loaded with the core action, then the format/paging contract, then the usage rule. Every clause carries information; nothing restates the name or annotations.

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 correctly takes on the return-value burden by describing plain-text shape and the paging/continuation protocol. It stops short of saying how to recover from an invalid or stale ref, which is a minor residual gap for a 3-param read tool.

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 semantics beyond the schema: it explains that offset is the continuation token emitted at the end of each page and that max_chars governs page size — turning three bare fields into a coherent pagination loop.

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 ('Read a section's full text by its ref') and enumerates the section kinds it covers (paragraph, article, table, list, thread, main area). The trigger case 'where a view cut text short' makes it unmistakably different from scrolling or screenshotting.

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 instructs 'Use it to read long text instead of scrolling through it or taking screenshots of it', naming two alternatives and when to prefer this tool. It doesn't explicitly position itself against browser_find or browser_snapshot, which are the nearest siblings for locating vs. extracting 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?

Annotations already declare readOnlyHint=false and openWorldHint=true, so the description does not need to establish that this is a mutating action. It usefully adds that the tool 'answers with what changed on screen', which tells the agent to expect a post-action observation, though it could say more about side effects like form submission or navigation.

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

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

The description is two compact sentences with no wasted text. Usage examples and the browser_type alternative are front-loaded, making it easy to scan.

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 browser action with annotations covering safety and openness, the description supplies enough context: what it does, when to use it, the typing alternative, and the kind of response to expect. No output schema exists, but the description states 'answers with what changed on screen', which is sufficient.

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

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

Schema coverage is 100%, and the schema already explains that the key parameter accepts keys joined with '+', including examples. The description reinforces the combination concept but adds no syntax or format detail beyond the schema, so the 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: pressing a key or key combination in the page. It also distinguishes the tool from browser_type by explicitly assigning text entry to that sibling, so an agent can select correctly without opening both schemas.

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

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

Gives concrete when-to-use examples (submit, close a dialog, move through a list, shortcut) and explicitly names the alternative for typing text: browser_type. This is clear routing guidance with an explicit exclusion.

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 readOnlyHint=false and openWorldHint=true already declared, the description adds useful behavior beyond annotations: it says the result is the new page's view and that load failures return the browser's error. It does not describe timeout, auth, or tab-replacement side effects, but the key success and failure behavior is 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?

The description is three short sentences with no waste. The core action is front-loaded, followed by alternate-tool guidance and result behavior.

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 navigation tool, the description covers purpose, the main sibling alternative, success response, and failure mode. Annotations and the schema fill in the rest sufficiently.

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?

There is only one parameter and the schema already documents it at 100% coverage, including that a full URL with scheme is required. The description adds no parameter-specific detail beyond the schema, which is acceptable given the high 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 states a specific verb and resource: 'Open a URL in the current tab.' It also distinguishes the tool from browser_click, making the boundary between direct navigation and in-page link clicking 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?

It gives clear alternative guidance for one important case: use browser_click to follow an on-page link. It does not mention browser_back or other navigation-related siblings, but the primary routing decision is covered.

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?

Beyond the readOnly/openWorld annotations, it discloses a genuinely non-obvious artifact: a glass arrow overlay indicating the last action's target, with instructions for interpreting it as a mis-click signal. It also states the output format is JPEG. It stops short of describing image size, cost, or viewport-vs-fullpage behavior, which keeps it at 4.

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 with the core capability first, then the interpretation caveat, then the routing advice — all front-loaded and waste-free. The middle sentence is dense and slightly meandering with its parenthetical and double clause, costing it the top mark.

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 read tool with annotations and no output schema, the definition covers purpose, alternatives, output format, and the misleading-arrow pitfall. It leaves 'current tab's screen' implicit about viewport vs full-page capture, but nothing essential to correct invocation 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% and the single `ref` parameter is already documented as 'one element to capture; the whole screen if omitted'. The description restates the same omitted/not-omitted behavior without adding format, syntax, or lookup guidance for refs, so the 3 baseline 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 exactly what is returned (a JPEG of the current tab's screen, or one element by ref), which uniquely identifies this as the visual capture tool. It also names the two siblings it competes with (browser_snapshot, browser_get_text), so an agent can separate it from the reading tools without inspecting schemas.

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

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

'Only when layout, images or a canvas matter' is an explicit usage gate, and the same sentence names the cheaper alternatives that should be preferred otherwise. That is a when-to-use plus a when-not-to-use plus named alternatives in one clause.

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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, which only imply the view state changes), the description adds genuinely useful behavior: the response shows the new view, already-pinned regions are named rather than re-emitted, and at-boundary conditions are reported. It does not describe whether the returned view is a full snapshot or a diff, which is the one remaining behavioral unknown.

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 compact sentences with the primary behavior front-loaded and the ref variant immediately after; every clause (default amount, pinned-element handling, boundary reporting) carries distinct 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?

With no output schema, the description does a solid job covering what a scroll returns (new view, named sticky elements, top/bottom notice). The only gap is not stating whether the new view is a full snapshot payload versus a partial diff, which matters for a browser tool.

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 ref, screens, and direction are already fully documented in the schema; the description only restates the 'one screen down by default' and ref behaviors. Correct baseline for a tool whose parameters are covered by structured data, with no added format or interaction detail.

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?

Specific verb ('scroll') plus resource ('the current tab') with the default unit of movement stated, and it explicitly distinguishes the two modes (plain scroll vs. ref-based element scroll). An agent can separate this from browser_snapshot or browser_navigate 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 clearly says when the ref path applies ('with ref, scroll that element into view instead') and that plain scrolling is one screen down by default, which is enough to choose a mode. It does not name a sibling alternative (e.g., when to prefer browser_snapshot over scrolling to inspect content), so it falls short of the explicit when-not guidance a 5 requires.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation/open-world profile is covered. The description adds the return behavior ('answers with what changed on screen'), which is genuinely useful, but says nothing about failure modes (option not found, lazy-loaded options) or whether the dropdown must be closed first. With annotations doing the safety work, a 3 fits.

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: what it does, when not to use it, and what it returns. Front-loaded with the core action and zero filler.

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

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

For a 2-param tool with no output schema, the description covers the action, the alternative path, and the return shape ('what changed on screen'). Only minor gaps remain around error/edge behavior for missing or virtualized options.

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 both params (ref, option) are fully documented in the schema, including the frame-qualified ref format and 'exactly as shown'. The description only restates that the option is matched by visible text, adding little 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?

States a specific verb (Choose) and resource (an option of a native dropdown, combobox, listbox), and explicitly scopes it to native widgets, distinguishing it from the button/list sibling path. An agent can tell exactly what this does without opening the schema.

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

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

Gives the positive case (native dropdown by ref + visible text) and the exclusion with a named alternative: 'For one built from buttons and lists, open it and use browser_click.' That is an explicit when-not plus a redirect to a sibling.

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

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

Annotations already cover read-only and open-world safety, and the description adds substantial behavioral context beyond them: the exact line format, indentation by nesting, inline refs for clickable links, and truncation signalling via '(+N chars: get_text eN)'. It stops short of stating size limits, error behavior, or how much the margin 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-loaded with what is shown, then the format, then the two interpretation rules (link refs, truncated text, footer). Dense but every sentence conveys a rule the agent needs to read the output; the format sentence is long but not redundant.

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, and the description effectively substitutes for one by specifying the header, element lines, refs, link convention, truncation marker, and footer. An agent can parse the result and knows where to go for cut text.

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 single 'mode' parameter has a full enum explanation in the schema, so the schema carries parameter meaning. The description says nothing about mode, leaving it at the baseline for fully documented params.

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 concrete verb and resource – 'Show the current tab's viewport (plus a margin) as text' – and immediately clarifies the distinctive output (text with element refs), which separates it from browser_screenshot and browser_get_text in the sibling list.

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 is implied rather than stated: the format spec reflects the post-navigation 'what's on screen' case, and '(+N chars: get_text eN)' does route the agent to browser_get_text for full text. But there is no explicit when-to-use/when-not statement and nothing about when to prefer browser_find or browser_screenshot instead.

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?

Goes beyond the annotations by disclosing two real behaviors: "submit presses Enter after" changes what the call does, and "Answers with what changed on screen, not a new snapshot" tells the agent the return is a diff and that a separate snapshot is needed for full state. Annotations only give the generic readOnly=false/openWorld=true profile, so this added context matters.

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 front-loaded sentence carrying the action first, then alternatives, then return behavior — no wasted clauses. The semicolon-chained style is dense to the point of being telegraphic, which costs a little 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 3-param tool with no output schema, it covers the essentials: what is replaced, what submit does, where to go for dropdowns/keys, and what the response represents. Only minor gaps remain (frame/ref sourcing is left to the schema, no mention of failure modes on non-editable targets).

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 ref, text and submit are already fully documented, including "the field's whole new text" and "press Enter after; default false." The description restates the same facts (replace whole text, submit presses Enter) without adding new 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 ("Replace the text of a field or editable area by its ref") and immediately distinguishes the tool from its two nearest siblings (browser_select for dropdowns, browser_key for single keys). An agent can pick this tool 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?

Explicitly routes two competing cases to alternatives: "Dropdowns: browser_select; single keys: browser_key." That is clear conditional guidance rather than inference. It stops short of a full when/when-not treatment (e.g. type vs. click-then-type, or whether it works on non-editable elements), so not a 5.

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