Browse Bridge

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

Annotations cover only the generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description adds the behavior that matters: exact one-entry step semantics, the sign-in-prompt cancellation side effect, that FORM_RESUBMISSION_REQUIRED means nothing is reloaded or resubmitted, and that ORIGIN_NOT_ALLOWED leaves the tab unmoved and is recoverable. That is genuine context beyond the annotations, and nothing contradicts them.

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 action, then the history-step rule, then edge cases and error codes. Dense but every sentence carries distinct behavioral information; the error-code list is compact. Slightly packed, but 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?

With no output schema, the description carries the return/error burden and does it well: it enumerates the meaningful failure codes and their consequences. The remaining gap is the undocumented sessionId parameter, which an agent needs in order to invoke the 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?

Schema coverage is only 50%: idempotencyKey is fully documented in the schema, but sessionId has no description anywhere. The description never mentions either parameter, so it does not compensate for the undocumented sessionId or explain what a session id must reference for this tool. Below the 3 baseline because of that 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?

"Go back one history entry in the delegated tab" states a specific verb (go back), resource (browser history entry), and scope (the delegated tab). It explicitly contrasts with browser_forward ("back and forward move exactly one browser history entry") and browser_navigate, so an agent can distinguish it from siblings without reading 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?

It names concrete situations: after a cancelled sign-in an extra back may be needed, when a sign-in prompt is up back cancels the prompt instead of stepping history, and for form submissions it says "Use navigate instead." The alternative is named explicitly with the condition that selects it.

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 beyond the annotations (which only declare the mutation/safety profile) by stating the concrete consequence: the waiting command fails. That is exactly the kind of downstream effect an agent needs before invoking a non-read-only, non-idempotent tool. It does not say what happens on a second cancel or what the response contains, keeping it at 4.

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, then requirements, then the behavioral consequence. Nothing is redundant with the title or annotations.

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 mutation with no output schema, the description covers action, prerequisites, parameter provenance, and the observable side effect (the waiting command fails). An agent has everything needed to decide and call it correctly.

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

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

Schema coverage is 0%, so the description must carry the load — and it partly does by naming both required parameters and, crucially, telling the agent where approvalId comes from (APPROVAL_REQUIRED or APPROVAL_PENDING). sessionId is only implied (browser session), leaving a small gap from a 5.

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?

Uses a specific verb+resource pair ('Withdraw a pending approval') scoped to approvals the agent itself requested. It also explicitly distinguishes the action from a human Deny, which no sibling tool name conveys. It is not quite a 5 because it doesn't name a sibling tool as the alternative path.

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 conditions: only for pending approvals that the agent requested, identified by APPROVAL_REQUIRED or APPROVAL_PENDING. The 'this is not a human Deny' clause steers the agent away from a wrong mental model. No explicit exclusion against simply continuing to wait, so it stops 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?

Goes well beyond the annotations: discloses that events are not isTrusted, per-session FIFO serialization (5s wait) that holds across server instances, click pacing with RATE_LIMITED, approval flow with expiration and recoverability semantics, and the 30s dialog timeout. This is unusually rich behavioral context for a mutation tool.

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

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

The first sentence is front-loaded and the rest is a single undifferentiated block of error-code prose with repeated content ('STALE_OBSERVATION means the page changed — observe again' appears twice, and 'Do not omit observationId' duplicates the required-field list). Bullets or grouping by error family would make it far easier to scan.

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, non-idempotent click there is no output schema, yet the description covers error semantics, concurrency, dialog state, approvals, and rate limiting — everything an agent needs to call it correctly and recover from failures.

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%, and the description compensates by explaining that elementId comes from browser_observe, that observationId is the observation token and must not be omitted, and that button maps left/middle/right with right meaning contextmenu. idempotencyKey semantics live in the schema, so nothing critical is lost, but sessionId is never characterized.

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 a semantic element from the latest observation') and ties the element to browser_observe via elementId, which separates it from siblings like browser_hover or browser_type. An agent can tell exactly what this tool does without opening the 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 routes to alternatives and follow-ups: re-observe after STALE_OBSERVATION, use browser_handle_dialog for open dialogs, browser_cancel_approval to cancel approvals, and the human must click file pickers. It also states what not to do ('Do not retry through CHALLENGE_DETECTED').

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 by naming the three failure modes (HTTP_AUTH_REQUIRED, NO_HISTORY_ENTRY, ORIGIN_NOT_ALLOWED), stating whether the tab moves, and flagging ORIGIN_NOT_ALLOWED as recoverable. That is real behavioral context, though the interaction with the idempotencyKey replay window is left to the schema.

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 core action is front-loaded in the first sentence and the remainder is dense, non-redundant edge-case and error documentation. It is longer than average but nearly every clause adds a distinct rule an agent would otherwise have to discover by trial.

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 navigation tool with no output schema, the description covers success semantics, all failure codes, whether the tab moves, and the recovery path. An agent has enough to call it and to interpret any result without further documentation.

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 50%: idempotencyKey is thoroughly documented in the schema, but sessionId has no description and the description does not explain it either, only implying via "delegated tab" that state is session-scoped. Baseline 3 fits for a tool whose schema carries most parameter meaning.

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: "Go forward one history entry in the delegated tab." The follow-up sentence explicitly contrasts it with back, letting an agent separate it from the sibling browser_back without reading either 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?

