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

Goes well beyond the annotations: it discloses that all tabs are closed, in-memory page state is discarded, the on-disk profile (cookies, logins) is preserved, attached endpoint browsers are also closed, and the next tool call auto-starts a fresh browser. This is exactly the kind of destructive-scope and lifecycle context annotations cannot convey.

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 action and its consequences, then the alternative routing sentence. Slightly dense in the opening clause ('the browser agent-in-browser is driving') but every clause carries real 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 zero-parameter session-termination tool with no output schema, the description covers everything an agent needs: destruction scope, what survives, attached-browser behavior, and post-close lifecycle.

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 there is nothing to document; baseline applies. The description does not need to explain inputs and correctly avoids doing so.

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 (shut down) and resource (the browser the agent is driving), and explicitly contrasts with tab_close for closing a single page. An agent can distinguish it from tab_close, browser_status, and browsers_installed 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?

Explicitly names the two situations to use it (finish a session, recover from a stuck browser) and the alternative for the narrower case (tab_close for one page). No inference required.

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 and openWorldHint, so the 'Read-only' and 'Does not launch anything' statements are reinforcing rather than novel. The description does add real behavioral context beyond the annotations: the per-line return shape, the protocol/executable path fields, and the caveat that Safari is detected but not yet drivable.

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 safety qualifier and the core action, then the output shape, then the consumer instruction. It is dense but every clause carries information; the enumerated browser list is the only mildly expendable element.

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 supplies exactly what an agent needs: the line-per-browser return format, the fields emitted, the drivability flag, and the Safari support caveat. Nothing required to call it correctly is absent.

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 zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level detail is needed or missing.

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 the browsers installed on this machine') plus the enumerated set of browsers covered. It also draws a clear line against the sibling browser_status ('shows the one in use'), so an agent can pick 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 tells the agent what to do with the result ('Use the listed name as the browser option when starting the server') and names browser_status as the alternative for the active browser. There is no explicit 'when not to use' framing, but the routing context is 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?

Discloses a non-obvious side effect: it will launch a browser if none is running, which the readOnlyHint alone would not reveal. It also spells out what the report contains. It stops short of saying what happens if the launch fails or how long the start-up can take, keeping 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 sentences, each with a distinct job: what it returns, the launch side effect plus when to call it, and the sibling alternatives. Front-loaded with the core purpose and free of filler.

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

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

There is no output schema, so the description carries the return-value burden and does so fully, enumerating every reported field including protocol type and tab marking. Annotations cover the open-world/read-only framing, and the auto-launch caveat closes the last 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 takes no parameters, so there is no parameter semantics to add and the baseline of 4 applies. Nothing in the description misdescribes the empty input object.

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?

Names a specific verb and resource ('health check: report which browser is connected') and enumerates the returned fields (name, protocol, endpoint, PID, headless, profile dir, open tabs with current marked). It also explicitly distinguishes itself from siblings tabs_list and browsers_installed, so an agent can route correctly 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?

Gives a positive usage rule ('a good first call in a session') and names two alternatives with the exact condition that selects each ('Use tabs_list when you only need the tabs, browsers_installed to see what could be launched'). No inference required.

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 only declare readOnlyHint=false and openWorldHint=true; the description goes well beyond by disclosing the scroll-into-view side effect, the coverage warning, the navigation wait with title/URL reporting, and ref staleness after navigation. These are exactly the operational traits an agent needs before invoking a page-mutating 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-loaded with the action and supported addressing modes, then consequences, then alternatives — a good information order. It is five dense sentences and slightly long, but no sentence is filler; the only redundancy is restating addressing modes already in the schema.

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 compensates by describing the return payload (what was clicked, coverage warning, navigated title/URL). Combined with 8 optional params, the staleness caveat, and the named alternatives, an agent has everything needed 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?

