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 well: it discloses that op=call sends API requests without exposing the agent to tokens, that op=sign_in types saved credentials into a login form, and that unlinked accounts yield policy.denied with a mandated recovery path. It lacks details on side effects, rate limits, and whether sign_in changes session state, keeping it from 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?

The description is tightly structured: it opens with the scope (linked accounts), then enumerates each op in a single dense sentence, and closes with the failure behavior. Every clause carries information and nothing is 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 7-parameter multi-operation tool with no annotations and no output schema, the description covers the operations well and includes important error guidance. It remains incomplete because it does not explain the account or tabId parameters, and it does not describe what each op returns, leaving gaps that the schema does not fill.

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 the op enum and maps connector, method, path, and body to op=call, but it does not explain the account or tabId parameters at all, leaving key semantics undocumented.

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 resource (accounts linked in the Account Center) and enumerates four distinct operations, making the tool's purpose clear. It does not explicitly distinguish this tool from the sibling browser_call, so it falls short of a perfect score.

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 explains what each op does and provides a clear condition for failure: if an account is not linked, expect policy.denied and ask the person to link it. However, it does not compare this tool against sibling alternatives such as browser_call or browser_open, leaving the agent to infer when to choose one over the other.

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 disclose meaningful traits: it performs 'real input' (real side effects), waits for the page to settle before returning, returns a diff of what changed rather than full state, and can surface approval.required/handoff.required outcomes. It does not mention reversibility, permissions, or that actions like upload/click are irreversible, which keeps it short of 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?

The description is dense and front-loaded: the core behavior (act, wait, return diff) comes first, followed by the action list and then the special submit/handoff rules. The action enumeration is long but each entry earns its place by disambiguating parameter usage. Slightly telegraphic phrasing costs it the top score.

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 complex 10-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what it does, which params pair with which actions, and how to handle approval/handoff replies. Gaps remain around approvalId, the provenance of ref values, and the shape of the diff returned, but nothing critical to invoking it correctly is missing.

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

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

Schema description coverage is only 20% and there are 10 parameters, so the description must compensate — and it largely does. It maps parameters to actions: text for fill/type, key for press, value/values for select (values for multiple lists), to for scroll (top|bottom or a ref location), paths for upload, and submit:true to make fill press Enter. It omits approvalId's purpose and doesn't explain where valid refs come from.

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

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

The description states a specific verb+resource: acting on an element identified by ref using real input, then waiting for the page to settle and returning only what changed. It enumerates every supported action (click, fill, press, check, uncheck, select, hover, scroll, type, upload), which immediately separates it from read-only siblings like browser_read and browser_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?

Usage is implied rather than stated: the agent must infer that this is the write/interaction tool used after browser_open/browser_read, and no comparison to browser_batch or browser_call is given. It does provide one concrete routing rule — if the reply is approval.required or handoff.required, call browser_wait_human — which is genuinely useful but narrow. There are no explicit when-not-to-use conditions.

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

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

With no annotations, the description carries the behavioral burden and does well by disclosing ordered execution, stopping at the first failure, and returning the final change set. It still leaves open whether partial changes persist on failure and does not mention permissions or other side-effect constraints.

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

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

Three tight sentences, front-loaded with the core behavior and an example, with no filler. Every sentence adds useful information about sequence, failure handling, or return value.

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 single-parameter tool with no output schema or annotations, it covers the key operational behavior: batching, ordering, abort-on-failure, and return value. It could be more complete by clarifying partial-change persistence after failure, but it is sufficient for correct invocation.

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

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

Schema coverage is 100%, including the note that each step has the same fields as browser_act, so the schema already explains the single parameter. The description reinforces that steps are browser_act-like but adds no additional parameter constraints or formatting details beyond the structured schema.

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

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

The description states a specific action and resource: run several browser_act steps in order in one call. It clearly implies batching versus single-step browser_act, but does not explicitly name the sibling as the alternative for single 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 gives a clear usage context, exemplified by filling a whole form and clicking Save, which signals when a multi-step batch is appropriate. It does not explicitly state when not to use it or name alternatives, 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?

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing about safety profile, side effects, permissions, or failure behavior. Since it can invoke arbitrary methods (including destructive ones like downloads or dialogs), omitting any risk or reversibility context is a real 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?

Two tight sentences, front-loaded with the core capability and immediately followed by a concrete invocation example. No filler and the example earns its place by doubling as a discovery hint.

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, no output schema, and 0% parameter coverage, the description is incomplete for a fully generic dispatch tool, but the browser.capabilities discovery pointer partially compensates by giving the agent a way to enumerate valid methods. Return-value and params structure remain unaddressed.

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% for two parameters, so the description must compensate, and it only offers one concrete example (method:"browser.capabilities"). It gives no explanation of the method naming convention, no detail on the nested params object shape, and no required-vs-optional semantics.

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

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

