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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool scrolls the element into view and waits for it to be clickable, which goes beyond the bare action of clicking. It does not mention failure behavior on timeout or missing elements, but the key behavioral traits 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 concise sentences with no filler. The primary action and key behavioral details are front-loaded, and the fallback guidance is placed second without undermining the main purpose.

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 one-parameter tool, the description is complete: it explains what happens (scroll, wait, click), how the target is identified, and what to do when this tool is not appropriate. The presence of an output schema covers return-value details, so no further explanation is needed.

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 does by clarifying that the selector is a CSS selector and that the click targets the first matching element. This adds meaningful context to the otherwise bare 'selector' property, though an example or further selector syntax detail would be even more helpful.

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 (Click) and resource (first element matching a CSS selector). It also distinguishes itself from the sibling tool browser_click_at by contrasting selector-based clicking with coordinate-based clicking, making the tool's purpose immediately clear.

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

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

The description explicitly says when to use this tool versus browser_click_at: use browser_click_at when no selector can describe the target, using coordinates from browser_snapshot. This provides clear decision guidance and a named alternative.

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 behavioral burden and over-delivers: pointer event ordering ('Moves the pointer there first (no teleport), then down, then up'), the return value (screenshot after release), a documented silent-failure version caveat for hold_seconds, viewport-relative coordinate semantics, the no-raise stale-coordinate behavior, and a concrete mitigation (take a fresh snapshot).

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

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

Three paragraphs, but high information density: the first front-loads purpose, use cases, mechanics, and return value; the third covers the staleness trap and routing. The only somewhat expendable line is the 'floor in pyproject.toml is set accordingly' remark in the version caveat, which reassures rather than instructs; otherwise every sentence 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?

Complete for a 3-parameter click tool with several genuine traps. It covers the event sequence, the return value (stated, so no output schema is needed), the version trap, the coordinate-system trap, the silent failure mode, and the mitigation. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 0% — the schema offers only bare titles ('X', 'Y', 'Hold Seconds') — so the description must compensate, and it does fully. It defines the coordinate reference frame (viewport, not page), what staleness does to a coordinate, and hold_seconds' real semantics plus its version dependency. Both parameters are materially clarified beyond the schema.

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

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

States a specific verb and resource — 'Click (or press-and-hold) a raw viewport coordinate instead of a selector' — and gives concrete target examples (slider track, canvas-drawn captcha, precise point inside a wider element). It is explicitly framed against the sibling browser_click ('instead of a selector'), so there is no ambiguity about what it does or when it applies.

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

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

Explicitly sets the selection condition — 'for targets a selector cannot reliably reach' — and closes with a direct routing instruction: 'prefer browser_click with the element's `selector` whenever it has one.' This is exactly the when-to-use vs alternative guidance the rubric asks for.

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 behavioral burden and does so well. It states that acting on the page is refused, that the refusal names the correct tool, and that attempts to bypass the guard are the wrong approach and should be reported rather than used. This gives the agent an accurate model of the tool's safety boundary.

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 capability, then gives concrete examples, then explains the read-only boundary and alternatives. Each paragraph earns its place, and the structure moves from what the tool does to when not to use it to the correct fallback 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?

For a one-parameter read-only evaluate tool, the description covers purpose, use cases, restrictions, alternatives, and expected output format. The presence of an output schema covers the return value details, so nothing essential is missing for an agent to select and invoke 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 input schema only says 'Expression' with no description, so the description must compensate. It explains that the expression is JavaScript and that its result is returned as JSON, and gives example targets. It does not spell out the exact expected syntax or return serialization rules, but for a single self-named parameter the provided context is sufficient.

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

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

The description opens with a specific action and resource: 'READ from the page with JavaScript and get the result as JSON.' It also gives concrete use cases (computed style, framework state, list length) that are not covered by sibling tools, clearly distinguishing browser_evaluate from browser_read_text 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 explicitly says when browser_evaluate is the right tool ('For what the other tools cannot see') and when it is not: mutations, clicks, typing, and selection changes. It names browser_click, browser_type, and browser_select_option as the alternatives, giving the agent direct routing guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the default behavior of wait_until, the trade-offs among 'domcontentloaded', 'load', and 'networkidle', and the fact that a tab may be created if none exists. It does not mention timeouts or failure behavior, but the core side effects are disclosed.

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

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