With 100% schema description coverage, the schema already documents all 8 parameters including ref preference and x/y-as-alternative. The description restates the addressing modes (ref, CSS selector, visible text, x/y) but adds no syntax, precedence rules, or conflict resolution beyond what the schema says; 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 (click) and resource (element, addressed by ref/selector/text/coordinates) and immediately names the mechanism (real trusted mouse events) and its consequence (works on links, buttons, custom widgets, checkboxes). This is clearly differentiated from siblings like hover, fill_form, and evaluate.

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 the agent: 'Use hover to move without clicking, fill_form for form fields,' and the schema-preferred ref path is reinforced in prose. It also gives a follow-up rule — 'Refs may be stale after navigation, so snapshot again' — which is a when-to-do-what-else instruction, not just a fact.

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 read-only annotation, the description discloses important behavioral traits: capture begins when the agent attaches, earlier page-load messages are missed, output is one line per entry in `[time] LEVEL text` form oldest first, and clear empties the buffer.

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 front-loaded with purpose, then usage, caveats, and alternatives. Every sentence contributes useful selection or invocation guidance with no 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 read-only console-listing tool with full schema coverage and no output schema, the description covers purpose, capture behavior, output format, usage guidance, reset behavior, and the relevant alternative.

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 tab, clear, level, limit, and pattern are already documented in the schema. The description adds context around clear and error-level inclusion of uncaught exceptions, but most parameter meaning is carried by the schema.

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

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

The description states a specific verb and resource: list browser console output including console.log/warn/error and uncaught exceptions. It also distinguishes the tool from network_requests, making selection 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?

It explicitly says when to use the tool (debug after an action fails, confirm no errors), gives a prerequisite (navigate with action=reload first because capture starts on attach), explains how to reset via clear, and names an alternative for HTTP traffic.

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?

Adds substantial context beyond the annotations: 50000-character output truncation, promise awaiting, bare-expression vs explicit-return evaluation, and an explicit warning that page side effects are real. This directly complements readOnlyHint=false and openWorldHint=true.

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 action and return semantics, then evaluation rules, then limits, then routing guidance. Every sentence carries distinct information with no 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?

No output schema exists, and the description covers return form, truncation limit, and side-effect risk, which is everything an agent needs to invoke an eval-style tool safely and correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning about the code parameter's evaluation model (bare expression returned as-is, multi-statement code needs return). The tab parameter is left entirely to 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 verb and resource ('Run JavaScript inside the page') and the return form ('return the result as JSON text'). Clearly distinguishable from siblings like get_text or snapshot, which read fixed representations.

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 use case ('data the other tools cannot read... computed styles, storage, app state') and the exclusions, routing interaction to click, type and fill_form because those send real input events.

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, the description discloses scrolling into view, firing input/change events for React/Vue/Angular, returning one line per field, stopping with an error that names `fields[i]`, and not submitting the form. These are meaningful behavioral details for a browser form mutation tool.

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

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

The description is dense but front-loaded, starting with what the tool does and immediately covering value types, targeting, side effects, return behavior, and the non-submission caveat without 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 multi-field form mutation tool with no output schema, the description covers the important missing pieces: target resolution, supported value types, event firing, return format, error behavior, and the required follow-up submit 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 coverage is 100%, so the baseline is 3. The description adds useful semantic detail: selects accept an option value or visible label, checkboxes/radios take true/false, and fields are set in order using ref, selector, or visible label.

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—setting values of several form fields in one call—and distinguishes the tool from siblings by explaining that it does not submit the form and that key-by-key typing is handled by `type`.

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 says when to use this tool versus `type`, and it tells the agent to use `click` afterwards to submit the form. It also explains supported field types and how targets are located.

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, so leading with 'Read-only' earns no credit, but the description adds real substance: only visible elements are searched, matching is case-insensitive substring, results carry a ref usable by click/type/hover/fill_form, and an empty return means no match. It does not mention caveats such as iframe/shadow-DOM scoping or whether matches are capped beyond the limit parameter.

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: capability first, then when-to-use, then failure behavior. Every sentence carries distinct information with zero restatement of the schema.

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 read-only tool with no output schema, the description covers what is returned (role, name, ref), how refs are consumed, and the empty-result case. Only edge-case scoping (frames, hidden elements, ordering of matches) is unaddressed, which is a minor gap.

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

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

