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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutation/open-world profile is known. The description goes beyond them with genuinely additive context: WebMCP tools are site-supplied code and their output is untrusted ('the site's word'), and CONSEQUENTIAL ones can place orders, payments, or messages. It stops short of timeout/error semantics or how to handle a consequential prompt.

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: the action and its argument source come first, then a compact risk disclosure. Every clause earns its place and nothing is repeated from the schema or annotations.

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

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

No output schema exists, and the description does cover the nature of returns (untrusted site-authored output) without describing their shape. For an open-world dispatcher this is close to complete; it lacks only notes on call failure/timeout behavior, which the timeoutMs parameter implies but never explains.

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 adds real value by pointing the agent at browser_tool_schema as the source of truth for the 'arguments' object, which the schema itself only refers to abstractly as 'the tool's input 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 (runs/calls a tool) plus the exact resource class (a tool from browser_list_tools) and the execution target (the session's page). It names the two sibling tools in the discovery flow, so an agent can distinguish it from browser_list_tools and browser_tool_schema 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?

The description implies the intended workflow (list tools, read schema, then call) and flags the condition that matters most: tools marked CONSEQUENTIAL take real actions. It does not, however, say when to prefer this dispatcher over siblings like browser_evaluate or run_task, nor any explicit when-not-to-use case.

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 (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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely new behavioral context: webmcp tools are read live and change as the page navigates, and devtools tools are executed by this server with no separate MCP server to configure. It does not describe the shape or volume of the returned list, which is a minor 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?

Front-loaded with the verb and resource, then a compact closing instruction about the follow-up calls. Dense but every clause carries information; the em-dash parenthetical about devtools capabilities is the one place it sprawls slightly.

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 burden of describing returns and does so by giving the qualified-name formats and noting that webmcp results are volatile as the page navigates. It does not say whether results are paginated, bounded, or error-prone when no page is loaded, leaving a small completeness gap for a 2-parameter, session-scoped listing tool.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents sessionId and the source enum. The description nevertheless adds meaning by explaining what the webmcp and devtools categories actually contain, which is the semantic key to choosing a source filter value.

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 — listing tools that run against the session's page — and partitions the result into two clearly named namespaces, "webmcp.<name>" versus "devtools.<name>". It further differentiates itself from the sibling tools it feeds into (browser_tool_schema, browser_call_tool), so an agent can place it precisely in the tool landscape.

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?

Lays out an explicit call sequence — list here, then browser_tool_schema, then browser_call_tool — which tells the agent when this tool belongs in a workflow. It stops short of saying when not to use it or how it relates to the similarly named sibling browser_list, so the guidance is strong but not complete.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context not in the annotations: what each entry contains (status, size, duration), how WebSockets are represented as WS entries with frame counts, and the #id handoff to browser_request_detail. It stops short of describing truncation or limit behavior beyond 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?

Three tight sentences, front-loaded with what is listed, followed by the detail-tool handoff and the filtering options. Every sentence carries information; nothing is 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?

There is no output schema, and the description partially compensates by sketching the shape of each entry and the special WS rows, which is exactly the gap an agent would otherwise face. Combined with annotations covering safety and a fully documented schema, only minor gaps (ordering, pagination/limit behavior) remain.

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, including the enum meanings for 'status' and the substring semantics of 'filter'. The description restates the two filter modes without adding format, defaults, or edge cases beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Lists network requests the session has made') plus the fields returned (status, size, duration), and distinguishes itself from sibling browser_request_detail by explaining that each line carries an #id for that tool. An agent can tell the two apart without opening either schema.

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

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

The description implies usage by describing the two filtering modes (URL substring, failure status) and the WS entry case, but it never states when to reach for this tool versus browser_request_detail or browser_console. Guidance is inferable rather than 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 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?

Annotations already cover the read-only/open-world safety profile, and the description adds real behavioral detail beyond them: small text responses remain readable after navigation due to caching, and WebSocket entries return a frame stream regardless of the part requested. Rate limits or paging behavior are not described, but the annotations plus these notes make the behavior reasonably transparent.

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

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

Three tight sentences with no filler, and the core action is front-loaded. The caching and WebSocket sentences each carry distinct, useful information rather than restating 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, so the description carries the return-value burden; it names what each part yields and calls out the WebSocket special case. It stops short of explaining paging (offset/maxChars) or response size limits, but covers the essentials for correct invocation.

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

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

Schema coverage is 80%, so the baseline is 3, but the description adds semantic mapping for the part values (headers, timing, request/response body) and explains the special frames case for WebSocket entries. Minor mismatch: it says 'timing breakdown' while the enum exposes 'summary'.

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 (inspects) and resource (one request from browser_network) and enumerates the fetchable parts: headers, timing, request body, response body. It also distinguishes itself from the sibling browser_network, which produces the #id this tool consumes.

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?

Implies the ordering: use browser_network first to obtain the #id, then call this to inspect a single entry. It also routes WebSocket entries (shown as WS) to the frames part. No explicit when-not-to-use or fallback, but the 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?

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 declare readOnlyHint=false and openWorldHint=true but say nothing about lifecycle. The description adds genuinely useful behavioral context: the session persists cookies/storage/page state across calls and ends only on close or idle timeout, and it clarifies the return contract (sessionId). It does not disclose auth, permissions, or resource costs.

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 the core purpose and return value front-loaded, followed by the persistence/idle-timeout nuance. No filler or repetition of the title; the only slight excess is the parenthetical state list, which still 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 an 11-parameter, zero-required session-creation tool with no output schema, the description covers purpose, lifecycle, and the returned sessionId adequately, while the schema handles parameter semantics. It could more explicitly guide interaction with sibling tools, but nothing critical for calling it correctly is missing.

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

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

Schema description coverage is 82%, above the 80% threshold, so the schema already documents nearly all 11 parameters with rich per-field context (cdpUrl, tab takeover, devtools, useBrowserProfile, etc.). The description adds no parameter-level detail beyond the schema, so the baseline of 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 ('Opens a new browser session') and adds the return value ('returns its sessionId'). It implicitly distinguishes itself from browser_close via the lifecycle note, but does not explicitly name siblings like browser_navigate or browser_list, so it stops short of full differentiation.

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

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

The lifecycle statement ('stays alive across tool calls... so you can interact with the same page over many turns') implies this is the entry point for subsequent browser work but never states explicitly when to call it versus alternatives such as attaching via cdpUrl, using an existing profile, or navigating with browser_navigate. Usage is inferable but not prescribed.

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 safety profile is covered. The description does not add anything beyond that, such as behavior on an invalid or unknown tool name, so with annotations doing the work 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?

A single front-loaded sentence with zero filler that both states the result and illustrates the name format. Nothing is padded or redundant.

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

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

With no output schema, the description helpfully discloses what is returned (full description plus JSON input schema) and where names come from. It omits error behavior for an unknown tool name, 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 the baseline is 3, but the description adds format-level meaning by giving concrete qualified-name examples ('webmcp.search', 'devtools.performance_start_trace') that go beyond the schema's 'Qualified tool name from browser_list_tools'.

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

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

The description states a specific verb+resource: it returns the full description and JSON input schema of a named tool. It also ties itself to the sibling browser_list_tools as the source of valid names, though it does not distinguish itself from other schema/introspection siblings explicitly.

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 implies a clear two-step workflow by stating the name must come from browser_list_tools, which gives the agent a prerequisite. It does not state when-not to use it or name a competing alternative, so it falls short of a 5.

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

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

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.