The description is compact and front-loaded. The first sentence states the action, and the second paragraph adds necessary parameter guidance without repetition or filler. Every sentence 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 provides sufficient context for an agent to invoke the tool correctly: the target resource, tab behavior, and wait_until semantics are covered. An output schema is present, so the lack of return-value detail is not a gap. Minor omissions like timeout handling prevent a perfect score.

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 provides 0% description coverage, so the description must compensate. It meaningfully explains the wait_until parameter and its options beyond the schema's bare default value. The url parameter is not elaborated, but its meaning is self-evident and the required format is implied by 'go to a url'.

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 and resource: 'Go to a url in the active tab', which clearly states the tool's core function. It also distinguishes itself from sibling tools like session_new_page by noting it operates in the active tab and opens one only if none exists.

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 useful context about when to use different wait_until values, but it does not explicitly compare this tool to alternatives like session_new_page or browser_snapshot. The usage context is implied rather than stated as a decision rule between tools.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the key press targets the focused element, which is important context. However, it does not mention potential side effects like form submission, navigation, or focus changes caused by keys such as Enter or Tab, nor what happens if nothing is focused.

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 an inline list of key examples. Every part is useful, and the structure makes the accepted values immediately visible without unnecessary prose.

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 input tool, the description is largely complete: it conveys the target, the key format, and common examples. An output schema is indicated, so return-value details are not required here. A little more detail about modifier formatting or unfocused-element behavior would make it fully comprehensive, but it is adequate for effective use.

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 a bare 'key' string with zero description coverage. The description adds essential meaning by listing accepted key forms, including named keys, navigation keys, modifier chords, and single characters, which gives the agent a concrete understanding of what to pass.

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 ('Press') with a clear resource ('a key on whatever has focus') and gives concrete examples such as 'Enter', 'Tab', 'Escape', and 'Control+a'. This clearly differentiates it from sibling tools like browser_type, browser_click, and browser_navigate.

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

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

The description implies when the tool should be used: when a keyboard key or shortcut needs to be sent to the currently focused element. However, it does not explicitly contrast it with browser_type for text input, nor does it state when not to use it, leaving the decision partly 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, the description fully discloses behavioral traits: it is uncapped and can return tens of thousands of characters, it returns the whole reduced page, and it explains why (cutting markup would break tags). It also details how each mode alters the output. This goes beyond what annotations would typically cover and fully informs the agent of the tool's 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?

The description is well-structured and front-loaded: it starts with the core purpose, then usage context, then mode details, then size caveat, and ends with alternatives. Every sentence serves a distinct informative purpose, and there is no redundancy. It is appropriately sized given the complexity of the tool.

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

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

The description covers all essential aspects for correct usage: purpose, when to use, mode semantics, output size expectations, and explicit routing to alternatives. Given that an output schema exists, the description does not need to explain return values, so it is complete for an agent to invoke 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 schema provides no description for the 'mode' parameter (0% coverage), so the description must compensate. It does so thoroughly by explaining each mode: 'form' keeps interactive surface, 'text' returns prose alone, 'full' keeps structure with noise removed. This adds rich semantic meaning beyond the bare schema, making the parameter fully understandable.

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 what the tool does: returns the page's HTML cleaned down to readable content, and explicitly differentiates it from siblings by contrasting with browser_snapshot (flat inventory) and browser_read_text (capped text). The verb 'read' and resource 'HTML' are specific, and 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?

It explicitly instructs when to use this tool: 'Use this when the STRUCTURE matters' and gives concrete examples. It also provides exclusion guidance by naming alternatives and the conditions for choosing them: 'Reach for browser_snapshot when you only need something to click, or browser_read_text when you only need the words.' This is exemplary usage guidance.

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

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

With no annotations, the description carries the behavioral burden, and it delivers: it discloses that only visible text is returned, that long text is truncated at max_chars (6000 default), and that the return value marks the cut so the agent can detect truncation by the marker's absence. It doesn't cover edge cases like missing selectors, but the core read behavior is transparent.

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

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

Four compact sentences with no filler. The most important outcome is first, followed by usage guidance, then a precise truncation caveat. Every sentence earns its place and the whole is scannable.

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 an output schema exists (so return formatting is covered elsewhere) and only two optional parameters, the description supplies enough to invoke correctly: what it returns, how to narrow it, and how to detect truncation. A minor gap is not stating behavior for multiple matching elements or a missing selector, but the core workflow is 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 must compensate. It explains selector as the element to narrow and max_chars as the truncation limit with a default of 6000 and a marker behavior. This adds real semantic meaning beyond the raw schema, though it doesn't explicitly state that selector uses CSS syntax.

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 starts with a crisp definition—'The visible text of an element, with the markup gone'—which names the resource (element text) and operation (read). It also distinguishes from siblings: browser_read_html for structure and browser_snapshot for clicking, so an agent can tell them apart immediately.

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

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

