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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal one important behavioral trait: the challenge is forwarded to an external configured solver at PILOT_CAPTCHA_SOLVER_URL. However, it does not state whether the tool waits for a solution, returns a token, mutates the page, fails if no solver is configured, or performs any network/authorization side effects.

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 no filler. Every element—verb, resource, and solver configuration—earns its place, and the parenthetical configuration reference is compact yet informative.

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 there are no annotations, no output schema, and three parameters to understand, the description is incomplete. It does not explain what happens after forwarding, what a successful or failed solve looks like, or which captcha types are accepted beyond the schema enum. An agent would still need substantial inference to call this tool confidently.

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 0%, so the description must compensate for explaining siteKey, pageUrl, and type. It does not mention any parameter names or explain how each field contributes to the forwarded captcha challenge. The phrase 'captcha challenge' hints at the domain but adds no meaningful parameter-level semantics beyond the schema's field names and enum.

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 ('Forward') and a specific resource ('a captcha challenge to the configured solver'), making the tool's function immediately clear. It also differentiates itself from the sibling browser tools by naming the captcha-solving delegation behavior rather than navigation, clicking, or typing.

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?

There is no explicit statement about when to use this tool versus alternatives. The name and sibling list imply it should be used when a captcha challenge is encountered, but no exclusions or alternatives are mentioned, leaving usage 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It states only that a click is performed, but omits any side effects such as page navigation, waiting for elements, scrolling into view, or failure behavior. It also does not indicate whether the click is synchronous or whether it returns any confirmation. This is a significant gap for a browser automation tool.

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

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

The description is a single sentence that front-loads the action and identification methods, immediately followed by the recommendation to prefer `ref`. There is no filler or redundancy; every word earns its place. It is concise without sacrificing essential detail.

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 browser interaction tool, the description is too thin. It does not mention post-click behavior (e.g., page load waiting, need to refresh snapshot), error handling, or whether the click is relative to the viewport. Given the absence of an output schema and annotations, the description leaves the agent guessing about important execution details. It is adequate for a trivial click but incomplete for real-world automation scenarios.

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 lists four parameters with no descriptions (schema coverage 0%), so the description must compensate. It does so by clarifying that `ref`, `selector`, and (x, y) are alternative ways to identify the element, and explicitly recommends `ref` from browser_snapshot. This adds meaning beyond the raw schema by explaining the relationship between parameters and providing a priority hierarchy.

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 (click) and the resource (an element), and specifies three distinct identification methods (snapshot ref, CSS selector, coordinates). It is unambiguous about what the tool does and naturally distinguishes from sibling tools like hover or type. The mention of preferring `ref` from browser_snapshot adds operational clarity.

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 no guidance on when to use this tool versus alternatives such as browser_hover or browser_type. The only usage hint is the preference for `ref` over other identifiers, but that is a parameter-selection hint, not a tool-selection criterion. There is no mention of scenarios where coordinates or selector might be preferable, nor any 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?

There are no annotations, so the description must carry the behavioral burden. 'Read' implies a non-mutating operation and 'captured' indicates that messages are pre-recorded from the session, but the description does not say whether the console buffer persists across navigations, how stale the captured messages are, or what the tool returns when the console is empty.

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 sentence that states action, object, and scope with no filler. It is appropriately sized for the tool's simplicity.

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

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

For a read-only console reader with optional filter parameters, this is a workable description, but it omits usage context, output format, and behavioral expectations such as message retention. It is adequate but leaves an agent to infer several things before calling.

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 0% and the description does not mention level or limit. The parameter names and the level enum are reasonably self-evident, but the description adds no meaning to the filters or bounds, so an agent must infer semantics from names and defaults alone.

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 ('read') with a clear resource ('console messages') and a scoping qualifier ('current session'). It is meaningfully distinct from siblings like browser_network or browser_evaluate, though it does not explicitly name or contrast 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?

There is no guidance on when to use this tool versus browser_evaluate or browser_network, and no mention of prerequisites such as having navigated first. The only contextual hint is 'current session,' which implies scope but not selection 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. 'Drag from one element to another' implies an interaction, but it does not describe side effects, whether events are triggered, whether the action is reversible, or what the tool returns. This is comparable to a mutation tool that states its action without explaining consequences.

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 very concise and front-loaded, with no filler. Both clauses earn their place by stating the action and the accepted input modes. It is efficient, though slightly underspecified.

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 no annotations, no output schema, and four undocumented optional parameters, this description is not complete. An agent would need to infer prerequisites such as needing a snapshot first, the effect of the drag, and what happens on success or failure.

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

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

