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

Annotations (readOnlyHint=false, openWorldHint=true) already establish that clicking mutates state and touches an external browser. The description adds genuine value beyond that by disclosing a concrete behavioral trait: 'Reports any navigation, console errors, or network activity the click triggered.' This is non-obvious side-effect reporting that an agent could not infer from annotations or schema. No contradiction with 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?

Three short sentences, each earning its place: purpose, addressing strategy, and behavioral reporting. No filler, front-loaded with the action verb. The actionable guidance (prefer latest-snapshot refs) appears early. Nothing redundant with the schema is restated at length.

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 carries the return-value burden and does partially meet it by disclosing that navigation, console errors, and network activity are reported. For a 9-parameter click tool with one required field and heavy schema coverage, this is reasonably complete. Minor gaps: no detail on error behavior when the element is not found and no description of the response format.

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 78%, so the schema already documents the parameters well — baseline 3. The description adds marginal value by clarifying the relationship between the three addressing modes (ref/css/role+name) and noting refs come from the latest snapshot, but this overlaps the schema's own 'Preferred — refs are exact' note. It doesn't deepen semantics much beyond the schema.

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

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

States a specific verb+resource: 'Clicks an element.' The purpose is unambiguous and readily distinguished from browser_hover, browser_type, and browser_press_key by the click verb. It does not explicitly name sibling alternatives, which keeps it at 4 rather than 5, but the core action is 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?

Implied usage — the description tells the agent how to address the element ('by ref... or by css, or by role+name') and that refs come from the latest browser_snapshot, which is genuinely helpful. However, it never states when to use this tool versus the sibling interaction tools (hover, type, select_option, scroll) or names any exclusions, so the when-to-use guidance 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 mark the tool as mutating (readOnlyHint: false) and open-world (openWorldHint: true). The description adds 'frees its resources', which gives a concrete outcome beyond the annotations. However, it does not disclose that the session becomes unusable after closing, that state is destroyed, or that the operation is irreversible, which would be valuable behavioral detail given the mutation hint.

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

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

The description is a single, complete sentence with no redundant words. It front-loads the primary action and adds a meaningful effect, achieving maximum clarity in minimal space.

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

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

For a tool with one parameter, no output schema, and simple semantics, the description is adequate. It states the purpose and the resource freed, which is enough for an agent to know when to call it. It could mention that the session is no longer valid afterward, but that is largely implied by 'closes'. Given the low complexity, completeness is high.

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

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

The input schema already documents sessionId with a clear source ('Session id returned by browser_start'), achieving 100% coverage. The description adds no further detail about the parameter, so it relies entirely on the schema. Baseline of 3 applies because the schema carries the burden effectively.

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

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

The description clearly states the action ('Closes'), the resource ('a browser session'), and adds a behavioral effect ('frees its resources'). It is specific enough to distinguish from siblings like browser_start (which creates) and browser_navigate (which moves). No ambiguity in intent.

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

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

The description implies usage in a lifecycle context: it is the counterpart to browser_start, but it never explicitly says 'use after you are done with a session' or mentions alternatives. For such a simple tool, the absence of explicit guidance is acceptable, but it stops short of giving a clear when-not or discussing cleanup ordering.

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

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

Annotations are minimal (readOnlyHint=false, openWorldHint=true), so the description adds meaningful behavioral context: it returns buffered console messages plus uncaught page errors with stacks, and it often directly names the failure. The clear parameter's destructive behavior is documented in the schema rather than the description, which is acceptable since annotations already signal possible mutation.

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 tightly written sentences: the first states the result and content, the second gives practical usage guidance. No wasted words, and the most important information is front-loaded.

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

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

The description combined with the rich input schema and annotations is largely sufficient for an agent to select and call the tool. It lacks an explicit output format, but with no output schema present, the mention of 'messages' and 'errors (with stacks)' gives enough shape for first use. Parameter defaults and clearing behavior are covered by the schema.

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

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

Schema description coverage is 100%, so all five parameters already have clear descriptions and constraints. The tool description adds little parameter-level meaning beyond the schema, but it does reinforce that 'error' level includes uncaught page errors, which aligns with the schema's filter description.

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

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