Covers the normal case (one history entry), the sign-in-cancel edge case where an extra back is needed, and the blocked case with concrete alternatives: "Call back (cancels the prompt) or navigate elsewhere." That is explicit when-to-use and when-to-do-something-else 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?

The description adds extensive behavioral context beyond the annotations: sensitive-mode approval behavior, stale heartbeat handling, quota tracking, dialog states, Chrome error distinction, and extension version compatibility checks. This is far more than the readOnly/idempotent annotations provide.

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 first sentence is appropriately front-loaded, but the rest is a dense, long block of status-code details. Much of it is relevant, yet the structure is hard to scan and could be organized more clearly.

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?

Because there is no output schema, the description carries the burden of explaining return values, and it does so extensively with status codes, quota fields, dialog shapes, and error semantics. It is only missing sessionId sourcing and usage 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 description coverage is 0% for the single required sessionId parameter. The description only says 'for a session' and does not explain where to obtain sessionId, its expected format, or how it relates to browser_list_sessions.

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 states a specific verb and resource: 'Get control mode and tab status for a session.' It is clearly a status-reading tool, though it does not explicitly distinguish itself from siblings like browser_observe or browser_list_sessions.

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 many status codes and behaviors but never says when to call this tool versus alternatives such as browser_observe or browser_list_sessions. There is no explicit when-to-use or when-not-to-use 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?

Goes well beyond the annotations: concurrent-call race behavior, the 30s timeout with automatic dismissal recorded in History, warning emission when promptText is ignored, and an explicit statement that it does not click, type, or capture. This is the exact behavioral context an agent needs for a mutating, open-world tool.

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

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

Front-loads the action and promptText semantics before edge cases, and each sentence adds a distinct fact. Slightly dense with the CDP method references that add little for an agent.

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, and the description supplies the return signals (NO_DIALOG, warning on ignored promptText, timeout recording) so an agent can interpret results. Nothing needed 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?

Schema coverage is 0%, so the description carries the burden and largely does: it defines the two action values and constrains promptText to accepting prompts with a max length, plus the ignored-with-warning case. Only sessionId is left to obvious inference.

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 pair (accept/dismiss) and resource (the pending JavaScript dialog on the shared tab), scoping it to one dialog. It is clearly distinguishable from sibling tools like browser_click or browser_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?

Explains when each action applies, that promptText is only meaningful for prompts, and what happens with no pending dialog (NO_DIALOG). It doesn't explicitly name sibling alternatives to use instead, but the triggering condition is unambiguous.

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?

Adds substantial context beyond the annotations: the hover is synthetic and not persisted, hidden captions are omitted before hovering, events are not isTrusted, and the revealed text is ephemeral. This is genuinely useful for an agent interpreting results. The readOnlyHint=false framing is somewhat ambiguous for a non-mutating inspection action, but the description doesn't contradict it.

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-loads the action, then the requirements, then the key caveats about ephemeral revealed text. Mostly dense and purposeful, with only the parenthetical example adding mild slack.

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 usefully explains the return value (textSummary including newly visible caption/tooltip text) and the ephemerality caveat. It is nearly complete, lacking only fuller explanation of the observation/element identifier semantics and error behavior.

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

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