States a specific verb (call) and resource (AgentGo protocol method) and positions itself as the generic dispatch tool relative to specialized siblings, listing example domains like cookies, downloads, PDF and dialogs. It is clear what it does, though the abstraction of 'protocol method' means an agent still needs the sibling list to know it is the fallback.

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

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

Implies usage (call methods not exposed by other tools) and gives a discovery entry point via browser.capabilities, but never states when to prefer browser_call over the ten specialized browser_* siblings or when not to use it. Guidance is inferable rather than explicit.

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

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

With no annotations, the description carries the full burden, and it delivers real behavioral context: relative size of each topic ('short' for start, 'all = every command, about 25,000 tokens') so the agent can budget context, plus the one-shot call cadence. It stops short of stating the tool is side-effect-free/read-only, which would fully close the 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?

Three dense sentences with the primary instruction front-loaded and each topic clause carrying distinct information. The opening 'written for you' is mild filler, but no clause is truly redundant for a tool whose whole purpose is disambiguation.

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

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

There is no output schema and no annotations, and the description compensates by describing the content and rough size of each topic, which is what the agent needs to choose one. A note on how the guide is returned (single string vs. structured) is the only missing piece.

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 entirely, and it does: it defines all three topic values (start, commands, gomini), enumerates the group sections (open, read, act, batch, accounts, person, browser, all), and explains that query takes words like "selector click" to match commands. This is meaning well beyond the raw enum lists.

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 artifact ('how to use this browser') and its role as a documentation entry point, which cleanly separates it from the ten action siblings (browser_open, browser_read, browser_act, etc.). An agent can tell this is the meta/help tool 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?

It gives an explicit ordering rule ('Call it once before your first browser action') and then routes within itself: topic=start is labeled 'read this first', topic=commands is for finding commands, topic=gomini for the local model. When-to-call and which-topic-to-pick are both spelled out.

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 full burden and does meaningful work: it discloses that the call blocks until the page loads and that the response is a compact outline rather than raw HTML or text. It omits failure/timeout behavior and the fact that navigation mutates browser/tab state, which would matter for sequencing.

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, front-loaded with the action, followed by the return contract and the follow-up instruction. Every clause earns its place 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?

No output schema exists, so the description must describe the return value — and it does, specifying the outline format and ref syntax. Combined with the schema-documented `view` modes, an agent has enough to call it correctly; only error/timeout and state-mutation behavior are unaddressed.

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% — both `url` and the `view` enum (page/text/none) are already documented in the schema. The description corroborates the default outline mode but adds no syntax, format, or constraint details beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb+resource (go to a URL / search Google), the behavior (waits for load), and the exact return shape (compact outline with headings and interactive `[ref] role "name"` elements). It also routes the agent to the sibling that consumes the refs (browser_act), so the tool is distinguishable from the rest of the browser_* family.

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 clear context for both modes ('a URL (or search Google with plain words)') and explicitly says what to do with the output ('Use the refs with browser_act'). It stops short of stating when NOT to use this tool (e.g., browser_read for existing pages, browser_screenshot for visual capture), so no explicit alternative/exclusion 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation and names the default view, but says nothing about side effects, preconditions (a tab/page must already be open), whether reads are cached/live, or pagination semantics beyond the bare word 'offset'.

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 dense sentences, front-loaded with the core action and immediately followed by the view taxonomy and parameter hints. Every clause carries information, though the telegraphic style trades some readability for brevity.

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 tool with no annotations, no output schema, and 0% schema description coverage, the definition is only moderately complete. It fails to describe the return shape of each view, what 'refs' are, the 'max' parameter, or the 'changes' view, which an agent would need in order to invoke it 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 coverage is 0%, so the description must compensate, and it partially does: it explains the view modes, filter, and offset. However it omits 'max' entirely and never mentions the 'changes' enum value present in the schema, leaving one parameter and one enum value undocumented anywhere.

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

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

States a specific verb+resource: 'Read the current page.' That is clear and distinguishable from the act/click siblings. It does not explicitly name any sibling (e.g., browser_act, browser_screenshot), so it stops short of the 5-level sibling differentiation.

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

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

