agent-browser

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

With no annotations provided, the description carries the full behavioral burden and largely fails: it says nothing about whether the click waits for the element to exist, scrolls it into view, what happens if the selector matches nothing or the page is not loaded, or whether a browser session must already be open. It only restates the mutation action implied by the name.

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, the primary mode listed first, and the argument constraint stated immediately after with no filler. 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 no annotations and no output schema, the description leaves the agent without error/failure semantics, session prerequisites, or any indication of what a successful click returns. A simple tool, but the missing behavioral context is exactly the gap the description should have filled.

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

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

Schema description coverage is 100%, so the schema already explains x, y, and selector, setting the baseline at 3. The description adds genuine meaning beyond the schema by declaring mutual exclusivity between the selector mode and the coordinate mode, a constraint the schema itself does not encode (zero required parameters).

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

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

States a specific verb (click) and the exact resource it acts on (CSS selector or viewport x/y point), so an agent can tell it apart from browser_type, browser_press, and browser_scroll. It does not explicitly name sibling tools or say how it differs from e.g. browser_press, but the action itself 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?

"Provide one, not both" gives a real constraint on argument selection, which is useful since no parameter is marked required. However, it gives no guidance on when to prefer a selector versus coordinates (selector is normally the reliable path, coordinates the fallback for non-CSS targets), nor any precondition such as the page already being open.

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 does disclose two non-obvious traits: idempotency and the existence of a single session slot that must be freed. It does not say whether an unclosed session blocks future browser_open calls or what an error looks like if no session exists, but the key behavioral context is present.

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

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

Three short sentences, front-loaded with what the tool does, then the idempotency guarantee, then the calling condition. No filler or redundancy.

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

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

For a zero-parameter teardown tool with no output schema and no annotations, the description covers what it does, when to call it, the idempotency edge case, and the resource constraint. Nothing an agent needs in order to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing to document and the description does not pretend otherwise.

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 ('End the session and release the browser'), which is unambiguous against siblings like browser_open or browser_read. It also names the shared resource being affected (the browser session), so an agent can tell it apart from navigational tools without opening any schema.

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

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

Explicitly gives the trigger condition: 'Call this when the task is finished so the single session slot is free.' That is clear when-to-use guidance. It stops short of naming browser_open as the counterpart that must precede it, or warning what happens if the session is still mid-task, so it is not a full 5.

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

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

No annotations are provided, so the description carries the full burden. It does add real behavioral value by disclosing that the server validates the destination and refuses blocked address classes, plus what it returns. It says nothing about waiting for load, timeouts, redirect handling, or whether a session must already exist.

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

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

Two sentences, the action and its outputs front-loaded, with the validation caveat appended. Nothing is padded and nothing needs reordering.

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 with no output schema, the description covers both the action and the returned fields (title, final URL, readable text), which is the key missing piece elsewhere. It falls short only on session prerequisite and post-navigation timing, which matter given the browser_* sibling set.

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

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

Schema coverage is 100%, so the single url parameter is fully documented by the schema itself. The description's "http(s) URL" phrasing matches the schema's "Absolute http(s) URL" without adding syntax or constraint detail, so the baseline 3 applies.

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

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

The description uses a specific verb+resource ("Navigate the session to an http(s) URL") and even enumerates outputs, which is well beyond tautology. It does not, however, distinguish this tool from the very similar sibling browser_open, leaving the agent to guess which entry point opens versus navigates.

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 when-to-use or when-not-to-use guidance, and no alternative is named. With a sibling named browser_open that plausibly competes for the same job, this omission is costly rather than trivial.

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 well: it discloses idempotency ('Safe to call twice — it reuses the session that is already open'), the headed/single-session nature, and human takeover semantics. It omits failure modes (e.g., what happens if Chrome cannot launch) and any auth or timing 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?

Three tight sentences: action and return value first, then human-facing usage, then idempotency. Every sentence carries distinct information with no filler.

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

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

For a zero-parameter tool with no output schema, the description adequately covers the return value (live view URL), idempotency, and human cooperation model. It could be slightly more complete by stating that this must be opened before the other browser_* tools can drive the session.

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 with 100% schema coverage, so the baseline is 4. The description correctly adds no parameter detail because none is needed, though it does not mention a configurable session name or similar implied knobs.

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 — starting the single headed Chrome session and returning the live view URL — and the phrase 'the one headed Chrome session' plus 'reuses the session that is already open' carves out its singleton role versus siblings like browser_close and browser_status. An agent immediately knows this is the session entry point.

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

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

It gives clear operational context: the returned URL goes to the human, who can watch or take over while the agent drives, and it is safe to call twice. It never explicitly says when not to call it or names a sibling alternative, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the allowlist restriction, which is genuine behavioral context, but says nothing about what pressing does (e.g., acting on the focused element), whether an error is returned for unlisted keys, or the post-press effect.

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 bulk of the text is a 20-item enumeration that redundantly duplicates the input schema's enum, which does not earn its place. The useful content ('press one allowlisted key or combination') is a single short clause buried ahead of the redundant list.

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 with no output schema, the description covers the what and the allowed values. It is nonetheless missing focus/prerequisite context and error behavior that an agent would need to invoke it reliably.

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

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