Explicitly instructs when to use this tool: 'Narrow the selector when you know where the answer is' and when to prefer alternatives: 'use browser_read_html instead when the structure matters, or browser_snapshot when you need something to click.' It also frames it as 'the cheapest way to read a page,' giving a cost-based decision signal.

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. It discloses that the tool performs a real interaction (as opposed to synthetic DOM changes) and explains why that matters. It does not detail error conditions or return values, but the output schema covers returns, and the behavioral distinction is clearly stated.

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: the first states the action and parameters, the second justifies the preferred approach. Every sentence earns its place, with no redundant wording.

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 two-parameter tool with an output schema, the description covers the essential purpose, the value parameter semantics, and the behavioral rationale. It does not mention edge cases like missing options or non-visible selects, but these are unlikely to block correct invocation given the clear guidance.

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 0%, so the description must compensate. It explicitly explains that 'value' can be either the visible label or the underlying value, which is critical for correct usage. The 'selector' parameter is left implicit, but standard CSS selector semantics are widely understood and not a significant gap.

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 (choose an option in a dropdown), identifies the target element type (`<select>`), and clarifies the two selection modes (visible label or value). It also distinguishes itself from sibling tools like browser_click and 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?

Explicitly contrasts this tool with two alternatives: clicking + arrow keys (which cannot confirm the selected row) and browser_evaluate (which bypasses real interaction). This provides clear when-to-use and when-not-to-use guidance, leaving no ambiguity for an agent deciding among sibling tools.

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

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

With no annotations, the description carries the full burden, and it is unusually rich: it discloses the unique-selector guarantee, the 88%/48% real-world measurement, Playwright's first-match behavior, coordinate fallback for elements without selectors, and the character-cap rationale for excluding options. This lets an agent anticipate silent wrong-click failures.

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

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

The description is dense but every sentence earns its place: the first line front-loads the output, the second paragraph gives selector safety guidance, and the third justifies the filtering behavior. No filler or restatement of the tool name.

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

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

Given complexity and no annotations, the description covers output structure, selector semantics, coordinate fallback, and interaction routing impressively well. It falls just short of completeness by leaving the max_chars parameter unexplained and not explicitly distinguishing this tool from sibling read tools.

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 provides only max_chars with a default and no description, so schema coverage is 0%. The description mentions a 'character cap' but never says that max_chars controls it, how values behave, or what the default means; an agent cannot determine how to set this parameter from the description.

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

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

The first sentence names exactly what is returned — title, url, and actually visible interactive elements — so an agent knows the resource and output. It also distinguishes itself from 'the accessibility tree' and explains why, which prevents confusing it with a DOM dump.

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

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

The description explains how to consume its output: pass selector VERBATIM to browser_click/browser_type, or use at coordinates with browser_click_at. It gives clear context for choosing the tool (visible interactive elements for interaction) but does not explicitly say when to prefer it over sibling read tools like browser_read_text or browser_read_html.

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 burden of explaining behavior. It does disclose that exactly one screenshot is taken, from the active tab, and only on demand. However, it does not mention what happens after capture, such as return format or whether the screenshot is saved, which keeps it 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 a single, front-loaded sentence with no wasted words. Every component adds meaning: 'one', 'screenshot', 'active tab', and 'on demand' all clarify scope and 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?

The tool is simple and has no parameters, but there is also no output schema or annotations. The description explains what is captured but not what the agent receives in return, such as an image path, base64 data, or dimensions. This missing return-value guidance leaves a gap for an agent trying to use the result.

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

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

The tool has zero parameters and an empty schema with 100% coverage, so there is no parameter meaning for the description to add. The baseline of 4 applies because no parameter documentation is needed.

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 and resource: 'One screenshot of the active tab, on demand.' It clearly identifies what is captured, the active tab, and the trigger condition. This is distinct from sibling tools like browser_navigate or browser_read_text.

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

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