Schema coverage is only 25% (only idempotencyKey is documented), so the description should compensate more. It lists the three required parameter names and implies observationId ties to "the latest observation," but adds no format or meaning for sessionId/elementId beyond what the schema already shows via pattern and length constraints.

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 ("Hover a semantic element from the latest observation") and clarifies the underlying events (mouseover/mouseenter). It is clearly distinguishable from siblings like browser_click or browser_select by the action itself, 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?

Gives a clear operational context (use it to reveal caption/tooltip text) and an important consumption rule: the revealed text is only on this result and is gone from the next browser_observe, so the agent must read it now. It doesn't state explicit when-not-to-use or name an alternative tool, which keeps it below 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?

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds valuable return-behavior details beyond annotations, including dialog presence, HTTP_AUTH_REQUIRED blocking, and title fallback semantics, though it does not cover ordering, pagination, or full session object shape.

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, then efficiently explains edge-case return fields. It is dense but each sentence adds useful interpretation detail; a bulleted structure might improve scanability slightly.

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 carry the burden of explaining return values. It covers several tricky fields and edge cases, but does not describe the overall session list structure or all fields an agent might receive.

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 are no parameter semantics to document. The baseline score of 4 applies because no parameter-level explanation 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 clearly states the verb and resource: 'List browser sessions the user has delegated.' It communicates scope well enough for an agent to understand the operation, but does not explicitly distinguish it from siblings such as browser_get_status.

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

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

There is no explicit guidance on when to use this tool versus alternatives like browser_get_status or browser_observe. The description names the resource but provides no exclusions, prerequisites, or alternative-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?

Well beyond the annotations (which only say non-readOnly, open-world, non-idempotent): it discloses URL userinfo stripping and redaction across status/sessions/history, the ~5s busy-wait before navigating, history-push side effects on the top window, pacing/rate limits, approval gating for sensitive and cross-origin sites, HTTP auth blocking, and pending JS dialogs with DIALOG_PENDING on re-navigation.

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?

Purpose and required parameters are front-loaded, and the remaining sentences are each tied to a distinct error state an agent must handle. It is dense and long for a single paragraph, with error-code detail (BUSY, RATE_LIMITED, APPROVAL_REQUIRED, HTTP_AUTH_REQUIRED, DIALOG_PENDING) that could be grouped, but no sentence 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?

No output schema exists, and the description documents failure and side-effect shapes thoroughly (dialogs, approvals, rate limits) but says nothing about what a successful navigation returns — final URL, page state, or load-completion signal — leaving the agent to infer success behavior.

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

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

Schema coverage is only 33% — url and sessionId have no schema descriptions — but the description compensates partly by stating both are required, that url must be an allowed http(s) origin, and that userinfo is stripped before navigation. It adds no semantics for sessionId beyond its required status, and the idempotencyKey is already richly documented 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?

States a specific verb (navigate) and resource (the delegated tab) plus the scope constraint ('allowed http(s) origin'). It also differentiates from siblings by explaining that navigation pushes a history entry so browser_back/browser_forward operate on it, and explicitly excludes observationId, separating it from browser_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?

Gives actionable conditions for the common failure paths — retry with sessionId and url on BUSY, wait retryAfterMs on RATE_LIMITED, do not wait for command timeout on cross-site APPROVAL_REQUIRED, call back or navigate elsewhere on HTTP_AUTH_REQUIRED. What's missing is an explicit contrast with sibling actions for the same goal (e.g., browser_reload vs re-navigating to the same URL).

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?