The description names a specific verb and resource: 'Returns buffered console messages and uncaught page errors (with stacks).' It clearly differentiates from sibling browser tools like browser_network, browser_snapshot, and browser_request_detail by focusing on console output and page errors.

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

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

The description gives explicit when-to-use guidance: 'Check this whenever the page misbehaves.' It doesn't explicitly name alternatives or when-not-to-use cases, so it falls just short of a 5, but the usage context is clear and actionable.

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

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

Although annotations already indicate readOnlyHint: false and openWorldHint: true, the description adds useful behavioral context: it accepts expressions or functions, binds targeted elements to `el`, and returns JSON-serialized results. It doesn't explicitly warn that arbitrary JS may have side effects, but that is implied by 'Runs JavaScript' and already covered by openWorldHint. No contradiction with 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 two sentences plus a usage example—no fluff. It front-loads the primary purpose and then adds the details that matter most (function form and element binding). Every sentence earns its place, and the example is illustrative without being verbose.

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

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

With no output schema, the description explains the return type ('JSON-serialized result'). It covers the two execution modes, element binding, and a usage scenario. It doesn't enumerate all 8 parameters, but the high schema coverage handles that. The only minor gap is an explicit note that JavaScript can have side effects, though openWorldHint already implies this.

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 88%, so most parameters are documented. The description adds meaning beyond the schema by explaining the `expression` parameter with examples and clarifying how element targeting works (binding to `el`). It also implies how `css`/`ref`/`role`/`name` selectors relate to the expression, which the schema does not explicitly connect.

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

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

The description clearly states the verb ('Runs JavaScript'), the resource ('in the page'), and the output ('JSON-serialized result'). It includes concrete examples ('document.title' and 'el => el.value') that make the purpose unmistakable. It differentiates from sibling browser_* tools because it is the only one that executes arbitrary JavaScript.

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

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

The description provides a clear use case: 'Use it to read state the accessibility tree does not expose.' This tells agents when it is appropriate, but it does not explicitly mention alternatives or when not to use it (e.g., 'for accessible text use browser_read_text'). The guidance is implicit rather than explicit about 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 description's 'navigates back' is consistent. It adds the specific outcome 'returns the new page state with fresh refs', which is useful but does not disclose potential failures (e.g., empty history) or side effects beyond navigation. No contradiction with 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 a single, compact sentence that front-loads the primary action ('navigates back') and then states the return value. Every word earns its place with no fluff.

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

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

The description covers the essence: it navigates and returns new state. However, without an output schema or annotations for failure modes, it does not mention behavior when history is empty, whether it waits for page load, or any timing aspects. For a simple browser action this is adequate but could include a caution about history limits.

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% for sessionId, and the description adds no extra detail about the parameter beyond the schema's own description. This is the baseline for a fully documented 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 clearly states the action 'navigates back in history' and the resource 'page state', which distinguishes it from generic navigation like browser_navigate. However, it does not explicitly name sibling alternatives, so its distinctiveness relies on the verb phrase 'go back' which is clear enough.

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

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

The description gives no guidance on when to use this tool versus others like browser_navigate, browser_click, or browser_scroll. It lacks context about typical scenarios (e.g., after following links) and does not mention any exclusions or prerequisites (e.g., existence of history).

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?

The description goes well beyond annotations. It discloses the timing behavior (arming vs. immediate), the auto-dismissal mechanic, and the requirement to call before triggering the dialog for prompt text. This is critical operational detail that the annotations (readOnlyHint=false, openWorldHint=true) do not convey. No contradiction with 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 concise and front-loaded. The first sentence states the core purpose, the second explains blocking and default behavior, and the third gives precise usage instructions. Every sentence adds value with no redundancy or filler, making it an exemplar of efficient writing.

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

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

For a tool with 3 parameters and no output schema, the description covers everything an agent needs to know: how to invoke it, when to call it, what parameters do, and the consequences of not calling it. It also addresses the two distinct operational states. Given the tool's simplicity and the existing schema/annotations, the description is fully complete.

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

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