The description gives no guidance about when to use this tool versus alternatives such as browser_snapshot, browser_read_text, or browser_read_html. There are no explicit exclusions or conditions, so the agent must infer appropriate usage from the tool name alone.

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 reveals that the tool replaces the field's current value and does not fire per-keystroke handlers, which is a critical trait. It could also mention broader side effects like input/change events, but it covers the key differentiator well.

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 the primary action front-loaded. Every sentence adds value: the first states the purpose, the second provides a key caveat and an alternative. 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 that has an output schema, the description covers the essential behavior and the most important exception (autocomplete). It does not address error conditions or focus requirements, but those are not critical given the tool's simplicity and sibling context.

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 indirectly clarifies that 'text' is the value to fill and 'selector' is the target field, but it does not define acceptable selector syntax or text encoding, leaving room for ambiguity.

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 and outcome: filling a field and replacing its current content. It clearly differentiates the tool from typing-based tools like browser_press_key by emphasizing that it sets the value rather than typing key by key.

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 tells when not to use this tool (when the field needs autocomplete per-keystroke handlers) and names the alternative (click the field and use browser_press_key). This gives agents unambiguous 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that this is a live capture, that coordinates are window pixels rather than page coordinates, and that it is unsuitable for action. However, it doesn't explicitly state the return format (e.g., single frame vs. continuous stream) or how/when the capture stops, which is a modest gap.

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

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

The description is appropriately short and front-loaded: the first sentence defines the tool's core behavior, the second provides usage constraints and an alternative. Every sentence serves a purpose with no redundant 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 zero-parameter watch tool, the description is largely complete, covering purpose, limitations, and a recommended sibling alternative. The main omission is the exact delivery/return mechanics of the 'live capture' and whether any session or lifecycle management is required, especially since no output schema exists to fill that gap.

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

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

The tool has zero parameters and the schema is empty, so no parameter description is needed. The description still enriches the tool's semantics by describing what is captured (tab strip, address bar, page, pointer), matching the baseline expectation for a parameterless tool.

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 what the tool does: it shows the whole browser window (tab strip, address bar, page, pointer) via a live capture on the active tab. It also explicitly frames the tool as 'watching the work, not for acting on it,' which differentiates it from siblings like browser_click_at and browser_take_screenshot.

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 direct usage guidance: use it for watching, not for acting, and explicitly warns against feeding its coordinates to browser_click_at, directing the agent to browser_take_screenshot instead. This makes the choice between sibling tools 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?

No annotations are provided, so the description carries the burden of disclosing behavior. It clearly states the destructive action (closing a tab) and the default behavior when page_id is omitted. However, it does not mention side effects such as whether the closing is permanent, what happens if the last tab is closed, or whether any confirmation is needed. The word 'Close' implies destruction, but more transparency would improve the score.

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. The primary action is front-loaded and the optional behavior is appended naturally. 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 one optional parameter and an output schema, the description is nearly complete. It covers the core action and the parameter default. Minor missing context includes how to identify page_id and any irreversible side effects, but these are partially inferable from sibling tools and the word 'Close.'

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 does add meaning: page_id identifies the tab to close, and leaving it out closes the active tab. This explains the optionality and default behavior beyond the bare schema. It does not specify how to obtain a valid page_id, but the sibling session_list_pages provides that context.

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 and resource: 'Close a tab.' It clearly distinguishes this from sibling tools like session_new_page, session_select_page, and browser_navigate by indicating the action of closing. The optional active-tab behavior is also stated explicitly.

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

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

The description provides clear context: use this tool when you want to close a tab, optionally specifying which one via page_id. It does not explicitly mention when not to use alternatives or list exclusions, but the scope is straightforward and unlikely to be confused with sibling actions like navigating or selecting pages.

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 the burden of behavioral disclosure. It clearly states what the tool returns and notes a meaningful limitation about the id alone. A small gap is that it doesn't explicitly state read-only behavior, but the verb 'list' reasonably implies a non-mutating operation.

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 compact sentences, with the essential output contract front-loaded and the usage guidance in the second sentence. Every sentence earns its place with 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 zero-parameter list operation with an output schema available, the description covers everything an agent needs: the scope of results, the fields returned, and the recommended usage ordering relative to session_select_page. Nothing important is missing.

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

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

The tool has zero parameters and the schema is already fully descriptive, so the description couldn't add much parameter-level detail. It instead adds value by explaining the output fields and how they relate to subsequent tool usage, which is appropriate for a parameterless tool.

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 a list operation over open tabs with specific output fields (id, title, url, active state). It also distinguishes itself from session_select_page by explicitly naming it, so an agent can tell them apart without inspecting schemas.

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

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