Well beyond the annotations (readOnly/idempotent/openWorld), it discloses that returned page content is untrusted, how dialogs short-circuit the call (DIALOG_PENDING, pending: true), how truncation is computed (2000-char textSummary, flags.totalTextLength, flags.truncated edge case), and the exact remediation for CHALLENGE_DETECTED, ORIGIN_NOT_ALLOWED, CONTENT_SCRIPT_UNAVAILABLE, EXTENSION_RECONNECT_NEEDED and HUMAN_HAS_CONTROL. That is precisely the failure-mode context the annotations cannot carry.

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 front-loaded sentences set up purpose and returns well, but the remainder is a dense run-on paragraph where truncation math, frame injection, dialog state and a five-item error-code catalog all blend together. Every clause is informative, but the lack of structure (bullets or sentence breaks per concern) makes it harder to scan than its content warrants.

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 6-parameter read tool with no output schema, the description does describe the response surface (observationId, elements with ids, textSummary, flags, dialogs) and the observable failure states, so an agent can call it and interpret results. Gaps remain around maxElements and includeTextSummary, which are neither in the schema nor named in prose.

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 mostly does: it explains textOffset slicing semantics with a concrete 0/2000/4000 walkthrough, the page-vs-offset mutual exclusion with the INVALID_ARGUMENT outcome, and the flags.textLimit default. Weakness: maxElements and includeTextSummary are only obliquely referenced ("the element window," "flags.textLimit") rather than named and explained.

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 ("Observe the delegated tab as a semantic page tree") and immediately names the return shape (observationId + elements). It also disambiguates from siblings by stating that the observationId/elementId pair is what feeds browser_click, browser_type and browser_select, so an agent can tell what this tool is for versus those.

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 makes the workflow role clear: observe, then pass observationId with elementId to the interaction tools, and it explicitly says a repeat with nothing new returns an empty dialogs list. It does not, however, say when to prefer this over sibling browser_screenshot or browser_get_status, nor when not to call it, so it stops short of full alternative routing.

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: validation happens before the tab is touched, exact INVALID_ARGUMENT messages for duplicate modifiers/unknown tokens/missing keys, HUMAN_INPUT_REQUIRED semantics for sensitive fields, INVALID_INPUT_VALUE for untypeable inputs, target reporting on the result, untrusted events, and RATE_LIMITED pacing. This is exactly the mutation-risk context destructiveHint=true implies but cannot explain.

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?

Purpose is front-loaded and every sentence carries actionable information, but the body is a dense run-on sequence of error cases that would read better as short grouped sentences or a compact 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 destructive, open-world mutation tool with no output schema and low parameter coverage, the description supplies the error taxonomy, the sensitive-field safety rule, the result shape (target), and rate-limit handling. An agent has everything needed to call it correctly and interpret failures.

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%, so the description carries real weight — 'key' gets a full accepted-key enumeration and chord grammar, and elementId/observationId get their dependency and fallback behavior spelled out. sessionId and idempotencyKey are left to the schema (idempotencyKey does have a schema description), which is acceptable coverage.

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

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

The first sentence gives a concrete verb and resource ('Press a keyboard key in the delegated tab') and the supported-key list plus the note 'Modifier chords do not insert text' implicitly separates it from browser_type. It never names a sibling tool explicitly, so the differentiation is inferred rather than stated.

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?

Extensive conditional guidance: elementId requires observationId, no elementId means the key goes to the focused element, password/one-time-code fields return HUMAN_INPUT_REQUIRED for printable keys but still accept Tab/Enter/Escape, and rate limiting means waiting retryAfterMs. It lacks an explicit 'use browser_type instead when...' routing statement but the context is otherwise unambiguous.

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 the success payload shape ({ controlMode: "human" }) and that the operation works during a pending approval. It also clarifies that this is not HUMAN_HAS_CONTROL, which adds behavioral context without contradicting 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 short and front-loads the core action. The final sentence about HUMAN_HAS_CONTROL is ambiguous and slightly reduces clarity, but otherwise there is little wasted text.

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 annotations and no output schema, the description covers purpose and some behavior. However, it leaves the sessionId parameter unexplained and the HUMAN_HAS_CONTROL reference unclear, so it is only minimally 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 schema has zero description coverage and the description never mentions sessionId, so it adds no meaning beyond the parameter name. The single required identifier is somewhat self-explanatory, but the description does not compensate for the missing schema documentation.

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

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

The description clearly states a specific verb and resource: returning control of the tab to the human. It also distinguishes this from HUMAN_HAS_CONTROL, though that phrase is cryptic and no sibling tool is named 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?

It implies when the tool is usable by saying it works while an approval is pending, but it does not state when to prefer it over alternatives such as browser_cancel_approval or browser_get_status. Usage guidance is present but incomplete.

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=false, idempotentHint=false and openWorldHint=true, and the description adds nothing beyond them. It does not say that reload may re-submit forms or replay POST side effects (which is why it is non-idempotent), nor what happens if the tab has no loaded page.

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

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