The input schema already has 100% coverage with clear descriptions for each parameter (accept, sessionId, promptText). The description adds a small amount of context by associating promptText with prompt() dialogs, but it does not meaningfully extend parameter semantics beyond the schema. It mostly explains when to use the parameters, which falls under usage guidance. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: it answers JavaScript dialogs (alert/confirm/prompt). This is a specific verb-resource combination that is immediately distinct from sibling tools like browser_click or browser_navigate. The description also adds valuable context about dialog blocking behavior, which fully clarifies what the tool does.

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

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

The description provides explicit usage guidance: it explains the two calling modes (before opening a dialog to arm the answer, or while it's open to answer immediately), and explains that an unanswered dialog is dismissed automatically. This clarifies when to use the tool and what happens if you don't, which is comprehensive and removes 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 already declare readOnlyHint=false and openWorldHint=true, so the agent knows this interaction can have side effects. The description adds that hovering can reveal UI elements, which is useful behavioral context. However, it doesn't disclose potential failure modes (e.g., element must be visible) or that it may trigger events like mouseover handlers. Given annotations cover the general behavior, this is adequate but not rich.

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

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

The description is two sentences: the first states the action and a motivating example, the second explains how to address the element. It's front-loaded with the core purpose, no redundant wording, and every sentence earns its place. Excellent conciseness.

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

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

The description covers the essential 'what' and 'how to address' for a hover tool. It mentions the snapshot context for refs, which is important. It doesn't explain return values (no output schema exists) or discuss error handling, but those are not typically required. For a tool with six parameters and one required, this is reasonably complete for successful 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 all parameters are documented individually. The description adds integrative value by summarizing the alternative targeting methods (ref, css, role+name) and noting that refs come from the latest snapshot. This helps the agent understand the relationships between parameters and their precedence, which goes beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool performs a hover action on an element, with a concrete example use case (revealing a menu or tooltip). It specifies the resource (element) and the action (hover), which distinguishes it from sibling tools like browser_click or browser_type. However, it doesn't explicitly contrast with those siblings, so it's slightly above average but not perfect.

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

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

The description provides a clear context for when to use the tool ('e.g. to reveal a menu or tooltip') and explains the different addressing methods (ref, css, role+name). This gives an agent enough context to decide when hover is appropriate, though it doesn't explicitly state exclusions or alternatives. The mention of 'from the latest browser_snapshot' for refs adds valuable usage guidance.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description is not required to disclose read-only behavior. It adds value by specifying the actual data returned (computed styles, box model, etc.) and the intent (diagnose layout/visibility). No contradiction with annotations; the description enriches beyond the hints.

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

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

Two sentences with zero fluff. The first sentence front-loads the purpose and output; the second gives a clear use case. Every word earns its place, and the structure is ideal for agent consumption.

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

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

There is no output schema, so the description must convey what the tool returns — and it does, listing tag, attributes, box model, form state, and computed styles. The description covers purpose, usage, and output sufficiently for an agent to call the tool correctly, despite not detailing the exact JSON format or how computed styles are structured. This is adequate for a read-only inspection 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% — every parameter has a definition. The description itself does not add parameter-level detail beyond the schema, which is acceptable when the schema is thorough. It stays at the baseline of 3 because the schema already explains ref, css, role, name, index, props, and sessionId without needing the description to compensate.

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

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

The description states a specific verb ('inspect') and a specific resource ('one element') and enumerates exactly what it returns (tag, attributes, box model, form state, computed styles). It immediately distinguishes the tool from siblings like browser_snapshot or browser_query by framing it as DevTools-style inspection for diagnosing layout/visibility issues.

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

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

The description includes an explicit use case: 'Use it to diagnose layout and visibility problems.' This tells the agent when to reach for this tool. It does not explicitly mention when not to use it or list alternatives, but it does not mislead either. The context is clear enough for an agent to choose correctly among sibling tools.

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 convey readOnlyHint=true and openWorldHint=true, so the description's job is light. It adds useful context by specifying the exact data returned (current URL, age, idle time), which goes beyond the annotation flags and tells the agent what to expect from the call. No contradiction with annotations exists.

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 efficient sentence that front-loads the core action ('Lists open browser sessions') and follows with the concrete data fields. There is no filler, no repetition, and every word adds meaning. Ideal for an agent to quickly parse.

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

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

Given the tool has no parameters, no output schema, and annotations cover safety and world-behavior, the description is largely sufficient. It could be slightly more explicit about the exact structure of the returned list (e.g., array of objects vs. formatted text), but for a read-only listing tool the missing detail is minor and the description provides the essential information an agent needs.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). Per the instructions, the baseline for 0-parameter tools is 4. The description does not need to explain parameters, and it does not waste space trying; it focuses on the output instead.

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

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