Schema coverage is 100%, so query, tab and limit are already documented in the schema with the same semantics (case-insensitive substring over text/label/placeholder/id/name). The description restates the query behavior but adds nothing new, and says nothing about tab or limit beyond the schema. 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 (search the page for visible elements) plus exactly what is matched (text, accessible label, placeholder, id or name), and returns role/name/ref. It is clearly differentiated from snapshot and get_text by the 'without a full snapshot' framing.

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 says when to use it (locate one element on a large page without a full snapshot), names the alternative (snapshot), and gives a recovery path when no match is found (shorten the query or call snapshot). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description still adds real behavioral detail beyond them—output is prefixed with page title and URL, hidden text is excluded, and results are truncated at max_chars. It stops short of describing pagination or error behavior on bad selectors, so not a full 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?

Four tight sentences with the core capability front-loaded, followed by use cases, sibling routing, and the truncation caveat. No filler or restated name.

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 compensates by explaining the return shape (plain text prefixed with title/URL, hidden text omitted, truncated at max_chars). Combined with the annotations, nothing essential for a correct call 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 purpose-level meaning: selector narrows output for long pages and max_chars causes the cut. It does not explain selector syntax edge cases or tab defaulting beyond what the schema states.

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

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

States a specific verb (return/read) and resource (visible text of the page or a CSS-selected element) with the output format (plain text). It explicitly distinguishes itself from siblings by noting it carries no element refs, pointing to snapshot and screenshot instead.

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 use cases (articles, search results, tables, status messages) and names the alternatives with the condition selecting each: snapshot for click/type, screenshot for visual layout. An agent can route correctly without inspecting other schemas.

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 past the thin annotation set (readOnlyHint=false, openWorldHint=true) by disclosing that the element is scrolled into view, that its centre is targeted, that the return value reports what is hovered, and that an occlusion warning is emitted. The "real mouse pointer" phrasing signals this is a genuine input-device event rather than a synthetic DOM dispatch, which matters for triggering CSS/JS hover handlers.

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?

Five short sentences, front-loaded with what the tool does and why, then mechanics, then the alternate targeting modes and the anti-recommendation. No filler and nothing repeated from the schema.

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 describing the return payload and its warning case. Combined with the follow-up snapshot advice and the pointing-input rules, an agent has everything needed to call this correctly on the first attempt.

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 per-parameter docs already carry the baseline burden and the score starts at 3. The description adds the cross-parameter constraint (choose one of ref/selector/match/x+y) and the behavioural note that element coordinates come from a scroll-into-view centre rather than the raw viewport, which is not in the schema.

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

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

States a specific verb (move the pointer over) and resource (an element or viewport point) plus the absence of clicking, which sharply separates it from the sibling `click`. The stated purpose (open hover menus, tooltips, lazy content) tells an agent exactly what outcome it buys.

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 away from the tool: "use click to press instead", and gives the follow-up step "Take a snapshot or screenshot afterwards to see what appeared" so the agent does not rely on the return value alone. It also states the selection rule among targeting inputs ("Give one of ref, selector, match or x+y").

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 only say readOnlyHint=false and openWorldHint=true. The description adds crucial behavioral traits: waiting for page load, timeout handling reported as 'still loading', clearing captured network requests, and invalidating element refs requiring a snapshot next. These are non-obvious side effects that go well beyond annotations.

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

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

The description is front-loaded with the core action and return values, then adds important caveats about side effects and alternatives. Every sentence earns its place, though it's slightly dense and could be broken into clearer clauses.

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 navigation tool with no output schema, the description covers return values (title, URL, tab id), timeout behavior, side effects on network requests and element refs, and next steps (snapshot). Nothing essential for 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 description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by noting 'Give either url or action' and scheme defaults, but most parameter meaning is already in the schema. Baseline 3 is appropriate.

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

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