A single front-loaded sentence with zero waste, but its brevity is under-specification rather than efficiency given the missing context.

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 must cover return behavior and failure modes (e.g. no active session, no loaded page) and does neither. The required sessionId's meaning is left entirely unexplained.

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 50%: idempotencyKey is richly documented in the schema, but sessionId has no description anywhere and the description does not compensate by explaining that it identifies the delegated browser session. For a tool whose only required parameter is undocumented, this is a real 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?

States a specific verb ('Reload') and resource ('the delegated tab'), which an agent can distinguish from browser_navigate or browser_forward. It never defines what a 'delegated tab' is or which session it belongs to, 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?

No guidance on when to reload versus calling browser_navigate to the current URL, and no prerequisites (an active delegated session) are mentioned. The agent must infer the trigger condition entirely.

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?

Discloses behavior well beyond the annotations: the exact response envelope, the ORIGIN_NOT_ALLOWED no-capture path, the debugger-detach fallback, CAPTURE_PERMISSION_MISSING remediation, the fact that a failed screenshot does not consume screenshotsRemaining, and RATE_LIMITED with retryAfterMs. These are concrete operational facts an agent cannot infer from readOnlyHint/idempotentHint alone.

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 return format, which is what an agent most needs, and every sentence carries an error-path or capacity fact. It is dense and slightly crammed into one block, but there is little 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 fully specifies the return values and error semantics, which is the important gap to close. The remaining hole is parameter meaning for a 2-parameter tool, which leaves it short of 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% and neither parameter is explained. sessionId is only obliquely implied by 'shared tab,' and the 'reason' field is never mentioned at all, so the description does not compensate for the schema 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?

States a specific verb and resource (returns a JPEG of the visible shared tab) and specifies the exact return shape: MCP image content plus a small JSON text part with observationId, width, height. This is precise enough to distinguish it from browser_observe, which is not an image-returning tool.

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 preconditions: capture only runs when the tab origin is in allowedOrigins, site access for that origin is sufficient, and Chrome permission prompts require Enable or Reconnect. It doesn't explicitly compare against siblings like browser_observe or browser_get_status, so the when-not guidance is implied rather than 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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds valuable behavioral detail beyond that: elementId requires observationId, calls with no scroll target are invalid, and numeric inputs are bounded. It still omits some side-effect context, but it meaningfully exceeds the annotation coverage.

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 and compact, with four sentences that each carry invocation constraints or validation information. It avoids wasted prose, though the repeated INVALID_ARGUMENT phrasing is slightly verbose.

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 10-parameter tool with no output schema and very low schema description coverage, the definition covers the main scrolling modes and validation rules. It remains incomplete because amount is undocumented and the interaction between coordinate, delta, direction, and elementId modes is left mostly implicit.

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 10%, so the description needs to compensate. It covers direction values, elementId/observationId dependency, and numeric bounds for x, y, deltaX, and deltaY, but it never mentions the amount parameter and does not explain the distinct semantics of x/y versus deltaX/deltaY.

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 gives a specific verb and resource: scroll the page or a semantic element into view. It is immediately distinguishable from siblings like browser_click, browser_navigate, or browser_observe without needing schema inspection.

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 how to invoke scrolling with direction, deltas, coordinates, or elementId, and notes the observationId dependency. However, it does not say when to use this tool versus alternatives such as browser_observe or browser_wait, nor does it describe when not to use it.

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 annotations by enumerating failure modes (WRONG_ELEMENT_TYPE, INVALID_SELECT_VALUE, OPTION_DISABLED) and stating that these failures leave the select unchanged. It also clarifies observation validity after failures. Minor gap: it does not discuss side effects of a successful selection or the idempotencyKey behavior, even though idempotentHint is false.

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 action and required parameters, then proceeds through error conditions in short, information-dense sentences. No filler; every sentence carries actionable error or state 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?

With no output schema and a mutation tool, the description provides strong error semantics and state-change guarantees. It is slightly incomplete because it omits the idempotencyKey contract and does not say what a successful selection returns or whether it can trigger navigation or form submission.

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% (only idempotencyKey is documented), so the description must compensate. It does so partially: it lists the required parameters and explains that value must match an <option value> or a unique option label, which is the critical semantic the schema lacks. It does not explain elementId format or the idempotencyKey.

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: 'Select a value on a <select>'. This is unambiguous and immediately distinguishes it from sibling actions like browser_click or browser_type, which target different element kinds.

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?