The description uses a specific verb ('lists') and a clear resource ('open browser sessions') and enumerates the returned attributes (URL, age, idle time). It unambiguously distinguishes this from navigation, clicking, and other browser actions, so an agent can separate it from siblings like browser_snapshot or browser_start without opening their schemas.

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

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

The description clearly indicates the tool's function, making the use case for listing sessions implied. However, it does not explicitly state when to prefer this over alternatives (e.g., browser_snapshot for current page state) or provide any exclusions. Without explicit routing, an agent must infer its appropriate place among many browser tools, so it falls short of clear standalone guidance.

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

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

With annotations readOnlyHint=false and openWorldHint=true, the bar is lowered. The description adds that it returns a snapshot and that relative URLs resolve against baseUrl, which is useful. However, it does not disclose other behavioral traits such as side effects on the session or blocking behavior, but annotations already cover the mutation aspect.

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

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

Two concise sentences with the main action front-loaded. No wasteful words; the relative URL detail is relevant and efficiently placed.

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, the description is adequate: it specifies the result (page state + snapshot) and URL handling. It does not mention error conditions or prerequisites (e.g., session must be active), but these are implied by the schema and sibling context. Given annotations and schema richness, this is fairly complete.

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

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

Schema coverage is 100%, so the schema documents all parameters. The description only repeats the relative URL behavior already stated in the schema ('Absolute URL, or a path relative to the session baseUrl'). It adds no new meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description states a specific verb ('Navigates') and resource ('session to a URL'), and mentions it returns page state and a fresh snapshot. It is clear and distinct from siblings (e.g., go_back, start) but does not explicitly name the alternatives.

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

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

The description implies when to use this tool (for navigation) and clarifies relative URL resolution, but it does not explicitly contrast with sibling tools like browser_go_back or browser_start. Context is clear but no exclusions or when-not-to-use guidance is given.

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=true already annotated, the description doesn't need to restate safety. It adds some context about the output (status, size, duration, id) but doesn't disclose any additional behavioral traits like pagination limits, timeouts, or how the log is captured. The description adds minimal extra value beyond the annotations, so a 3 is appropriate.

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

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

The description is two sentences with zero wasted words. It front-loads the core purpose and immediately mentions the linkage to browser_request_detail. Every part contributes to understanding, making it appropriately sized and well-structured.

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

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

Given there is no output schema, the description does a good job hinting at the output format (list with status, size, duration, and an id). It also covers the main filtering options. However, it doesn't mention the default limit or that results may be truncated, which the schema covers but the description doesn't reinforce. Still, it is fairly complete for a list 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 all parameters are already described in the schema. The description mentions filtering by URL substring or failure status, which aligns with the schema but adds no new meaning beyond it. For example, it doesn't explain the 'failed' vs '4xx/5xx' distinction beyond what the schema already does, keeping this at baseline 3.

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

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

The description clearly states the tool lists network requests with specific attributes (status, size, duration) and differentiates itself from browser_request_detail by noting each line carries an #id for that tool. It's a specific verb+resource with a clear scope, distinguishing it from its siblings.

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

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

The description implies when to use this tool by mentioning that each line has an id for browser_request_detail, suggesting that this is for a list view while the detail tool is for individual requests. However, it does not explicitly say 'use this for lists, use browser_request_detail for details' or mention any exclusion criteria, so it falls short of explicit guidance.

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

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

Annotations only indicate readOnlyHint=false and openWorldHint=true, so the description carries the burden of explaining behavior. It adds that key names follow Playwright, which is helpful, but does not disclose possible side effects (e.g., navigation triggers), how focusing works, or error conditions. This is insufficient for a mutating tool.

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

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

Two concise sentences with no fluff. The action is front-loaded, and the Playwright key-name note is directly relevant. Ideal length for this tool.

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

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