Usage is only implied: the view list communicates 'use this to extract content,' and 'Use filter to narrow, offset to page' hints at bulk-reading. There is no explicit when-to-use or when-not, and no mention of alternatives such as browser_act for interaction or browser_screenshot for visuals.

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 load: it discloses the high token cost, that the return value is an image, and the two scoping modes (whole page vs. single element). It does not mention image format, viewport assumptions, or that the operation is non-mutating, but the token-cost warning is genuine behavioral context most tools omit.

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: the capability first, then the cost/alternative rule. Zero filler and the most decision-relevant information is front-loaded.

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

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

No output schema and no annotations, yet the description tells the agent what comes back (an image) and why that is expensive. Missing only minor details like image format and the semantics of fullPage, which is thin for a 2-param tool but not blocking.

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 both parameters. It clarifies 'ref' as targeting one element, but says nothing about 'fullPage' (capture beyond the viewport?), leaving half the parameters undocumented in both schema and prose.

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 ('Screenshot the page'), plus the element-scoped variant via ref, and names the sibling it is not (browser_read). An agent can distinguish it from browser_read and browser_act 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?

Gives an explicit routing rule: prefer browser_read, and only use this when layout, images or a canvas must be seen. The cost tradeoff that drives the choice is stated, not implied.

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 mostly fails it. It never says whether 'switch' changes focus, what happens when 'close' removes the active or last tab, whether 'back/forward/reload' apply to the active tab, or what any operation 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?

Extremely compact and front-loaded: a one-line purpose followed by an op-to-parameter list with no filler. Every token is load-bearing, though the telegraphic style leaves no room for the behavioral context the tool lacks 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 seven-operation tool with three undocumented parameters, no annotations, and no output schema, the description is too thin. It does not explain return values (e.g., what 'list' yields), which operations require a live page, or error/edge behavior, leaving an agent under-informed for several ops.

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 maps parameters to operations ('new (url)', 'switch (tabId)', 'close (tabId)'), which is real added meaning, but it omits the tabId format, whether url is required for 'new', and what the remaining ops operate on.

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 the resource (tabs) and enumerates seven concrete operations (list, new, switch, close, back, forward, reload), so the tool's scope is legible. The framing verb 'Manage' is generic and the description never distinguishes it from sibling browser_open, which plausibly overlaps with the 'new (url)' op.

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 guidance, no exclusions, and no mention of alternatives among the ten sibling browser tools. The op list is a task-to-parameter mapping, not usage guidance, so an agent must infer when this tool is the right choice.

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 full behavioral burden. It does disclose one meaningful trait: with no condition it waits for load-and-settle. However it omits the timeout default, what happens when the timeout elapses (error vs. silent return), and whether conditions are mutually exclusive or combined.

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

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

Two tight sentences with the supported conditions front-loaded and the default behavior appended. No redundant or wasted phrasing.

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 five-parameter, zero-annotation, no-output-schema tool, the description covers condition semantics but leaves notable gaps: timeout default and unit behavior per condition, failure mode on timeout, and return value after waiting.

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

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

Schema coverage is only 20% (timeout is the sole documented property), yet the description semantically maps four of the five parameters: text, selector, gone, and urlContains. It adds real meaning beyond the bare schema, though it does not state precedence or exclusivity among conditions.

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

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

The description names a specific verb (wait) and enumerates the four condition types it supports (text, selector visible, selector gone, URL contains), plus the no-condition default. It does not explicitly differentiate itself from the sibling browser_wait_human, but the purpose is unmistakable.

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

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

It implies when the tool is useful by listing the conditions and stating the no-condition fallback ('waits for the page to finish loading and settle'), but there is no explicit guidance on when to choose this over browser_wait_human or how it relates to browser_read/browser_act sequencing.

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 must disclose behavior, and it does explain that the tool blocks on a human operator and when to pass approvalId versus nothing. However, it omits important operational behavior such as timeout handling, what is returned after human action, and whether the wait is interruptible.

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 compact sentences and front-loads the core action. Every clause adds relevant usage or safety information without redundancy.

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

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

No annotations and no output schema mean the description should fully cover invocation behavior. It explains the human-wait contexts but leaves timeout semantics and return behavior unaddressed, which are important for an agent deciding how to call and interpret the tool.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains approvalId conditionally after approval.required, but never mentions the timeout parameter, leaving half of the parameters undocumented.

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 target: waiting for the human operator. It explains the two human-interaction modes (approval and handoff), which helps distinguish it from normal browser_wait, though it does not explicitly name that sibling as an alternative.

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

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

It gives explicit triggering conditions: use with approvalId after approval.required, or with no arguments after handoff.required for CAPTCHA or login. It also includes a clear prohibition against solving CAPTCHAs directly, though it does not contrast usage with browser_wait.

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