The description states specific verbs (load, go back/forward/reload) and resources (URL, tab history), and explicitly distinguishes from siblings like tab_new and click. An agent can understand exactly what this tool does without opening the schema.

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

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

It specifies when to use this tool vs alternatives: 'Use tab_new to open a page in a new tab and click on links to follow them.' It also clarifies 'Give either url or action', removing ambiguity about argument combinations.

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 declare readOnlyHint=true and the description's 'Read-only:' opener is consistent with that. Beyond annotations it discloses the retention window (only requests since attach), the absence of request/response bodies, the per-request output shape including FAILED/pending states, and the workaround (reload) to capture earlier traffic – context 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?

Front-loaded with 'Read-only' and the core operation, then use cases, then caveats, then the sibling redirect. Four sentences with no filler; each carries distinct information (output shape, purpose, limitation, 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?

No output schema exists, but the description compensates by describing the returned line format and the FAILED/pending states. With annotations covering safety and a fully documented schema, 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 description coverage is 100%, and every parameter (tab, clear, limit, pattern, failed_only) is already documented with an example in the schema. The description adds no additional semantics for these parameters beyond what is structured, 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 ('list network requests made by the tab') plus the scope constraint ('since agent-in-browser attached') and the exact line format returned. It also explicitly names the sibling it is not for ('For script errors use console_messages'), so an agent can distinguish it from console_messages and get_text 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?

Gives concrete when-to-use cases (verify an API call fired, find 4xx/5xx, see what a page loads) and explicit exclusions (response bodies not included, use console_messages for script errors). It also names the prerequisite failure mode and the remedy: requests before attaching are missed, so navigate with action=reload first.

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, the description discloses that this sends a real key press to the focused element, that page changes are not reported and a snapshot should follow, that it returns the key and repeat count, and that an unrecognised key name returns an error. These are useful operational details for a non-read-only, open-world browser action.

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

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

The description is front-loaded with the core action, then gives examples, focus guidance, alternative tools, return behavior, and error behavior in a compact sequence. Every sentence contributes useful selection or invocation information without 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?

There is no output schema, but the description covers return behavior (key and repeat count), side-effect visibility (page changes not reported; snapshot afterwards), error behavior, and the focus prerequisite. Combined with the fully documented schema and annotations, an agent has enough to call the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents keys, repeat, and tab. The description reinforces that keys can be combos and clarifies the focus context, but it does not add substantial parameter-level meaning 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?

The description opens with a specific verb and resource: "Send a real key press (or combination) to whatever element currently has focus." It gives concrete examples and explicitly distinguishes the tool from siblings type and fill_form, so an agent can identify its role 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 states when to use the tool (Enter to submit, Escape to close dialogs, Tab/arrows to move, shortcuts like Control+a) and names alternatives for adjacent tasks: "To enter text use type instead; to set form fields use fill_form." It also explains the prerequisite to focus first with click or type.

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 only declare it is not read-only and is open-world; the description supplies the substance — emulation happens inside the page rather than resizing the window, the size persists until browser close or the next resize, some layouts need a reload, and later screenshots use the new size. These are non-obvious stateful behaviors an agent could easily get wrong.

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 action and purpose, then each subsequent clause adds a distinct operational fact (emulation scope, persistence, reload caveat, validation, screenshot impact). No redundant restatement of the name or schema.

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 still says it returns the size set, and it covers validation, persistence, and downstream effects on screenshots. For a small three-parameter mutation tool, nothing an agent needs before calling 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 already 100% (tab defaults to current tab, width/height examples given), so baseline would be 3. The description adds a genuine constraint not in the schema: 'width and height must be positive,' which prevents an invalid invocation.

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

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

States a specific verb and resource — set the tab's viewport to a given CSS-pixel size — and immediately scopes it with the use case (responsive layout testing) plus concrete examples. No sibling tool touches viewport sizing, so the boundary is unambiguous.

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

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

Usage context is explicit: responsive layout testing with phone/tablet/desktop examples, and it clarifies this does not move or resize the browser window, steering the agent away from expecting OS-level behavior. It doesn't name alternatives, but none exist among the siblings for this capability.

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 readOnlyHint/openWorldHint, and the description adds real value: the image is returned inline, capture is viewport-limited (not full-page), size is determined by the viewport set through resize, and path triggers folder creation plus a saved path in the result. That folder-creating side effect is the one behavior worth flagging more loudly since it is a filesystem write, but it is at least 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?

One tight paragraph, front-loaded with the action, with no filler sentences. Dense nested parentheticals (the full-page caveat and the path clause) make it slightly less scannable than it could be split into bullets.

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-param capture tool with no output schema, the description covers what is returned (inline PNG), the limitation (viewport only), the reload/scroll workaround, the resize dependency, and the optional save result. 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 coverage is 100%, so both parameters are already documented, including the 'Tab id from tabs_list, defaults to current tab' and the path/parent-folder semantics. The description restates the path behavior and default size source rather than adding new meaning, 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 concrete verb and resource ('capture the visible viewport of a tab as a PNG image') and immediately scopes it against siblings by saying snapshot and get_text only describe structure and text. An agent knows exactly what this returns and how it differs from the other read 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?

Names the selection condition explicitly: use this for visual layout, colours or images, because snapshot/get_text are text/structural. It also states the negative case (full-page capture unsupported; scroll and capture again) and the optional save flow, leaving no routing ambiguity.

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 only give readOnlyHint=false and openWorldHint=true; the description adds genuine behavioral context by disclosing the return payload (new scroll position and maximum scroll, so you can tell when you reached the end) and by clarifying that click/hover auto-scroll. It does not contradict the annotations. It stops just short of noting rate/lazy-load timing caveats, so a 4 rather than 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?

The core action is front-loaded in the first clause, the two modes follow, and the closing sentence carries non-obvious routing advice. No sentence is filler and nothing important is buried.

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, but the description compensates by explaining what is returned (new scroll position and max scroll). For a 7-parameter, all-optional tool the coverage is strong; only minor edge cases (e.g. behavior when no scrollable area exists) are 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 description coverage is 100%, so every parameter (ref, tab, match, amount, within, selector, direction) is already fully documented, including the default amount of 600 and that direction is ignored when an element is given. The description groups these into two usage modes but adds no 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?

The description opens with a specific verb ("Scroll") and clearly delineates its two distinct modes: scrolling by an amount in a direction, and scrolling a given element (ref, selector or match) into the centre of the view. This is far more precise than the bare tool name and lets an agent distinguish it from siblings like click or hover.

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 reach for it ("lazy-loaded or long pages") and when not to ("click and hover already scroll their target into view, so you rarely need it for those"). Naming the siblings whose behavior overlaps is exactly the routing guidance 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?

Annotations already declare readOnlyHint=true, but the description adds substantial context beyond that: refs go stale, it sees through shadow DOM and same-origin iframes, output includes stale ref identifiers, and it is cheaper than screenshot. These are operational traits an agent needs and they are not in the annotations.

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

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

Front-loads the read-only nature and what is returned, then moves to refs, usage timing, alternatives, and mode caveat. Every sentence contributes a distinct decision or behavioral fact with no 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?

No output schema exists, but the description explains the output format (role, accessible name, state, [ref=e12]), coverage (shadow DOM, iframes), staleness, and mode differences. An agent has everything needed to call 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 description coverage is 100%, so all four parameters are already documented. The description mentions mode=all including text blocks and implies selector-based narrowing, but largely repeats schema content. 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?

Uses a specific verb ('return a compact text outline') and names exactly what is included: headings, landmarks, interactive elements with role, name, state, and ref. It clearly differentiates itself from screenshot and get_text, so 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?

Gives explicit sequencing ('Call it first on any page, and again after navigation'), names the alternatives ('Far cheaper than screenshot', 'use get_text to just read content'), and explains the staleness condition that triggers re-invocation. Nothing is left to inference.

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

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by naming exactly what is destroyed — the tab's page state and any element refs from it — and by stating the post-condition that the browser keeps running. It also pre-announces the return value (the id of the tab that is current afterwards), which is important for an agent that must re-anchor after a destructive close.

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 and scope, then default/override, then the sibling escape hatch and the invalidation warning. No filler and nothing repeated.

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-param mutation with no output schema, the description covers destruction, scope, default, alternative, and return value — nearly everything needed. The only gap is unspecified failure behavior when `tab` is unknown or already closed.

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 parameter already documents its source ('Tab id from tabs_list') and its default, so the description only restates the default. Baseline 3 is appropriate since the schema carries the semantic load.

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 ('Close one tab') plus the scope boundary ('the browser itself keeps running'), which immediately separates it from browser_close and tab_new/tab_select. An agent can pick it 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 the default behavior (closes the current tab), the override ('pass `tab` to close another'), and an explicit pointer to the alternative for a different intent ('To shut down the whole browser use browser_close'). The when-to-use and when-to-use-something-else conditions are both present.

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?

Adds real context beyond the annotations: it blocks waiting for page load when a URL is given, and it mutates global state by making the new tab current so later page tools target it. That side effect and blocking behavior are not derivable from readOnlyHint=false/openWorldHint=true alone. Not a 5 only because there is no mention of failure modes (e.g., bad URL, load timeout).

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, each doing distinct work: what it does, how it behaves and what it returns, and which sibling to use instead. No 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?

No output schema exists, and the description compensates by naming the return values (tab id, title, URL) and explaining how to use the id downstream. For a one-parameter tab-creation tool this covers everything needed to call it correctly.

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

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

Schema coverage is 100% and the single parameter already documents the https:// default and the omit-for-blank-tab behavior. The description's 'optionally at a URL' merely restates that, 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 ('Open a new browser tab') plus the side effect that it becomes the current tab. It explicitly distinguishes itself from the sibling navigate, which handles changing pages of existing 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?

Gives the alternative explicitly: 'Use navigate instead to change the page of an existing tab.' It also names the follow-on tools (tab_select, tab_close, `tab` argument) so the agent knows where this tool fits in a workflow.

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 readOnlyHint=false / openWorldHint=true: it discloses the side effect (fronts the tab and changes the default target of all page tools), the non-effects ('Does not reload or change the page'), the return value (title and URL), and the error behavior for unknown ids. Nothing here contradicts the annotations — readOnlyHint=false is consistent with the client-side state change of switching the active target.

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 short sentences, each carrying distinct information: effect, return value, id source/error, non-effects, and the alternative path. The core effect is front-loaded and the escape hatch ('pass `tab` to that tool instead') closes the definition without padding.

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, non-readonly tool with no output schema, the description covers effect, side effects, return values, id sourcing, error case, and the do-not-switch alternative. An agent can call this correctly without consulting anything else.

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 property description already explains the tab id, so the baseline is 3. The description earns the extra point by adding provenance (tabs_list or tab_new) and the invalid-id outcome, which are not in the schema.

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

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

States a specific verb+resource ('Switch to an existing tab') and immediately defines the mechanism and effect: brings it to the front and makes it the default target of all page tools. This clearly separates it from tab_new, tab_close, and tabs_list by naming the tab-lifecycle siblings in the id-sourcing sentence.

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 when-to-use routing ('Get ids from tabs_list or tab_new') and an explicit alternative for the case where switching is unnecessary: 'To act on a tab once without switching, pass `tab` to that tool instead.' It also states the failure mode for an unknown id, so the agent knows what a bad call looks like.

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=true and openWorldHint=true, and the description reinforces "Read-only" while adding genuinely new context: the line-based output format, the current-tab marker, the fact that it launches the browser if needed (a real side effect of an otherwise read-only call), and the cross-tool data contract. It stops just short of mentioning timing (e.g., waiting for the page to be ready) or what happens when no browser is installed.

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 read-only guarantee and the resource, then the output contract, then the cross-tool routing. Every clause carries information an agent would otherwise have to discover empirically.

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, no-output-schema list tool, everything an agent needs is present: what it returns, how to interpret the `*` marker, what to do with the ids, and what side effect to expect. 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing the description could clarify beyond confirming the implicit scope of "connected browser." The schema is closed (additionalProperties: false), so no undocumented inputs exist.

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 the open tabs of the connected browser") and goes further to specify the exact output shape: one tab per line as id, title, and URL, with `*` marking the current tab. That output contract lets an agent distinguish this from browser_status and snapshot 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 the agent: "Use the ids with tab_select, tab_close or any tool's `tab` argument" names the concrete consumers of this tool's output, and "For browser details as well use browser_status" names the sibling and when to prefer it. It even warns of the browser-launch side effect so the agent can anticipate state changes.

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?

Adds real behavior beyond annotations: focusing the element, clearing by default first, submit=true pressing Enter and reporting the new page if navigation occurs, and returning the character count. It does not mention failure modes (e.g. what happens if no element matches the selector or the ref is stale) — the schema hints refs go stale, but the description doesn't address it.

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 action, then defaults, then return value, then sibling routing — a sensible order in a single tight paragraph. Slightly dense, but no sentence is waste.

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 does state the return value (characters typed), so that gap is covered. For an open-world, mutating browser tool, more on error/no-match behavior would complete it, but everything needed to call it correctly is present.

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

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

Schema coverage is 100% so the baseline is 3; the description earns above baseline by stating the default clear-on-focus/append semantics, the ref-vs-selector-vs-match precedence, and the submit behavior. It does not add format details for text or tab beyond what the schema already carries.

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 target (type text into input/textarea/contenteditable) and immediately distinguishes the mechanism (real keyboard input events) from a value-setting operation. The named alternatives (fill_form, press_key) make its scope unambiguous relative to siblings.

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

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

Explicitly routes to fill_form for multiple fields/selects/checkboxes and to press_key for non-text keys like Tab or Escape, and explains the no-element case (types into the focused element). An agent can pick the right tool without opening other schemas.

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 only declare readOnlyHint and openWorldHint; the description adds the facts an agent actually needs: 200 ms polling cadence, timeout returns an error, the call returns elapsed wait time, and the ms-sleep cap of 60000. It also states the gone=true inversion covers disappearance cases like spinners.

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 read-only/safety tag and the core polling behavior; nearly every clause carries new information (poll interval, timeout error, return value, exclusive params). The opening sentence packs three semicolon-separated clauses, which costs a little readability against a tool this simple.

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 covers the return value and the failure mode. Combined with 100% schema parameter coverage and the stated exclusivity rule, an agent can call this correctly without further guessing.

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; the description goes beyond it by stating the mutual-exclusivity constraint ('exactly one of text, selector or url') and the asymmetric behavior when only ms is supplied — neither of which the schema encodes. It does not, however, restate the default timeout of 10 s or the tab parameter, leaving those to 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?

Names a concrete action (pause/poll until a condition holds) and enumerates the three condition types plus the plain-sleep mode, which no sibling tool offers. The distinction from navigate/click/scroll is implicit but unmistakable given the polling semantics and the explicit 'instead of guessing delays' framing.

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 tells the agent when to reach for it ('after clicks that load content asynchronously instead of guessing delays'), and gives the selection rule among its own modes ('give exactly one of text, selector or url' vs. ms-only sleep). No competing sibling exists for this job, so no alternative tool needed to be named.

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