The description covers the core purpose but leaves several aspects unexplained: how to combine multiple element-targeting parameters (ref vs css vs role+name), the precedence or conflict resolution, and any return value or error behavior. Given seven parameters and two required, this is a moderate gap. However, schema descriptions fill some gaps, so a 3 is fair.

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 86%, so baseline is 3. The description adds specific value for the 'key' parameter by specifying Playwright key names, which the schema lacks. It also clarifies that element parameters are used to focus before pressing, augmenting the schema's generic selector descriptions.

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

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

The description clearly states the action ('Presses a key') and the optional focused element, which is understandable. It does not explicitly differentiate from siblings like browser_type or browser_click, but the resource (key) is distinct enough for an agent to recognize the purpose.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or context for using browser_type for text input or when a key press is preferred. The agent must infer usage from the tool name and siblings.

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

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

The annotations already declare readOnlyHint=true, so no read-only disclosure is needed from the description. The description adds transparency by detailing the return format (compact line per match, including ref and visible/enabled state), which is not in the schema or annotations. It does not contradict 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 exactly two sentences with zero filler. The first sentence states the core functionality and return format; the second gives actionable usage advice. All information is front-loaded and necessary.

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

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

For a 6-parameter tool with full schema coverage and read-only annotations, the description provides everything an agent needs to invoke it correctly: query modes, output structure, and when to prefer it over alternatives. No critical detail is missing given the absence of an output schema; the return format is explicitly stated.

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?

Although schema coverage is 100%, the description goes beyond mere parameter names by explaining the intended use of role and name together ('role+name'), and by grouping the three query modes. This is meaningful guidance that the schema properties alone do not convey. It does not fully duplicate schema descriptions for every parameter.

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

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

The description uses a specific verb ('Finds'), names the resource ('elements'), and specifies three search criteria (role+name, visible text, CSS) plus a defined output shape (compact line with ref, visible/enabled state). It also implicitly differentiates from sibling browser_snapshot by calling itself an alternative to a 'full snapshot', so an agent can distinguish 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?

It explicitly advises using this instead of a full snapshot when the target is known, which is clear usage guidance. It does not enumerate all alternatives (e.g., browser_read_text, browser_inspect_element), but the primary alternative is named and the selection condition is provided. That is sufficient for a read-only query tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the bar. The description adds useful behavioral context: 'rendered text' and 'without markup' explains what the output looks like, going beyond the read-only hint. It does not repeat annotation information and adds nuance about the return content.

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, no fluff, and the core behavior is front-loaded. The first sentence states exactly what the tool does, and the second gives practical usage. Every word earns its place.

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

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

For a read-only tool with many parameters, the description adequately explains the purpose and return content. It does not mention paging (offset/maxChars) or how to target an element, but the schema covers those details, and the annotations convey safety. The description is complete enough for an agent to call 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 88%, so the schema already documents most parameters well. The description adds no parameter-specific details beyond what the schema provides; it mentions 'element subtree' which loosely relates to css/ref but does not explain selector mechanics. Baseline 3 is appropriate given the high schema coverage.

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

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

The description uses a specific verb ('Returns') and clearly identifies the resource: the rendered text of the page or an element subtree. It adds the key distinction 'without markup' and gives concrete use cases (verify copy, read results, check error message), which separates it from sibling tools like browser_snapshot or browser_query.

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

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

The description provides clear context for when to use the tool ('verify copy, read results, or check an error message'), but it does not explicitly mention alternatives or when NOT to use it (e.g., 'if you need raw HTML, use browser_snapshot'). This is clear context without 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?

The readOnlyHint=true annotation aligns with the non-mutating 'Inspects' verb, and there is no contradiction. The description adds genuinely useful context beyond the annotations: the caching note ('Small text responses are cached, so they stay readable after navigation') discloses non-obvious persistence behavior that an agent would otherwise not know.

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

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

Two tight sentences with zero waste. The purpose and parts are front-loaded in the first sentence, and the behavioral caching note in the second sentence earns its place by disclosing a resilience property. No redundancy with 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?