The description gives explicit contextual guidance: use this tool before session_select_page because the tab id alone doesn't indicate which tab you're switching to. This tells the agent not just what the tool does, but when to call it relative to a sibling.

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 discloses key behaviors: opens a new tab, makes it active, returns a page id, and persists tabs across calls and clients. This goes beyond the schema and gives the agent a clear model of the tool's effect. It could mention more about cleanup or session boundaries, but it is transparent for the operation it describes.

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 sentences with no filler. The action is front-loaded, the return value is stated, and the persistence behavior is explained in the second sentence to justify when to use it. Every sentence 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 zero-parameter tool with an output schema, the description is complete: it explains the action, the side effect, the return type, and the recommended usage pattern. The sibling context and persistence rationale give the agent enough to call it appropriately without further investigation.

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 baseline is 4. The description appropriately does not invent parameter details, and there is nothing additional to explain about inputs. The return value is mentioned, which is useful context.

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

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

States a specific verb and resource: 'Open a new tab and make it the active one.' It clearly distinguishes itself from sibling tools like session_list_pages, session_select_page, and session_close_page by describing creation of a new page rather than listing, selecting, or closing one.

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 clear context for when to use the tool: when you want to keep one page while working on another, since tabs persist across calls and clients. It does not explicitly name alternative tools or state when not to use it, but the guidance is sufficient for most agents.

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

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

With no annotations, the description carries the full burden and does add useful behavioral context: the tool changes session state (active tab) and has a broad effect on all subsequent browser_* calls. This is the key behavioral trait beyond a simple read/write hint, and it is disclosed.

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

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

Two sentences, front-loaded with the core action, then a concise dependency/scope note. No filler or repeated schema information.

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

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

For a one-parameter state-selection tool, the description covers what it does, how it affects browser tools, and where the parameter value comes from. The presence of an output schema covers return-value expectations, so 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?

Schema coverage is 0%, but the description compensates by telling the agent exactly where to obtain page_id (session_list_pages or session_new_page). This adds actionable meaning beyond the bare 'page_id' string 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 opens with a specific verb and resource ('Switch the active tab') and immediately explains the tool's role in the session: every browser_* tool acts on this tab. This clearly distinguishes it from session_new_page/list_pages/close_page and from the browser_* 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?

It states the prerequisite source for page_id ('Take the id from session_list_pages or from session_new_page') and implies that selection should precede browser_* calls by saying those tools act on the active tab. It lacks explicit when-not/alternatives, but the contextual guidance 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 and does so thoroughly. It discloses that calling it closes the current browser, that unsaved profile data is lost, that there is only one browser, that profiles persist their seed, and that proxy changes are only warned about when the user changes them—not when a provider rotates addresses.

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 long but densely informative, with every sentence earning its place. It is front-loaded with purpose and usage, then limitations, then parameter semantics, and it avoids repeating schema details since the schema has no descriptions.

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 three optional but semantically complex parameters and an output schema, the description is complete. It covers when to call, what happens on call, persistence behavior, identity semantics, and the single-browser limitation, leaving nothing an agent needs in order to decide and 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?

Schema coverage is 0%, so the description must fully compensate, and it does. It explains seed determinism, profile persistence and seed-carrying behavior, the empty-string convention for no profile, relative path resolution, and proxy format and its identity implications.

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

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

The description opens with a specific verb and resource: 'Start a browsing session as a particular person, and say who that is.' It clearly differentiates this tool from siblings by focusing on controlling the browser identity, while other session_* tools handle status, pages, and navigation.

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 call it ('Call this when you want to control WHO is browsing'), when not to call it ('You do not have to call it at all'), and what to use instead (session_status). It also gives a concrete exclusion: tasks needing two identities live simultaneously cannot be done here.

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 behavioral burden. It discloses that the tool starts nothing, that it reports when no browser is running, and why that state matters: 'If no browser is running yet it says so, because until one is running there is no identity to report.' This is strong side-effect and empty-state 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 front-loaded with the core purpose and stays reasonably concise. Each paragraph earns its place, though the opening is a sentence fragment and terms like 'exit' are used without immediate 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?

For a parameterless status tool with an output schema, the description covers the essential points: what is reported, when to ask, how the seed relates to session_start, and what happens when no browser is running. Nothing critical is missing for an agent 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?

There are zero parameters and the schema is complete, so the baseline is 4. The description adds useful context about the session seed concept even though no parameters exist, which is appropriate for a parameterless status tool.

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 the tool as a status reporter: 'Who is browsing right now: the identity, the exit, the profile and the tabs.' It also distinguishes itself by stating 'It starts nothing,' which separates it from session_start and other mutating session 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?

It explicitly says when to use it: 'Ask whenever you need to know which person the browser currently is, or from where its traffic leaves.' It also explains the seed's role for replaying a session, but it does not explicitly contrast itself with sibling tools like session_list_pages, so the alternative routing is slightly implicit.

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