Use is implied by the element requirement (a <select>), and the description tells the agent to 'observe again and retry' on STALE_OBSERVATION. However, it never explicitly says when to choose this over browser_click, browser_type, or browser_press_key, so the agent must infer the routing.

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 destructive/openWorld annotations: discloses that typed values are excluded from the audit log, that generated events are not isTrusted and the flag is not spoofed, that failed typing leaves page state untouched, and that password fields cannot be approved-and-typed. This is exactly the safety-critical context an agent needs before mutating a page.

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 action, then dense failure-mode clauses; every sentence carries distinct information, including the useful note that there is no Approve path for passwords. It is a long unbroken block with no structural grouping, which slightly hurts scannability.

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 6-parameter, non-idempotent, destructive browser action with no output schema, the description covers the failure modes, approval flow, trust flags, and audit behavior thoroughly. The remaining gaps are the undocumented 'submit' flag and the absence of any statement about what a successful call returns.

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 17%, so the description must carry the load. It clarifies text semantics (length counted in Unicode code points) and the failure behavior tied to elementId's editability, but leaves 'submit' completely unexplained and adds nothing on sessionId or observationId, so several parameters remain opaque in both places.

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 (type) and precisely scoped resources (text field, textarea, contenteditable), plus the precondition that it operates from the latest observation. The resource list implicitly separates it from browser_select (dropdowns) and browser_press_key (key events) among 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?

It gives clear conditions and exclusions for the tool's own operation: non-editable elements return ELEMENT_NOT_INTERACTABLE, invalid input types return INVALID_INPUT_VALUE, sensitive sites require APPROVAL_REQUIRED, and password fields must be handled by a human. It never explicitly routes to a sibling (e.g. click for buttons, select for dropdowns), which keeps it out of the top band.

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 establish readOnly, idempotent, non-destructive behavior, and the description adds substantial extra context: value bounds, the mutual-exclusion rule, the returned waitedMs/clamped fields, and explicit outcome codes for TIMEOUT, HUMAN_HAS_CONTROL, and DIALOG_PENDING. Nothing contradicts 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?

Front-loaded with purpose, then validation, then result and outcome codes — a sensible order with little filler. The closing sentence about a 'second release' returning ALREADY_RELEASED describes browser_release_control behavior rather than wait behavior, so it is marginal noise for this 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?

With no output schema, the description usefully explains that the result reports waitedMs and clamped and enumerates the failure modes. It is nearly complete for a 4-parameter tool, missing only what sessionId means and what happens if neither ms nor durationMs is supplied (the default wait length).

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 50% (ms and durationMs are documented; sessionId and urlIncludes are not), and the description compensates by spelling out the 0–30000 bounds, the INVALID_ARGUMENT conditions for negatives, oversize values and sending both fields, plus the TIMEOUT semantics of urlIncludes. Only sessionId is left without any explanation 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?

The opening sentence gives a specific verb and resource ('Wait briefly for page activity'), which is distinguishable from mutating siblings like browser_click or browser_navigate. However, 'page activity' is slightly misleading since the tool takes a fixed duration rather than detecting load/network activity, so the agent must read further to learn it is a timed sleep.

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 through the urlIncludes parameter (wait until a URL substring appears) and the error codes, but there is no explicit statement of when to call wait versus browser_observe or browser_get_status, nor any prerequisites such as needing an active session.

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, idempotentHint, and destructiveHint=false, so repeating 'Read-only' adds little. The description's real value is the explicit negative guarantee about what is withheld (email, tokens, cookies, page content), which tells the agent it cannot harvest credentials or content here — context the annotations do not carry.

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 with zero waste, front-loading the return value before the safety and exclusion notes. Nothing is padded or restated from the title.

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-param, read-only identity lookup with no output schema, the description covers what is returned and what is deliberately not returned. It stops short of naming the actual response field or confirming the auth precondition, but an agent has enough to call 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly signals a no-argument call by not mentioning any inputs.

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: returning the stable Browse Bridge user id for the signed-in account. This clearly separates it from browser_list_sessions and browser_get_status, which deal with sessions and status rather than account identity.

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 — call it when you need the account's identity — but no sibling is named as an alternative and no prerequisite (e.g., must be signed in / a live control session) is stated. The negative disclosure ('does not return email, tokens, cookies, or page content') gives partial 'when not to use this' guidance by ruling out credential or content retrieval.

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