For a read-only inspection tool with no output schema, the description covers the essential purpose, the parts available, and the one non-obvious behavior (caching). It could have explained the timing breakdown / summary default mapping, but nothing an agent needs to safely invoke the tool is critically 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 80%, so the schema already documents most parameters; the baseline is 3. The description adds marginal value by mapping the 'part' enum values (headers, request body, response body) onto concrete terms, though it omits 'summary' and does not clarify the offset/maxChars paging semantics beyond what the schema provides.

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

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

Uses a specific verb ('Inspects') with a precise resource ('one request from browser_network') and enumerates the inspectable parts (headers, timing breakdown, request body, response body). This clearly differentiates it from sibling browser_network, which lists requests, versus this tool which drills into one request's details.

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

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

The description implies the usage flow — inspect a request that came from browser_network — which establishes clear context. However, it never explicitly states when to use this versus alternatives, nor provides exclusions (e.g., 'for the list use browser_network first, then this for details'). The intended workflow is inferred rather than stated.

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, so the agent knows this is a safe read operation. The description adds useful behavioral context: the output is a JPEG, it can capture the full page or a specific element, and it is suited for visual checks. No contradictions with 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?

Two sentences, front-loaded with the action and scope, followed by a clear usage directive. No wasted words; each sentence adds essential 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 tool with 7 parameters but only 1 required, the description explains the primary use case, the output format (JPEG), and when to avoid it. The element-selection details are fully covered by the schema. The description is sufficient for an agent to decide when to invoke the tool and what to expect.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'page or element', which loosely maps to the targeting parameters (css/ref/role/name/index), but offers no additional syntax or selection details beyond what the schema already provides. It neither gains nor loses points because the schema already fully documents the parameters.

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

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

The description states a specific action ('captures a JPEG'), the resource ('the page or an element'), and explicitly scopes it to visual questions (layout, styling, rendering). It clearly differentiates from sibling tools like browser_snapshot and browser_read_text, making it easy for an agent to pick the right tool.

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

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

The description explicitly says 'Use this only for genuinely visual questions' and names two faster/cheaper alternatives (browser_snapshot and browser_read_text) for finding/verifying content. This provides unambiguous when-to-use and when-not-to-use guidance, with concrete alternatives.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the tool may mutate or cause side effects. The description does not disclose what side effects occur (e.g., scroll position changes are visible to user) or any potential navigation side effects. It adds a small detail about delta direction (positive = down) but misses the broader behavioral implications of openWorldHint.

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

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

One concise sentence covers the two main modes, with the key condition ('when no element is given') included. It is front-loaded and to the point, though it could add a brief note about parameter precedence without much length.

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 8 parameters and no output schema, the description does not explain how the different locator strategies interact (ref vs css vs role/name), nor what happens if multiple are provided. It also doesn't note that refs are only valid for the current page state, though that is in the schema. The description adds the core mode distinction but leaves open questions about parameter precedence and error behavior.

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 every parameter is documented in the schema. The description adds the relationship between delta scrolling and element scrolling (dy positive = down), but does not explain interactions between parameters (e.g., dx/dy together vs ref/css/role/name). Baseline 3 is appropriate since schema covers most semantics.

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

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

States a specific verb (scrolls) with two modes: into view by element, or pixel delta. It distinguishes between element-based and delta-based scrolling, but does not explicitly contrast with sibling navigation tools like browser_navigate or browser_go_back, so it could be clearer about its unique role.

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

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

The description implies when to use delta vs element scrolling ('when no element is given') and mentions the element ref is preferred. However, it does not provide explicit when-not-to-use guidance or name alternatives (e.g., browser_navigate for page-level jumps). It gives clear context for the two modes but no 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?

With annotations already declaring readOnlyHint=false and openWorldHint=true, the description adds no additional behavioral context about side effects, event triggering, or return values. It merely restates the mutation ('Selects...') without acknowledging potential page changes or external impacts. This adds minimal value beyond the annotations.

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

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

The description is a single, front-loaded sentence that states the core action first, then explains addressing. There is no fluff or redundant detail. Every word adds value, and it is appropriately sized for the tool's complexity.

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

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

Given the tool has 7 parameters, no output schema, and openWorldHint=true, the description is minimal. It does not mention potential event triggers, error conditions, or what happens after selection. While the schema covers parameter details, the description could be more complete about the mutation's impact and any caveats. It is adequate but leaves gaps.

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

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

