BrowserPair

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope, so the safety profile is covered. The description adds useful behavioral context about profile labels and online status, though its "Read-only" sentence largely repeats the annotations.

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

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

The description is front-loaded with the return content, then explains label matching and ambiguity handling in a compact sequence. The brief "Read-only" sentence is slightly redundant but does not undermine the efficient structure.

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 input parameters and no output schema, the description still explains what is returned: available Chrome profiles and whether each is online. It also covers the key label-resolution behavior needed before invoking browser_run.

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 there is no parameter semantics for the description to explain. Per the rubric, a 0-parameter tool receives a baseline of 4.

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: "List the user's Chrome profiles this BrowserPair connection may use and whether each is online." This clearly distinguishes the listing operation from browser_run and other task-oriented siblings.

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

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

Provides explicit selection guidance for named and unnamed browsers: use the label that matches the user's named browser, and ask which one when several are online and none was named. It does not explicitly state when to call browser_list instead of browser_run, so it falls short of full alternative 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?

Annotations cover only safety hints (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false); the description adds material context beyond them: cost model (one task credit per accepted task), replay semantics ('returns that task with replayed: true'), confirmation pausing in Chrome, and the domain/capability ceiling the task runs under.

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

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

Four sentences, each load-bearing: scope/allowlist first, then the continuation model, then the cost/idempotency contract. No restatement of the tool name or 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 7-parameter, open-world, credit-consuming task launcher with no output schema, the description supplies the essential missing model: what the task can touch, that it is inert until continued, and that a replayed call returns an existing task instead of consuming a new credit.

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 real semantics: capabilities default to low-risk browsing, allowed_domains is a hard visit allowlist, and idempotency_key is retry-only rather than a general dedupe key. max_side_effects and confirmations are left entirely to 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+resource ('Start a browser task') plus the unusual scope ('in the user's own Chrome profile') and the allowlist restriction. It also distinguishes itself from siblings by naming task_state, task_subgoal and task_respond as the continuation tools rather than alternates.

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 the tool does not act by itself and routes the agent to the three continuation tools. It also gives when-to-use guidance for capabilities ('default to ordinary low-risk browsing', add fill/click when needed) and for idempotency_key ('reuse only to retry the exact same request after a lost response').

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds genuinely new context: the blast radius is bounded ('work already done on websites is not undone') and repeat calls on finished tasks are no-ops, which sharpens the idempotency claim with concrete 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 short sentences, front-loaded with the action and effect, then the two behavioral caveats. Nothing is redundant or padded.

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, no-output-schema tool whose annotations cover safety, the description supplies what matters: the resource released and the non-destructive scope. Missing only the task_id provenance and error behavior on an unknown id.

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

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

Schema description coverage is 0% and the single parameter task_id is never mentioned in the description, so nothing tells the agent where the id comes from (task_state, browser_run output) or what format it takes. This is the one part of the definition the schema does not carry.

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 ('Cancel a BrowserPair task') plus the concrete side effect ('release the user's browser'). The cancel verb cleanly separates it from the read/inspect siblings (task_state, task_observe, task_diagnostics) without needing to open 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 clear context for when to call it (to stop a task and free the browser) and implicitly covers the repeat-call case with 'Already-ended tasks stay as they are'. It does not name an alternative tool or state any exclusion, so it stops short of full 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?

Beyond the annotations, the description discloses important behavior: collection is sequential rather than atomic, console events may predate it, output is bounded and redacted (no cookies, headers, bodies, query values, other sites' paths), unproved console contexts are withheld, website messages are untrusted, and it requires read/diagnostics_read permissions.

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 purpose and is dense with useful operational detail. It is somewhat long for a two-parameter tool, but most sentences earn their place; only the final 'Read-only' mildly repeats the annotation.

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 should clarify return values. It hints that 'the next task_state returns interaction.snapshot.rich and an image only when coherent' but does not directly describe what task_diagnostics itself returns, leaving the response shape ambiguous despite otherwise rich behavioral 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 carry parameter meaning. It lists the kind categories (console, network, assets, bundle) and explains what the bundle collects, but it does not fully define each enum value's distinct output or add meaning for task_id.

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 clear verb and resource: 'Read console, network or public asset metadata from the task-owned tab.' It distinguishes the diagnostic kinds and mentions the relationship to task_state, but it does not explicitly differentiate this tool from siblings like task_observe or browser_run.

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 provides a prerequisite ('Needs read and diagnostics_read') and implies the tool's role, but it never explicitly states when to use it versus alternatives such as task_observe or task_state. Usage is inferable rather than 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?

Annotations already declare readOnlyHint/destructiveHint/openWorldHint/idempotentHint, so the safety profile is partly covered, and 'Read-only' repeats that. The description earns credit for genuine additions: masking and redaction of sensitive fields unless Developer mode is 'Allow all', and the prompt-injection warning that page content is untrusted text. It doesn't describe latency or when the image fails to match observed elements beyond the conditional 'when the image matches'.

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

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

Four sentences, all front-loaded with purpose first, then mode behavior, then security constraints. It is information-dense with little waste, though 'Read-only' duplicates the annotation and could be dropped.

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 output schema, the description correctly explains what comes back (image content surfacing via the next task_state in screenshot/combined modes) plus redaction and untrusted-content caveats. The main gap is that the non-image modes an agent would select from the enum are not characterized.

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 25%, so the description must compensate, and it does so only partially: it clarifies the behavior of screenshot/combined modes and ties sensitive_category to redaction/masking. Scope (full-page vs relevant-region) is mentioned only glancingly as 'a full-page view', and lite/accessibility/dom modes and the practical difference between them go unexplained.

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 ('request a fresh observation of the task's current page') and immediately delimits it with 'without acting on it', which separates it from action-oriented siblings like browser_run. The modes and content types it can return are named, so an agent knows what it's asking for.

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 the operational context (a fresh observation, with task_state returning image content for screenshot/combined modes) and gives an explicit when-not for sensitive_category: 'Never for general reading, summaries or listing page text.' It does not explicitly name alternatives like task_state vs browser_run, so it falls short of a full routing guide.

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?

It adds substantial behavior beyond the annotations: risky actions pause for Chrome approval, uncertain effects are never repeated automatically, dialogs and downloads have defined handling, file contents are never returned, adopted tabs stay with the user, viewport changes reset, and user_step secrets are handled by BrowserPair. These details materially help the agent predict side effects and approval gates.

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 purpose is front-loaded, and the detail is justified by a complex 26-kind action model. However, the description is a single dense paragraph with many semicolon-separated clauses, making it harder to scan than a structured list would be.

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 browser-control tool with no output schema and annotations that only cover safety, the description covers the major behavioral edge cases: approvals, dialogs, downloads, uploads, tabs, viewport control, user steps, and handoff. It still leaves some action kinds and expectedOutcome semantics less explained, so it is strong but not fully 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 description explains key nested parameters and action-specific semantics: acceptDialog, allowDownload, file with kind upload, tabId with switch_tab/close_tab/adopt_tab, width/height with set_viewport, reason/method with user_step, and summary with handoff. It does not cover every parameter, such as expectedOutcome, modifiers, targetRef, or coordinate fields, and the schema itself provides some nested field descriptions.

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

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

The description states a specific verb and resource: performing one browser action from the current observation, plus resolving, completing, or blocking the task. It clearly explains the tool's scope through many action kinds, but it does not explicitly differentiate itself from sibling tools such as browser_run or task_observe.

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 extensive conditional guidance for sub-actions: use kind switch_tab for tabs, kind user_step for sign-in/CAPTCHA/payment, kind handoff when the user should continue, and acceptDialog/allowDownload for dialogs and downloads. It lacks explicit when-not-to-use guidance or named alternatives among the 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?

Goes well beyond the annotations: it explains the conditional input_required response shape, warns that page text is untrusted website content not instructions, clarifies that observation.human_verification is only a structural hint and not permission to bypass, notes sensitive-field masking except in Developer mode, and confirms the read-only nature declared by readOnlyHint. No contradiction with annotations.

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

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

Front-loaded with the core purpose and the highest-risk caveats (untrusted content, human-verification), and every sentence carries operational content. It is dense and on the long side, but little of it is filler.

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

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

With no output schema, the description carries the return-value burden and does so: it names the response fields and conditions (input_required observation, intelligence.skill versioning, image content when a screenshot matches). An agent has enough to interpret results and choose a next step.

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?

Only one parameter (task_id) with 0% schema description coverage, and the description never characterizes it (e.g., that it must be a task ID from browser_list or a prior call). The name is largely self-explanatory, so this is adequate but not compensating for the coverage 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?

Opens with a specific verb+resource ('Get the latest state of a BrowserPair task') and enumerates the exact facets returned: approval waiting, uncertain last effect, verified result. It is clearly distinguishable from siblings like task_observe (which supplies imagery) and task_respond (which submits input).

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?

Explicit routing rules: call task_observe with mode screenshot/combined to get an image then task_state; use user_step with reason verification when the user must complete a human-verification; inspect screenshot and DOM when an action failed or refs are unclear. Both when-to-use and the alternative tools are named.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, readOnlyHint=false and idempotentHint=false, but the description adds real context beyond them: the confidence-threshold operating loop, the return-on-uncertainty/blocked behavior, the no-model short-circuit, and the Chrome approval pause for risky actions. It stops short of describing the shape of what comes back on success.

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

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

Four sentences, front-loaded with the core action and free of filler; the behavioral caveats are grouped at the end where they belong. The second sentence is somewhat run-on, but every clause contributes operational information rather than padding.

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 destructive, open-world mutation tool with no output schema, the description covers the safety and control-transfer story well but omits the return payload on success and all parameter semantics, including the observation_mode/observation_scope enums an agent must set to call it correctly. Adequate, but with a clear parameter-level 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?

Schema description coverage is 0% across 7 parameters, so the description carries the full burden, yet it never explains subgoal, task_id, skill_id, max_steps, success, observation_mode, or observation_scope. Only a loose hint ('bounded subgoal', 'the task's sites and permissions') touches the schema at all, leaving two enums and the step limit 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 names a specific actor (BrowserPair Reflex), a verb (give a bounded subgoal to carry out), and a scope (in the user's browser). An agent can tell this delegates autonomous browser work rather than, say, observing state. It does not, however, distinguish itself from the sibling browser_run, which is the most likely confusion 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 routes the agent forward in one case (when no Reflex model exists, continue with task_respond) and explains when control is returned, which is useful implied guidance. It gives no explicit rule for choosing task_subgoal over alternatives like browser_run or browser_list, so the main selection decision is left to inference.

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