With 0% schema description coverage, the description must compensate. 'Accepts snapshot refs or selectors' adds useful meaning by explaining the two addressing modes, but it does not map these to fromRef/toRef and fromSelector/toSelector, clarify whether the modes are exclusive, or describe how the from/to pairs relate.

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 ('Drag') and resource ('from one element to another'), which clearly identifies the tool's core action and distinguishes it from siblings like browser_click and browser_hover. However, it does not explicitly differentiate itself from alternatives or state what makes it unique beyond the drag 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 provided about when to use this tool versus browser_click, browser_hover, or browser_select. The description mentions that it accepts snapshot refs or selectors, but does not explain when one addressing mode is preferred or whether both are required.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the page context and the JSON-serializable result, but it does not warn that arbitrary JS may mutate page state, trigger navigation or network requests, or fail on non-serializable values.

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: it states the action, the target context, and the return behavior. Every word contributes.

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 annotations and no output schema, the description should explain side effects, error behavior, and return-value limitations. It only covers the happy path, leaving an agent without enough information to use the tool safely and correctly.

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

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

The schema only defines 'expression' as a string, so the description adds meaning by identifying it as a JS expression. However, it does not clarify expected syntax, async handling, or how return values are serialized, so it only partially compensates for the 0% 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?

States a specific verb, 'Run', and a specific resource, 'a JS expression in the page context', while also describing the return behavior. This clearly distinguishes it from sibling tools like browser_click and browser_snapshot.

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 does not say when to prefer this over browser_console, browser_snapshot, or other siblings, and it gives no exclusions. The intended use is only implied by the phrase 'JS expression', not stated.

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

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

No annotations are provided, so the description carries the full behavioral transparency burden. It does disclose that the tool uses Playwright's fill() and accepts a selector or snapshot ref, but it omits side effects, actionability requirements, error behavior, or return value. This is thin for an unannotated mutation tool.

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

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