Schema description coverage is 100%, so all parameters are documented. The description reinforces the addressing methods (ref, css, role+name) already present in the schema but adds no new semantics. The 'values' parameter meaning is also already covered, so the description provides no extra clarity beyond the schema baseline.

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

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

The description clearly states the verb and resource: 'Selects one or more options in a <select>.' This is specific and distinct from siblings like browser_click or browser_type, which are generic interactions. The addressing modes (ref, css, role+name) further clarify the intended use.

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

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

The description implies usage for select elements but provides no explicit when-to-use or when-not-to-use guidance relative to alternatives. It does not name sibling tools or exclusions, leaving the agent to infer from the purpose. This is adequate but not explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the read-only nature. The description adds value beyond that by revealing the output structure (YAML with refs), the performance characteristics (cheaper than HTML/screenshots), and the fact that refs are tied to a particular page state (mentioned in schema, but reinforced). It doesn't describe side effects, but none are expected for a read-only snapshot.

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

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

Four sentences, each earning its place: the first defines the output, the second establishes the primary use case and inter-tool relationship, the third justifies cost-effectiveness, and the fourth explains scoping options. It is front-loaded with the core purpose and avoids redundancy.

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

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

For an 11-parameter tool with no output schema, this description is remarkably complete. It covers the primary use case, how to control scope (ref/css/role), depth, pagination, and cost trade-offs. It doesn't explain every parameter, but the schema covers those in detail, and the description captures the key decision points an agent needs 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%, so the baseline is 3. The description adds guidance on parameter usage: refs are 'preferred' because they are 'exact', css is an 'alternative', and role combines with name. It also introduces the concepts of scoping, capping, and paging, which map to the depth and offset parameters, providing extra context beyond their schema descriptions.

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

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

The description states a specific verb ('Returns'), a resource ('accessibility tree of the page'), and the output format (compact YAML with refs). It clearly distinguishes this from sibling tools like browser_screenshot by explicitly calling out that it's 'Far cheaper than HTML or screenshots' and frames it as 'the primary way to see the page'.

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

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

The description explicitly says 'use these refs to click and type', which ties to sibling interaction tools and indicates when to call this first. It also mentions to 'Scope it with ref/css/role, cap it with depth, or page through it with offset when a page is large', providing concrete guidance for large pages. It implies when not to use it (e.g., if you need visual info, screenshots exist) by contrasting cost and purpose.

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

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

Annotations only provide readOnlyHint=false and openWorldHint=true, which are minimal. The description adds meaningful behavioral context: the session persists, has an idle timeout, and carries state across calls. This goes beyond the annotations and helps the agent understand the side effects (creating a session) and its lifecycle. It does not cover failure modes or cleanup details, but that's acceptable for a start tool.

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

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

Two sentences with no redundant words. The primary function and the critical session-lifecycle detail are front-loaded. Every phrase earns its place; no filler or vague language.

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 start tool with 7 parameters and no output schema, the description provides the essential return value (sessionId) and the session semantics. An agent would know how to initiate a session and that the session persists. Minor missing details: how long the idle timeout is, and whether the session can be reused across different browser contexts, but these are not critical for correct invocation.

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

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

Schema description coverage is 71%, so most parameters (url, model, baseUrl, headless, userAgent, viewport) have meaningful schema descriptions. The tool description does not add extra parameter context, but that's acceptable given the schema's richness. The baseline of 3 is appropriate since the description adds no additional parameter-level value beyond what the schema already provides.

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

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

The description states the specific action ('Opens a new browser session') and the key output (returns sessionId). This clearly distinguishes it from siblings like browser_navigate or browser_snapshot, which operate within an existing session. The purpose is unambiguous and action-oriented.

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

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

The description explains the session's persistence ('stays alive across tool calls until closed or idle-timed-out') and implies this is the entry point for browser interactions. It does not explicitly state when not to use it (e.g., 'if you already have a sessionId, skip this'), but the context is clear enough for an agent to infer that. A small enhancement would be to mention that this should only be called once per interaction flow.

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 indicate this is a mutating operation (readOnlyHint=false). The description adds useful behavioral details about the 'clear' flag (replacing content) and 'submit' (pressing Enter), which go beyond the annotations. However, it doesn't disclose potential side effects like triggering input events or page 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 consists of two tightly written sentences with zero filler. The core action is front-loaded, and the addressing options are listed concisely without redundancy.

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

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

