AIHawk

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

Describes behaviors beyond the annotations: scrolling into view, waiting for clickability, and clicking only the first matching element. The annotations already indicate a destructive, non-read-only operation, and the description adds useful execution context without contradicting them.

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

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

Two short, purposeful sentences front-load the core action, followed by behavior details and the alternative tool reference. No redundant wording or unnecessary explanation.

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?

Combined with annotations and the output schema, the description covers the key behavioral guarantees and routing guidance. The only notable absence, the return value, is already addressed by the presence of an output schema.

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

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

The description clarifies that 'selector' means a CSS selector and that matching is scoped to the first element. The browser parameter is already documented in the schema with its default and possible values, so the description adds enough meaning for the undocumented 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?

States a specific verb and resource: 'Click the first element matching a CSS selector.' It clearly identifies the tool's function and is distinguishable from sibling browser_click_at, which is explicitly referenced as a coordinate-based alternative.

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

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

Provides explicit guidance: when no selector can describe the target, use browser_click_at with coordinates from browser_snapshot. This names the alternative and the condition that selects it, giving an agent clear decision criteria.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds critical behavior beyond that: it moves the pointer first (no teleport), does down/up, holds if hold_seconds is set, returns a screenshot, and crucially discloses that coordinates are viewport-relative and go stale, with no exception raised on staleness. This is exactly the kind of behavioral context an agent needs and is not provided by 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 structured with purpose first, then mechanics, then critical caveats, then alternative routing. Each sentence earns its place—no filler. The front-loaded purpose and explicit contrast with the sibling make it immediately scannable for an agent.

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 coordinate-click tool with no output schema, the description covers the essential context: how the click is performed, coordinate system, staleness risk, error behavior, and the recommended alternative. Nothing an agent needs to decide when and how to call 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 only 25% (only 'browser' has a description). The description compensates by clarifying x/y as raw viewport coordinates (relative to viewport, not page) and explains hold_seconds behavior. It doesn't specify units or allowed ranges, but it adds meaning beyond the bare schema, so a 4 is fair.

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

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

The description opens with a precise verb and resource: 'Click (or press-and-hold) a raw viewport coordinate instead of a selector' and immediately contrasts it with browser_click, its sibling. It names the exact use case (slider track, canvas-drawn captcha, precise point) and explicitly states it is an alternative to selector-based clicking, leaving no ambiguity.

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

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