The description is one sentence with no filler, and the core mechanism and locator options are front-loaded. Every phrase adds 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 an unannotated tool with no output schema and 0% schema coverage, this description is incomplete. It does not warn agents that calling with only 'value' is accepted by the schema but likely useless, nor does it describe what happens on success or failure.

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 0%, so the description must compensate. It usefully explains that selector and ref are alternative locator strategies, but it does not clarify whether one is required, whether they are mutually exclusive, or what constraints apply to the required 'value' 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 identifies a specific verb ('replace'), a clear resource ('an input value'), and the underlying mechanism (Playwright's fill()). It does not explicitly distinguish itself from siblings such as browser_type, but 'replace' and 'fill()' convey whole-value overwrite semantics clearly.

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 about when to use this tool versus alternatives like browser_type or browser_click. The only clue is the word 'replace', which implies usage but never states exclusions, prerequisites, or when to prefer a different browser 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Hover an element' without explaining side effects, prerequisite visibility, scroll-into-view behavior, timing, or how failures are reported. The action type is obvious from the name, but the behavioral consequences are undisclosed.

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 short sentences with no filler. The core action and the two targeting mechanisms are front-loaded, making it easy to scan. 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 tool with two optional string parameters and no output schema, this is minimally adequate but has clear gaps. The description tells the agent what action to perform and how to specify the element, but not when to prefer one parameter over the other or what observable behavior to expect. The lack of annotations and schema descriptions leaves important context uncovered.

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 0%, and the two parameters have no descriptions. The description partially compensates by saying the tool accepts 'a snapshot ref or a selector,' which clarifies that ref and selector are alternative ways to target an element. However, it does not define what a snapshot ref looks like, how to format a selector, or what happens if both are provided.

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

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

The description states the specific verb 'hover' with the resource 'element,' which clearly differentiates it from sibling tools like browser_click, browser_type, and browser_drag. Adding that it accepts a snapshot ref or selector further disambiguates its purpose. This is a one-sentence, fully clear purpose statement.

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 about when to use this tool versus browser_click or other interaction tools, nor are any exclusions or prerequisites mentioned. The phrase 'Accepts a snapshot ref or a selector' is input guidance, not usage-direction. The agent is left to infer appropriate hover scenarios.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It states only that a URL is opened, but does not mention whether the tool waits for page load, how it handles redirects or failures, or what state changes occur in the browser session.

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 short, front-loaded sentence with no wasted words. It is appropriately concise for such a simple tool, though some behavioral detail would justify more 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?

Given the low complexity and single parameter, the description captures the basic action, but it omits important operational context such as whether navigation blocks until loading completes and whether the current page context is replaced. With no annotations and no output schema, these gaps leave the agent without enough information to predict downstream 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 description coverage is 0%, and the description merely repeats the word 'URL' without adding guidance about required format, whether schemes must be present, or how the URL is interpreted. The schema's format: uri already conveys most of the parameter 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?

The description states a specific verb ('open') and resource ('a URL in the browser'), which clearly identifies the tool's core function among the browser operation siblings. However, it does not explicitly clarify whether navigation happens in the current tab or a new tab/window, leaving some ambiguity about the exact behavior.

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 about when to use browser_navigate versus sibling tools such as browser_evaluate or browser_wait. The usage context must be inferred entirely from the tool name and the sibling list.

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?

No annotations are provided, so the description carries the full burden. It adds that requests are 'captured' and scoped to the 'current session,' but does not disclose what types of requests are included, whether static resources are captured, or any side effects or return behavior. The read-only nature of 'list' helps, but critical behavioral details are missing.

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. It conveys the action, resource, and scope efficiently, earning every word.

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?

Despite being a relatively simple read tool, there is no output schema, no annotations, and an ambiguous 'static' parameter. The description does not explain what the returned data looks like or what 'static' filters, leaving an agent without enough information to use the tool confidently.

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 0% and the description mentions neither 'limit' nor 'static.' The schema only provides names and defaults; 'static' in particular is left completely ambiguous. The description adds no meaning beyond the schema and fails to compensate for the lack of parameter documentation.

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 ('List') and resource ('network requests'), and narrows scope to 'captured for the current session.' This clearly distinguishes it from the action-oriented sibling tools like browser_navigate and browser_click.

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 is clear: use when you need to inspect network requests from the current session. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives, so an agent must infer the appropriate context 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?

No annotations are provided, so the description carries the full behavioral burden. It only states that a key is pressed, without disclosing whether the action targets the focused element, whether it can trigger page navigation or form submission, or how the key event is delivered. This is a meaningful gap for a tool that sends input to a browser.

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 conveys the essential operation and examples. It is front-loaded with the action and resource, and no words are wasted.

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

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

For a one-parameter tool with no output schema, this is minimally adequate: an agent knows what to call and roughly which keys are valid. However, the lack of annotations and the absence of exact key syntax or behavior side effects leave some ambiguity for correct invocation, especially for less obvious keys or modifier combinations.

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

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

With 0% schema description coverage, the description must compensate for the bare 'key' string parameter. It does so by clarifying that the key must be non-text and by listing valid examples. It stops short of specifying exact key-name syntax or all supported special keys, but it adds substantial meaning 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?

The description clearly states the action ('Press'), the resource ('a non-text key'), and gives concrete examples (Enter, Tab, Escape, arrows). The phrase 'non-text' implicitly distinguishes this from sibling browser_type, making it easy for an agent to identify the tool's 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 usage context is implied by 'non-text key' and the examples, so an agent can infer this is for keys that insert no text. However, the description does not explicitly mention alternatives such as browser_type for text input, nor does it state when not to use this 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?

With no annotations, the description carries the behavioral burden; it at least discloses that output is base64 or a file written to savePath, and that the image is PNG. It does not mention whether the tool scrolls, waits, or changes page state, nor explain the default capture region or full-page behavior.

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 short front-loaded sentence conveys the core action and output mode with no filler. It is concise, though the completeness trade-off is substantial.

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 no output schema and bare string/boolean parameters, the description leaves key invocation details unexplained: element selector semantics, fullPage effect, default viewport behavior, and interaction consequences. It is adequate only as a minimal stub.

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 0%, so the description must compensate for the bare schema. It only mentions savePath ('if savePath is set') and leaves element and fullPage completely undeclared, forcing the agent to guess their formats and behavior.

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: 'Capture a PNG screenshot', and reports the output format. However, it does not explicitly differentiate from the sibling browser_snapshot, whose name could imply a similar visual-capture role, so clarity is strong but not maximal.

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 only guidance is the conditional 'saves to disk if savePath is set', which is parameter behavior rather than a usage policy. There is no statement of when to choose this over browser_snapshot, browser_evaluate, or other siblings, and 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?

No annotations are provided, so the description carries the full burden. It reveals the selection mechanism (value/label, snapshot ref/selector) but does not disclose side effects such as event dispatch, state changes, failure behavior, or whether selection replaces or requires existing page state.

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 core action front-loaded. Every phrase earns its place, and there is no filler or redundant restating of parameter names.

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 four optional, undocumented parameters and no annotations or output schema, the description is too thin. Missing guidance on parameter relationships, required conditions, and expected behavior leaves an agent to guess how to invoke 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 description coverage is 0%, so the description must compensate. It adds meaning by mapping label/value to selection criteria and ref/selector to target location, but it does not explain whether the parameters are mutually exclusive, optional in combination, or how precedence works when both are supplied.

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 action and resource: 'Select an <option> by value or label.' This distinguishes it from sibling interaction tools like browser_click or browser_fill, since selecting a dropdown option is a distinct operation.

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 mentioning targeting via 'a snapshot ref or a selector,' but it does not explicitly say when to prefer this tool over browser_click or other siblings, nor does it mention exclusions or prerequisites such as needing a navigated page or a rendered select element.

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 no annotations, the description carries the burden of behavioral disclosure. It adds key life-cycle information: each node carries a ref token, and refs are invalidated on navigation. This is important, non-obvious behavior beyond the bare 'return snapshot' statement. It does not mention output size or format, but the essentials for safe usage are covered.

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, both information-dense and front-loaded: the first states the core action, the second adds the ref workflow and invalidation caveat. No filler or redundancy exists.

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

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

For a zero-parameter, no-output-schema tool, this description is nearly complete: it names the resource, explains ref tokens, and warns about invalidation across navigation. A minor gap is that it doesn't describe the snapshot's internal structure (e.g. tree with roles/text), which would help an agent parse the result, but the core calling convention is fully specified.

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 schema coverage is trivially 100%, so the baseline of 4 applies. The description adds value by explaining the ref token format, which is the output-side analog to parameters, but this is not required for parameter clarity.

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

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

States a specific verb ('Return') and resource ('AI-oriented accessibility snapshot for the current page'), which clearly separates it from sibling tools like browser_click or browser_navigate. The distinction from the visual snapshot presumably offered by browser_screenshot is implicit but the resource is precisely named.

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?

Explains that refs are passed into browser_click/browser_type/etc., which tells an agent when to use this tool: to obtain element references for subsequent actions. It does not explicitly exclude alternatives like browser_evaluate or browser_screenshot for inspecting the page, but the primary workflow 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?

With no annotations, the description carries the full burden of disclosure. It does reveal key behavior: text is entered and the target is resolved via focus, a matched selector, or a ref. However, it omits details like whether typing is simulated keystrokes, whether the element is auto-waited or focused first, and what the submit and slowly flags change.

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 or repetition. Every word adds meaning, and the core behavior appears first.

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 five parameters, zero schema coverage, no annotations, and no output schema, this description is too sparse for an agent to call the tool reliably. It needs usage guidance, clearer parameter semantics, and some behavioral notes to be 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 description coverage is 0%, so the description is the only documentation for all five parameters. It loosely explains ref ('ref-targeted') and selector ('matched') but is silent on slowly and submit, and it does not clarify how the targeting modes interact with one another or with the required text 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 states a concrete action (type text) and a resource (the focused, matched, or ref-targeted element), so the basic purpose is clear. It does not explicitly contrast browser_type with the similarly text-oriented sibling browser_fill, so it stops short of differentiating the tools.

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

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

There is no guidance about when to choose browser_type over browser_fill, browser_press, or browser_click. The only hint is the word 'type' already present in the tool name, which provides no 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?

There are no annotations, so the description must carry the full behavioral burden. It states the core waiting behavior but omits critical traits: what happens if the selector/text never appears, whether a timeout exists, whether the wait is a single check or polling, and the effect of combining parameters. It also fails to mention the textGone mode entirely.

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 concise sentence with no filler. It front-loads the core behavior and earns its place, though additional behavioral details would be needed elsewhere.

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 4 undocumented parameters, no annotations, and no output schema, the description is too thin for fully reliable invocation. An agent cannot confidently know duration units, error/timeout behavior, or how textGone works, making the tool under-specified for its actual 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 0%, so the description must compensate. It adds some meaning by mapping selector, text, and time to waiting modes, but it does not define parameter semantics precisely: no units for time, no selector syntax, no behavior for textGone, and no guidance on which parameters are exclusive or combinable.

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 ('Wait') with clear resources ('selector/text' or 'fixed duration'), making the tool's role understandable. It does not explicitly contrast with siblings, but none of the sibling tools overlap with waiting, so the purpose 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 usage context is implied: use this tool when you need to wait for a selector, for text, or for a fixed amount of time. However, there is no explicit guidance about when not to use it, no prerequisites, and no mention of how to choose among the wait modes.

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