For a tool with 9 parameters and no output schema, the description covers the essential purpose and addressing strategies. It omits error handling or return values, but those are not critical given the full parameter documentation in the schema.

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

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

Schema coverage is 100%, so every parameter is already documented. The description reiterates the addressing modes (ref, css, role+name) but adds no new meaning beyond the schema. This aligns with the baseline of 3.

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

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

The description clearly states the tool types text into inputs/textareas and lists three addressing methods (ref, css, role+name). While it doesn't explicitly contrast with siblings like browser_press_key, the specific verb and resource make the purpose 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 is implied: use when you need to fill in a text field. However, there is no explicit guidance on when to prefer this over browser_press_key or other input tools, nor any mention of when not to use it (e.g., for non-editable elements).

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?

The description explains the waiting behavior but does not disclose what happens on timeout, the default timeout, or whether it returns a success/failure signal. The annotations (readOnlyHint: false) imply possible side effects, yet the description gives no insight into side effects or error handling, leaving a significant transparency 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?

The description is two sentences long, front-loads the core action, and has no filler. Every word contributes to understanding the tool's purpose and usage context.

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

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

For a tool with multiple optional conditions, a timeout parameter, and no output schema, the description is incomplete. It omits how conditions interact, the default timeout, and what the tool returns or does on failure. This leaves agents guessing about critical invocation details.

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

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

The schema covers 80% of parameters with descriptions. The description adds the semantic mapping of text, textGone, and selector to the three waiting modes, but it fails to state that exactly one condition should be provided, which is a critical constraint. It does not go beyond the schema's basic definitions.

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

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

The description clearly states the tool waits for one of three specific conditions (text appear, text disappear, selector visible), making the verb and resource explicit. It is easily distinguished from sibling tools like browser_snapshot or browser_query, which check state rather than wait.

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

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

The description says 'Use after actions that trigger async updates,' providing clear context for when to invoke the tool. It does not explicitly name alternatives or state when not to use it, but the guidance is actionable and sufficient for most agents.

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 provide readOnlyHint=false and openWorldHint=true, which are minimal. The description goes beyond these by disclosing a clear side effect ('The session is left on whatever page the agent ended on'), the report structure (success flag, summary, findings with severity/where/evidence), and that findings originate from both the agent and the harness (console errors, failed requests, dialogs). This adds substantial behavioral context, though it could mention failure handling or resource implications more explicitly.

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 paragraphs, with the core purpose and usage guidance front-loaded. It efficiently uses examples and explains the return format and side effects. While it is a bit lengthy, every sentence adds value: purpose, examples, return structure, and session side effect. It is well-structured 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?

For a delegation tool with five parameters and an output schema, the description covers the essential operational context: what it does, when to use it, what it returns, and side effects. The presence of an output schema covers return details, and the description mentions the session side effect for follow-up. It is slightly incomplete regarding error/timeout behavior, but adequate given the tool's complexity.

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

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

Schema description coverage is 100%, so all five parameters (sessionId, instruction, model, maxSteps, expectation) already have descriptions. The tool description does not add parameter-specific semantics beyond giving usage examples for 'instruction' and mentioning the report structure, which is not parameter-relevant. Since the schema carries full parameter meaning, the baseline is 3; the description does not exceed it.

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

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

The description states a specific verb ('Delegates a multi-step UI task to a fast built-in browser agent') and resource (UI task), with concrete examples. It clearly distinguishes from siblings by contrasting with 'driving each click yourself' and listing browser_* tools as the step-by-step alternative. An agent can immediately understand the tool's unique role.

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

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

The description explicitly says 'Use it for goal-shaped work' and provides two concrete examples ('log in as demo@example.com and check the dashboard loads', 'walk the checkout flow and report anything broken') versus driving clicks. It implicitly tells when not to use it (for step-by-step control) via the contrast with browser_* tools, giving clear selection guidance.

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