It gives explicit when-to-use ('for targets a selector cannot reliably reach'), when-not-to-use ('prefer browser_click with the element's `selector` whenever it has one'), and a practical condition (take a fresh snapshot after anything that could have moved the page). This fully routes the agent to the correct tool in context.

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

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

Beyond the destructiveHint annotation, the description discloses important behavioral traits: the page is gone after closing, the other browser is not touched, and the browser's identity is preserved across close and reopen. This adds meaningful context about side effects and state persistence.

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 well-structured: the primary action comes first, followed by immediate side effects, then the useful identity-persistence behavior. Every sentence contributes meaningful information without unnecessary 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?

For a tool with one optional parameter, a clear output schema, and destructive annotations, the description covers all important behavioral aspects: what is freed, what is destroyed, what remains untouched, and how to reopen with the same or a different identity. Nothing essential is missing.

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

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

The input schema already fully documents the only parameter, including its default value and the main/support distinction. The description adds no additional parameter-level detail, so the schema-description coverage 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 clearly states the action: 'Close one browser and free what it was holding.' It is specific about the resource affected and distinguishes itself from sibling tools by emphasizing that only one browser is closed and the other remains untouched.

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

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

The description gives clear context about when to use the tool: to close a browser and free resources. It also clarifies the non-obvious follow-up behavior by explaining that browser_open with no arguments restores the same browser identity, and that passing a seed, proxy, or profile is needed for a different identity. It does not explicitly state exclusions, but the context is strong.

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

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

The description goes beyond the readOnlyHint annotation by detailing exactly which operations are refused (assignments to value/checked/selected, and click/dispatchEvent/submit/requestSubmit calls). It also warns that the refusal is not exhaustive and instructs the agent to report a bypass instead of using it, which is valuable behavioral nuance.

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

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

The description is front-loaded with the core purpose ('READ...'), then gives concrete use cases, then establishes boundaries and alternatives. Every sentence adds information an agent needs to use the tool correctly, and the longer length is justified by the nuanced read-only enforcement behavior.

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

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

Given that an output schema exists and the annotations already mark the tool as read-only, the description covers the remaining essential context: use cases, refusal behavior, alternative tools, and how to handle scripts that bypass the refusal. Nothing critical for correct invocation is missing.

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

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

The schema only documents the 'browser' parameter, leaving 'expression' with just a type of string. The description clarifies that the expression is JavaScript code executed to read from the page and that the result comes back as JSON, but it does not specify syntax details such as whether it must be an expression, how to reference page context, or how complex scripts are supported. This partially compensates for the low schema coverage but leaves gaps.

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

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

The description opens with 'READ from the page with JavaScript and get the result as JSON,' which uses a specific verb, a clear resource, and the expected output format. It also distinguishes itself from siblings by saying it sees 'what the other tools cannot see' and by pointing to alternative tools for acting on 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?

It explicitly states when to use this tool: to read computed styles, framework state, list lengths, or anything else other tools cannot see. It also explicitly says acting on the page is refused and directs the agent to browser_click, browser_type, or browser_select_option for those cases, making the when-not usage unmistakable.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it reports only open browsers, explains the 'focus' field, and clarifies that it starts nothing. This goes beyond the annotations by explaining the tool's side-effect-free nature and output semantics.

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 well-structured and front-loaded: it starts with the core question the tool answers, then details the JSON output, and ends with a clear note about side effects. Every sentence adds value, and the formatting with backticks and line breaks improves readability.

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

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

Given the tool has no parameters and an output schema exists, the description is complete. It explains the output fields, the meaning of 'focus', the behavior with multiple tabs, and the side-effect-free nature. An agent has everything needed to call and interpret this tool correctly.

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

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

The tool has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining the output structure (focus, note, browsers with id, url, urls), which is the only meaningful semantic content for a parameterless tool. Baseline 4 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 clearly states the tool's purpose: it reports which of the two browsers are open, their locations, and which one the agent is working in. It distinguishes itself from siblings by focusing on listing/status rather than actions like navigate or close.

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 when to use it: to check what is open and which browser is the focus. It also notes that it starts nothing and is free to call, implying it's safe to use as a status check. It doesn't explicitly name alternatives, but the sibling list makes it clear this is the listing/status 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?

The description goes well beyond the annotations, explaining that the tool returns the HTTP status and final landed URL, that redirects may lead to login walls or regional domains, and that 404/403 pages still have a document. It also discloses default and alternative wait_until behaviors. This is substantial value beyond the structured annotations.

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

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

The description is front-loaded with the core action, then layers in critical response semantics and parameter behavior. Every sentence adds necessary information, and there is no redundant or filler content. It is detailed without being bloated.

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

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

For a navigation tool with 3 parameters, the description covers the required behavior, return value highlights, and parameter tuning options. The presence of an output schema reduces the need to describe return fields, and the description still provides useful context about interpreting status codes. Nothing essential is missing for an agent to invoke the tool correctly.

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

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

Schema coverage is only 33%, and the description compensates by thoroughly explaining wait_until values and their behavioral implications. The 'url' parameter is contextually implied as the destination URL, and the 'browser' parameter is already described in the schema. It does not add formal URL format guidance, but the provided semantics are sufficient for correct invocation.

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

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

The description states a specific verb and resource: 'Go to a url in this browser's page, opening it if none exists.' It clearly differentiates from sibling tools by emphasizing navigation within an existing page and the ability to open one if needed. The title and description align without being tautological.

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

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

The description gives clear context on when to use this tool and how to tune wait_until for different page types, such as 'load' for images and stylesheets or 'networkidle' for single-page apps. It does not explicitly name sibling alternatives or exclusion cases, but the behavioral context is strong enough to guide selection.

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

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

The description goes beyond the `destructiveHint: true` annotation by specifying exactly what is lost on reopen: the previous browser state is gone. It also discloses that `support` is ephemeral and that a profile does not pin its exit, making cross-device login behavior visible. 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 prose is dense but purposeful: each sentence introduces a distinct behavioral fact, and the parameters are formatted as a scannable list. It front-loads the core action and lifecycle rule before diving into parameter details, with no filler.

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

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

For a stateful, destructive browser tool with four optional parameters, the description covers selection, lifecycle, identity persistence, proxy behavior, and side effects. The presence of an output schema means the return format does not need to be explained here.

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 only 25%, so the description carries the burden for `seed`, `profile`, and `proxy`. It explains each parameter's meaning, the default behavior when omitted, the empty-string semantics, and the interplay between profile and proxy. This far exceeds the bare 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 opening sentence specifies the exact resources (`main` or `support`) and the two core actions: open, or reopen as a different identity. This distinguishes it clearly from siblings like `browser_close`, `browser_navigate`, and `browser_status` without needing to inspect them.

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

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

The description explicitly says when to open `support` ('when the task needs a second identity'), instructs to close it with `browser_close` before answering, and states that `support` is not saved. This gives the agent a clear lifecycle policy and prevents resource leaks.

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 signal mutability and destructive potential (destructiveHint=true, readOnlyHint=false). The description adds the important behavioral qualifier 'whatever has focus' and lists accepted key forms, but it does not disclose side effects like form submission from Enter or other shortcut-triggered actions. With annotations carrying the safety profile, 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 one compact, front-loaded sentence that names the action and target, then provides a scannable list of examples. Every element earns its place; there is no filler or repetition.

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

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

For a simple two-parameter tool with one required key and an optional browser, the description, schema, and annotations together provide enough to invoke it correctly. An explicit note about destructive side effects would improve completeness, but the destructiveHint annotation already covers the risk.

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 only documents the browser parameter, leaving the required key parameter undocumented. The description compensates by enumerating accepted special keys, showing modifier syntax like 'Control+a', and allowing single characters. This adds meaning beyond the bare string type in the schema.

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

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

The description states a specific action ('Press a key'), identifies the target ('on whatever has focus'), and enumerates concrete valid inputs such as 'Enter', 'Tab', and 'Control+a'. This clearly differentiates it from sibling tools like browser_type or browser_click, which handle text entry and pointer actions.

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

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

The description gives clear context: use this when you need to send a discrete key press or keyboard shortcut to the currently focused element. It does not explicitly contrast with browser_type for multi-character text input, but the examples and focus qualifier make the intended usage reasonably unambiguous.

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

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

Annotations already declare readOnly, openWorld, and destructive=false, so the description needs to add operational behavior. It does: the tool returns a cleaned, uncapped page that can be tens of thousands of characters, and it explains why the output is not cut (broken markup). That is useful context beyond the annotations, though things like error behavior or format details are left to the output schema.

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

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

The text is paragraph-heavy but every sentence earns its place. It is front-loaded with the core purpose, then gives usage guidance, mode semantics, and a size caveat before pointing to the sibling. It is not as snappy as it could be, but it is not bloated either.

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 that an output schema is present and annotations carry the safety profile, the description covers the remaining ground: purpose, mode differences, uncapped/truncated behavior, and sibling routing. It is complete enough for an agent to call the tool correctly without additional external knowledge.

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 only describes the 'browser' parameter and gives no detail on 'mode', but the description fully explains the mode values: 'form' keeps the interactive surface, 'text' returns prose alone, 'full' preserves structure while removing noise and attribute soup. The browser parameter is adequately covered by the schema description, so the description adds value where the schema is silent.

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: 'The page's HTML, cleaned down to what is worth reading.' It also differentiates from siblings by explaining what browser_snapshot and browser_read_text do differently, so an agent doesn't need to open their schemas to tell them apart.

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

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

It explicitly says to use this tool 'when the STRUCTURE matters' and points to browser_snapshot when the agent only needs something to click. It also calls out browser_read_text as the uncapped alternative. These explicit when-to-use and when-not-to-use conditions leave no room for ambiguous selection.

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

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

Annotations already provide readOnly and destructive hints, so the bar is lower. The description adds real behavioral context beyond annotations: the output is stripped of markup, is the 'cheapest way to read a page,' and long text is truncated at max_chars with a marker that signals truncation. This is useful operational detail not present in the structured metadata.

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

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

Four sentences, front-loaded with the core definition. The alternatives paragraph and the truncation behavior paragraph are each necessary and non-redundant; no filler.

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

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

For a read-only tool with 3 optional parameters and an output schema, the description covers what text is returned, how to target it, when to choose another tool, and how to detect truncation. Nothing essential for correct invocation is missing.

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

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

Schema coverage is only 33% (browser is described), but the description compensates for the other two parameters: max_chars gains truncation and marker semantics, and selector gains purpose via 'Narrow the selector when you know where the answer is.' It doesn't specify selector syntax, but it covers the missing parameters meaningfully enough.

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

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

The description opens with a precise definition: 'The visible text of an element, with the markup gone.' It names sibling tools browser_read_html and browser_snapshot and differentiates them by structure versus clickability, so an agent can distinguish this tool from close alternatives without opening 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?

It gives explicit when-to-use advice: 'Narrow the selector when you know where the answer is' and explicitly routes structure needs to browser_read_html and click needs to browser_snapshot. This is direct usage guidance with named alternatives and conditions.

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

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

Annotations already signal mutation with readOnlyHint=false and destructiveHint=true. The description adds useful behavioral context by stating this tool performs a 'real interaction' that the page observes, unlike browser_evaluate. It does not contradict the annotations and clarifies the interaction model.

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 filler: the first states the action and key parameter semantics, the second gives a compact, useful rationale for preferring this tool over alternatives. Every clause earns its place.

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

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

The description is sufficient for the core task: it specifies what to select, how to identify the option, and why this tool should be used over siblings. It does not describe selector formatting or error behavior, but the output schema exists and sibling conventions likely supply the rest.

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 low (33%), so the description must compensate. It meaningfully clarifies the `value` parameter by saying it can be either a visible label or an option value, but it leaves the `selector` parameter format (e.g., CSS selector) unstated. This is partial compensation for the undocumented 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 uses a specific verb ('Choose') and resource ('an option in a dropdown (`<select>`)') and explicitly states the two identification modes: visible label or value. It also distinguishes itself from clicking with arrow keys and from browser_evaluate, making its 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?

The description explicitly says 'Use this rather than clicking the dropdown and pressing arrow keys' and explains why browser_evaluate is unsuitable ('changes it without the page seeing a real interaction'). This gives clear when-to-use and when-not-to-use guidance relative to named 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?

The description adds valuable behavioral detail beyond the annotations: selectors are 'built to match exactly ONE element,' the driver acts on the first match, and elements without a selector carry center coordinates for browser_click_at. It also discloses the visible-only limitation and the reason for avoiding the accessibility tree. This is strong, practical behavioral transparency.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The subsequent detailed behavior about selectors and first-match semantics earns its place because it prevents incorrect tool invocation. It could be slightly tighter, but there is no wasted 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?

With an output schema present, the return format is largely covered, and the description provides the critical caveats about selector uniqueness and first-match behavior. The only missing piece is the meaning of `max_chars`, which is optional and has a default, so the tool remains callable without it. Overall, the description is strong for 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 only 50%; `browser` has a schema description but `max_chars` has none. The tool description does not explain `max_chars` at all, nor does it clarify the relationship between the parameters and the snapshot output. This leaves a meaningful gap for the agent.

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 resource and output: 'Title, url, and the interactive elements that are actually visible.' It also distinguishes the tool from a raw accessibility dump by explicitly saying it is 'not the accessibility tree,' which helps differentiate it from read_text/read_html. It lacks an explicit imperative verb, but the intent is unambiguous.

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

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

The description implies usage by stating 'It lists what a caller can act on,' suggesting it should be used before clicking or typing. It also explains why the accessibility tree is not used, which gives context for its filtering behavior. However, there is no explicit when-to-use or when-not-to-use guidance relative to sibling tools like browser_read_text or browser_take_screenshot.

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 destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: 'It starts nothing' and 'a browser that is not open, or gone, is answered with the sentence that says which.' This tells the agent the call is side-effect-free and how missing state is reported.

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

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

The description is compact and front-loaded with a clear one-line summary. The additional sentences about the seed and the closed-browser behavior each add useful context without repetition. It is somewhat poetic but remains efficient.

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 presence of an output schema and read-only annotations, the description provides enough operational context: what the status contains, when to call it, and what happens if no browser is open. The only minor gap is not detailing the 'exit' or 'profile' semantics, but the output schema can carry that.

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

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

Schema description coverage is 100%, and the schema already explains the single optional parameter: 'Defaults to `main`; `support` is the helper beside it.' The tool description does not add much about parameter semantics, but with full schema coverage the 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 clearly identifies what the tool reports: 'the identity, the exit, the profile and the page' of the current browser, and frames it as a status query. It is distinguishable from the action-oriented siblings like browser_open or browser_navigate, though it does not explicitly name a sibling to contrast with.

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 states 'Ask whenever you need to know which person the browser currently is, or from where its traffic leaves,' giving clear when-to-use guidance. It also explains the relationship to browser_open via the seed concept. It does not explicitly mention when not to use this tool, but the guidance is sufficient for an agent.

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 destructiveHint=false, so the safety profile is covered. The description adds that this is a single, on-demand capture rather than a continuous watch, but it does not clarify output format, viewport behavior, or whether any page-load waiting occurs.

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 with no filler. Every word adds meaning: 'one', 'screenshot', 'this browser's page', and 'on demand'.

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

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

For a simple, read-only, single-parameter tool with annotations covering the safety profile, the description is largely complete. It is slightly incomplete in that it does not mention what the screenshot returns (e.g., image data or a file reference) and does not distinguish itself from browser_snapshot.

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

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

Schema description coverage is 100%, and the parameter description already explains the 'main'/'support' browser options and default. The tool description itself adds no further meaning to the parameter, so the schema carries the burden as expected.

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 ('take screenshot') and resource ('this browser's page'), making the core action clear. It does not explicitly differentiate from the sibling tool 'browser_snapshot', which could be mistaken for a similar action.

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 given on when to use this tool versus alternatives like browser_snapshot, browser_read_html, or browser_watch. The phrase 'on demand' is the only hint, but it does not explain when a screenshot is preferable or when not to use it.

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

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

Annotations already indicate this is a destructive, non-read-only action. The description adds valuable behavioral context by explaining that it sets the value rather than typing, so it does not fire per-keystroke handlers. This is a key behavioral trait beyond what annotations provide, and it helps an agent understand side effects. It could mention more (e.g., blur events), but it adds solid value.

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, front-loaded with the core action, and contains zero filler. It efficiently conveys the main purpose and the critical exception, making it highly scannable for an agent.

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

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

For a simple tool with 3 parameters (2 required) and an output schema, the description covers the primary behavior and the main alternative. It does not discuss error cases (e.g., selector not found) or prerequisites like element visibility, but these are minor given the tool's simplicity and the presence of an output schema. It is reasonably complete for an agent to invoke 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?

The input schema has only 33% description coverage (only the 'browser' param is described). The description does not explain the 'selector' or 'text' parameters at all, and the schema provides no descriptions for them. Since coverage is low, the description should compensate, but it does not. The agent must infer from names alone, which is insufficient.

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 function: 'Fill a field, replacing whatever it holds.' It uses a specific verb ('fill') and a clear resource ('field'), and it distinguishes itself from sibling tools by explicitly contrasting with browser_press_key, which types key-by-key. This makes the purpose unambiguous and differentiates it from related actions.

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

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

The description provides an explicit alternative and a condition for when NOT to use this tool: 'For those, click the field and use browser_press_key.' It implies the primary use case is when you want to set a value directly without triggering per-keystroke handlers. It does not list all possible use cases, but the exclusion is clear and helpful.

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 read-only and non-destructive, and the description adds substantial runtime detail: it is a live capture kept running, called many times a second, outputs window pixels rather than page coordinates, and returns an idle response when no browser window exists. This goes well beyond the annotation flags and does not contradict them.

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

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

The description is compact and front-loaded: purpose first, usage warning second, idle behavior third. However, phrases like 'answers the sentence that says so' and 'live panes' are opaque and make the final sentence harder to parse than 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?

The description covers the view contents, the coordinate warning, the no-start behavior, and the closed-browser case, which is strong for a one-parameter tool. With no output schema, though, it leaves the result format somewhat ambiguous, mixing the idea of a live visual capture with the notion of answering with a sentence.

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 only parameter, browser, is already fully described in the input schema, including the default of main and the meaning of support, and schema description coverage is 100%. The description adds no parameter-specific meaning, so the schema carries the semantic burden.

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

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

The description defines the tool as showing the whole browser window as a person sees it, including tab strip, address bar, page, and pointer, from a live capture. It explicitly separates watching from acting and distinguishes itself from browser_take_screenshot and browser_click_at, so an agent can tell it apart 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?

It states directly 'For watching the work, not for acting on it' and gives an explicit exclusion: do not feed its coordinates to browser_click_at; use browser_take_screenshot for that. It also says 'Starts nothing,' clarifying that this tool is not a substitute for opening a browser.

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