Schema description coverage is 100% and the single parameter is a fully enumerated enum, so the schema already documents every valid value. The description's list adds no format or syntax meaning beyond what the enum provides, giving the baseline 3.

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

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

States a specific verb ('press') and resource ('one allowlisted key or combination'), which clearly separates it from siblings like browser_type and browser_click. It is clear, though it never explicitly names an alternative sibling to differentiate against.

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 reach for this tool versus browser_type (text entry) or browser_click, and no prerequisites such as an element needing focus. Usage is only weakly implied by the word 'press'.

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 and does disclose a real behavioral trait: the accessibility tree is bounded, and the vision-step cost only applies when the image is requested. It doesn't cover permissions, pagination, or truncation limits of the bounded tree, which is why it isn't a 5.

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

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

Two tight sentences, front-loaded with what is returned and immediately followed by the routing rationale. Every clause earns its place.

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

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

No output schema exists, so the description must describe return values and it does, listing title, URL, text, and the accessibility tree. 'Bounded' is left undefined, so an agent doesn't know the truncation limits, but the description is otherwise sufficient for a zero-required-param read tool.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, so the schema does the heavy lifting. The description's 'unless you ask for the image' only loosely echoes include_screenshot without adding format or default detail 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 (read) and resource (current page) and enumerates exactly what comes back: title, URL, readable text, and a bounded accessibility tree. It also distinguishes itself from the screenshot path, so an agent can tell it apart from sibling browser_* 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?

Explicitly says to prefer this over a screenshot and explains why (structure not pixels, no vision cost unless requested), which routes the agent correctly. It gives no guidance on when NOT to use it or how it relates to siblings like browser_status, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and delivers little: it discloses only that a zero delta is invalid, but says nothing about whether the scroll is instant or animated, whether it waits for load, what state it mutates, or what it returns.

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 zero-waste sentence with the key constraint front-loaded. Brevity is appropriate for a trivial operation, though the terseness leaves gaps that are penalized 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?

For a two-optional-parameter utility with no output schema, the description is minimally adequate, but an agent still lacks any statement of preconditions or post-scroll state, which matters when orchestrating a browser session.

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

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

Schema coverage is 100% and both deltas are documented with direction and sign conventions, so the schema does the heavy lifting. The description adds only the 'nonzero' constraint, which is a marginal but real addition.

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 (scroll) and resource (the page) with the delta semantics of the operation. It is clearly distinguishable from siblings like browser_navigate or browser_click, though it never explicitly contrasts itself with 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?

No when-to-use guidance, no prerequisites (e.g., must a page be open first?), and no mention of how scroll interacts with browser_navigate or browser_read. The only inferred guidance is the 'nonzero' wording.

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 disclosure burden. It usefully enumerates the four pieces of state returned (runtime, session, vision steps, view URL), but omits any hint about permissions, side effects, or when a session must exist before calling.

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 well-formed sentence that front-loads the most important outputs (runtime and session state) before the ancillary URL detail. No wasted words.

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

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

No output schema exists, so the description properly enumerates the return contents, which is what an agent most needs here. For a zero-parameter, side-effect-free status probe it is essentially complete.

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

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

The tool takes zero parameters, so the schema is trivially complete and there is nothing for the description to compensate for. Baseline 4 applies.

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

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

States a specific verb ('Report') and enumerates exactly what is reported: runtime state, session presence, remaining vision steps, and the live view URL. This clearly contrasts with the action-oriented siblings (browser_open, browser_click, etc.), though it does not name a sibling 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?

Usage is implied rather than stated: the mention of the live view URL 'to hand to a human' hints at one use case, but there is no explicit when-to-use/when-not guidance or routing against the other browser_* 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 behavioral burden. It does disclose two useful traits — 'Text is sent byte for byte' (no key interpretation) and the secret-handling safety rule — but says nothing about focus behavior, error/failure results, whether existing field content is cleared, or permission requirements.

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

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

Three short sentences, front-loaded with purpose, then the byte-for-byte behavior, then the safety exclusion. No filler and nothing buried.

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?

Covers purpose, targeting modes, and a safety caveat adequately for a 4-param, no-output-schema tool. With zero annotations, though, the behavioral profile is thin: an agent cannot tell what happens on a bad selector, whether the element is focused first, or whether text is appended or replaced.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: selector and x/y are presented as alternative targeting modes, implying a mutual-exclusion relationship the flat schema never states. It stops short of explaining precedence if 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?

Names a specific verb (Type) and target ('CSS selector, or at an x/y point'), which is enough to distinguish it from browser_click and browser_press. It does not explicitly name the sibling it differs from (browser_press for keys), so it falls just short of a 5.

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?

Gives an explicit negative case and a concrete alternative: 'Do not use this for a secret a human should enter — ask them to take over in the live view instead.' That is real when-not-to-use guidance with a fallback, though the positive when-to-use case versus browser_press is left implicit.

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