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

With no annotations, the description carries the full burden. It explains why a task pauses but says nothing about what resuming does to task state, whether answers are validated, permission requirements, or reversibility. The trigger context is useful but far from complete for a state-mutating 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?

A single front-loaded sentence with the core condition stated immediately and no filler. It earns its brevity but is arguably too terse for the missing detail an agent needs.

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 mutation tool with zero annotation coverage, no output schema, and 0% parameter documentation, the description supplies only the trigger scenario. It omits parameter formats, permissions, and task-state outcomes, leaving meaningful gaps.

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 required parameters, so the description must compensate. It hints that the answer may be a confirmation or sign-in input, but never explains 'taskId', the expected 'answer' format, or how the value maps to the paused prompt.

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 (resume) and resource (a task), plus the distinguishing condition that the task paused for a human. It implicitly separates itself from task_status by focusing on resumption rather than status checking, though it never names a sibling explicitly.

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

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

It clearly states the situation that selects this tool: a task that stopped needing a human, such as a confirmation or a browser sign-in that is now done. There is no exclusion or named alternative, keeping it short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: typing is dispatched key-by-key so autocompletes fire, steps 'stop at the first that fails', and the result reports any dialog or error the action caused. It omits whether dialogs are auto-dismissed unless acceptDialog is set — though that is in the schema — and says nothing about authorization or side-effect scope.

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 action inventory, then the operational caveats, then the alternative — a sensible ordering. The single dense paragraph with nested parentheticals is heavier than ideal, but nearly every clause conveys distinct behavior rather than 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 10-parameter mutation tool with no output schema and no annotations, the description covers actions, semantics of the important parameters, failure behavior, and the result contract. The main gap is tabId, which is documented in neither the schema nor the description, and no explicit guidance on browser_click overlap.

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 already 80%, so the baseline is 3. The description still adds meaning beyond it: it defines what 'press' accepts ('Enter', 'Tab', 'Control+a'), explains the replace-vs-append distinction for type, and clarifies that select's value is an option label or value for native or custom dropdowns. It leaves values undocumented for clear and scroll_into_view.

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 concrete verb ('Do one thing to an element') and enumerates the exact operations the tool performs (click, type, press, select, check, etc.), so the agent knows precisely what capability this is. It also marks the boundary of its scope by routing multi-step form workflows to browser_invoke.

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 explicit conditions in several places: 'For whole forms, prefer browser_invoke with the typed tool', 'without a target, presses on the focused element', and 'replaces unless append'. It does not, however, explain when to use this unified tool versus the sibling browser_click, which is the most likely disambiguation an agent needs.

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 readOnlyHint=true annotation by disclosing the key behavioral trait: the page never enters the agent's context, so the call costs hundreds of tokens instead of tens of thousands. It also discloses the degenerate mode ('without a model, it returns the passages relevant to your question instead'), which changes what the caller should expect to receive.

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 what the tool does and the cost rationale, with the fallback behavior last. Each sentence carries distinct information — purpose, cost benefit, degraded mode — with no restatement of the name or schema.

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 burden of describing returns and does so ('a short answer' or 'the passages relevant to your question'). What is missing is any mention of error behavior (unreachable tab, invalid tabId), which an agent may need for a tool that depends on live browser state.

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

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

Schema description coverage is 100%, so both parameters (tabId default-to-active-tab, question) are already documented in the schema, including the example question format. The description adds no further parameter detail, so the baseline of 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 and resource ('Ask a question about what is on a browser tab') and immediately explains the mechanism ('Deputy reads the page itself and returns a short answer'). The contrast with 'screenshotting or dumping the DOM' functionally separates it from browser_screenshot, browser_read, and browser_eval without the agent needing to open their 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?

Gives a clear selection rule: 'Use this instead of screenshotting or dumping the DOM,' which routes the agent away from heavier siblings when only a lookup is needed. It does not state a when-not case (e.g., when you actually need raw page content you should use browser_read/browser_extract), 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?

With only readOnlyHint available in annotations, the description carries the behavioral burden well and adds context annotations cannot: it names the return structure (typed tools, schemas, current values, clickable refs), guarantees completeness so probing is unnecessary, and discloses pagination semantics — long pages are windowed, the reply always states the true total, and narrowing/paging is via actionQuery/actionOffset.

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 sentences, front-loaded with the return contract, then the 'use this instead of X' routing, then pagination. Every sentence earns its place, though the clause 'it is complete, so you should not need to probe' slightly restates the completeness claim made one clause earlier.

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, so the description must explain the response — and it does, at a level that lets an agent consume the result without guessing. All three optional params are covered by the schema plus description guidance, and the readOnlyHint is consistent with a pure inspection 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 100%, so the baseline is 3, but the description goes beyond the schema's 'what' by supplying intent: actionQuery is for 'when you know what you want' and actionOffset is for paging through a long list, tying both to the windowing behavior. It adds genuine selection guidance, though it does not restate defaults or units.

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 resource ('the full contract of every open tab') and enumerates exactly what it contains: each form as a typed tool with JSON Schema, current field values, and every button/link with a ref. It also explicitly negates the closest sibling by saying it is read 'instead of a screenshot', so an agent can distinguish it from browser_screenshot without opening a 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 explicit when-to-use ('read this instead of a screenshot') and a when-not ('you should not need to probe'), plus steering on param use for long pages. It does not, however, position itself against the other discovery-flavored siblings such as browser_inspect, browser_find, or browser_look, so routing among those is left implicit.

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 largely fails it. It does not say whether clicking navigates, whether the call waits for the page to settle, what happens on a stale/invalid ref, or what the agent should do next — all critical for a browser click inside an automation loop.

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?

One short sentence with no filler, and the target source ("actions" list) is front-loaded. It is a touch terse and grammatically awkward ("Click something browser_capabilities listed"), but 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 mutation-ish browser interaction tool with no annotations, no output schema, and half its parameters undocumented, the definition is too thin. An agent cannot tell what state the page will be in after the click or how refs are refreshed, which is essential context for sequencing this in a browser workflow.

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%: "ref" is documented in the schema and the description usefully adds where refs originate (browser_capabilities "actions"), which is more than the schema's bare "Action ref, e.g. a10". The second parameter, tabId, is undocumented in both schema and description, so the coverage gap is not compensated.

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 concrete verb (click) and the target class (something browser_capabilities listed under "actions"), and the title narrows it to a button or link. The ref-based mechanism implicitly distinguishes it from siblings like browser_act or browser_invoke, but no sibling is named or contrasted 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 conveys the key prerequisite workflow cue — the ref must come from browser_capabilities' "actions" list — which tells an agent the ordering of operations. However, it gives no when-not-to-use guidance and does not mention browser_act, browser_invoke, or any alternative for interacting with elements.

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 readOnlyHint=true already covering safety, the description adds real context: the log scope ('from when an agent started driving the tab') and the important caveat that CSP/CORS internal messages are invisible without the debugger. It omits that the 'clear' parameter destroys prior output, which is a minor 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?

Front-loaded with what the tool returns, then the filter and the caveat. Efficient overall, though the fragment 'Filter by levels' is slightly clipped.

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 does a decent job describing the returned content, so that burden is met. However the undocumented limit/tabId parameters and the unstated side effect of 'clear' leave the definition only partially complete for a 4-parameter tool.

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

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

Schema coverage is only 25% (just 'clear' is documented). The description explains the level filter and its enum values, but that largely restates the schema enum, and it says nothing about 'limit' or 'tabId'. With low coverage it needed to compensate and does not.

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?

It names a specific resource and enumerates what is captured (uncaught exceptions with stacks, unhandled rejections, failed resources, console output). This clearly distinguishes it from browser_network or browser_inspect, though it never explicitly names those 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?

Usage is only implied – an agent can infer this is for diagnosing errors when driving a tab. There is no explicit 'use this when' clause and no comparison against the other diagnostics siblings like browser_network, which leaves the agent to infer the boundary.

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 so well: it discloses the default (dismissed, confirm returns false), that outcomes are reported in the action result, and the pre-emptive timing requirement. It does not describe interaction with tabId scope or error cases, so not 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?

Three sentences, front-loaded with purpose then behavior then usage. No filler; each sentence adds distinct actionable 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?

No output schema or annotations exist, so the description must stand alone, and it covers default behavior, timing, and the key parameter effects. Gaps remain on tabId semantics and whether text is required for prompt dialogs, keeping it from a 5.

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. It meaningfully explains accept ('for the next dialog') and persist ('keep answering that way') and implies text applies to prompts, but tabId is left entirely unexplained in both description and schema.

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

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

States a specific verb and resource: deciding how alert/confirm/prompt dialogs are answered on a driven tab. No sibling tool in the list handles dialog resolution, so it is naturally distinguishable from browser_ask, browser_fill, and browser_act.

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 timing guidance: 'Call this BEFORE the action that opens the dialog.' It also explains the effect of accept vs persist. There is no explicit statement of when not to use it or which alternative to prefer, 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?

With readOnlyHint=true already covering the safety profile, the description adds real behavioral detail: the wait action blocks until completion, and read converts text files to text, PDFs to extracted text, and everything else to path/type/size. It doesn't say what wait actually returns or what happens when a download never finishes.

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?

One purpose sentence followed by a tightly packed per-action breakdown, front-loaded so the agent learns what the tool is before the action details. No filler.

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

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

For a 3-param tool with no output schema, the description covers purpose, action semantics, and the read return format well enough to invoke correctly. It stops short of describing list/wait return shapes or timeout/failure behavior, which an agent relying on no output schema would benefit from.

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%, so the description must carry the load for action and id — and it does, defining all three enum values and explaining that id is optional for read with a newest-wins default. timeoutMs is left to the schema, which documents it.

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

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

The first sentence names a specific verb+resource (downloaded files) and the rest enumerates the three actions, so an agent can tell this apart from siblings like browser_upload, browser_read, and browser_wait without opening any schema. Each action's role is stated in a distinct clause.

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?

"wait" is tied to a concrete trigger ("the one just started (by a click)") and "read" is scoped to finished downloads, which gives clear selection context. What's missing is explicit routing away from siblings (browser_upload, browser_network, browser_read) or any statement of when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. The parenthetical about HTML5 vs pointer-driven libraries is genuinely useful behavioral context (the tool handles both DOM-native and synthetic pointer sequences), but it says nothing about permissions, return values, timing/settling behavior, or what happens if the drop target is not droppable.

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 that opens with the core action and uses the parenthetical only to add scoping value. Nothing is wasted and the essential meaning lands immediately.

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 5-parameter, zero-required-parameter mutation-style tool with no annotations and no output schema, the description is too thin. The ambiguous relationship between the *_ref and *_selector parameter pairs is a real gap that could cause failed invocations.

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?

All 5 parameters have 0% schema description coverage, and the description explains none of them. It never clarifies that fromRef/toRef are element handles versus fromSelector/toSelector being CSS selectors, nor whether one pair is an alternative to the other or both are required.

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 combination ('drag one element onto another') and even names the two implementation families it covers (HTML5 drag-and-drop, pointer-driven libraries). This clearly distinguishes it from a generic sibling like browser_click, though it never names the alternative 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?

No guidance on when to prefer this over browser_click, browser_act, or browser_eval for complex interactions. Nothing states prerequisites, e.g., that refs likely come from a prior find/look call, or whether a drag requires a separate wait before reading state.

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

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

With no annotations, the description carries the full burden and does well: it discloses the default execution world and its global-visibility consequence, the alternate 'isolated' world, promise awaiting, JSON-serialisability of results, and an environment prerequisite ('Allow User Scripts' switch for Deputy) with error-message guidance. It omits side-effect/error-behavior detail (e.g., whether thrown errors surface or page mutations persist), 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?

Four tight sentences, front-loaded with the core action and return contract, then edge behaviors. Densly informative with little waste, though the Deputy note and world clause could be trimmed 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 and no annotations, so the description must cover return values and constraints; it does both (JSON-serialisable result, awaited promises, permission prerequisite). The main remaining gap is the unexplained tabId parameter and no statement of error behavior, but the essentials for correct invocation are present.

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 `world` semantics (main default sees page globals, isolated keeps separate) and `code` semantics, but `tabId` is never addressed, leaving one of three parameters 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 ('Run JavaScript in the page and return its JSON-serialisable result'), which is clearly distinct from observation siblings like browser_read or browser_console. It does not explicitly position itself against those siblings, so it stops short of a 5.

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

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

It gives practical usage detail (expression vs statement with `return`, promises awaited, world selection, the Deputy switch), which implies when the tool applies, but it never states when to prefer this over browser_extract, browser_inspect, or browser_console. Usage guidance is implied 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?

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description adds genuine behavioral detail: the "auto" heuristic (biggest table, else biggest repeated list) and the scroll pairing for lazy-loading feeds, which are not captured by annotations or 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?

Two dense sentences, front-loaded with the core purpose before the auto heuristic and the workflow tip. No filler sentences; every clause carries actionable 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, the description still conveys the return shape (JSON rows or a list of links). For a 5-param read-only tool with annotations covering safety, this is nearly complete, though the limit default and tabId could be mentioned.

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?

With 60% schema coverage, the description compensates well: it explains the meaning of the undescribed kind enum value "auto" and the ref-vs-selector scoping tradeoff. Only tabId remains undocumented, keeping it below 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?

The description names a specific verb+resource: turning tables/repeated lists into JSON rows, or listing links. It clearly separates structured extraction from generic reading. It does not explicitly name the sibling it is distinct from (e.g., browser_read), so it stops short of 5.

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

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

"Scope it with a ref or selector" tells the agent how to target the extraction, and "Pair with browser_scroll untilStable for infinite feeds" gives a concrete workflow pairing. No explicit when-not-to-use guidance is offered, so it is clear context without exclusions.

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 it does disclose value semantics for checkbox ('true'/'false') and select (option value or visible text) plus the ref provenance. It does not, however, describe failure behavior, focus/event side effects, or what the call returns, leaving gaps for a mutation tool with zero 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?

Front-loaded with the core action, then usage scoping, then value special-cases, then the alternative. Dense and mostly waste-free, though the div/<form> elaboration is slightly verbose relative to the essential routing 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?

No output schema and no annotations, so the description must stand alone; it covers when to use it, how to address the field, and value formatting. It stops short of explaining the result of a successful fill or error conditions, but is largely sufficient for invoking 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 67%, so the schema documents ref and value but leaves tabId bare. The description adds real meaning to value by specifying how to pass checkbox and select values, and clarifies that ref originates from browser_capabilities, going beyond the schema's own text.

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 ('Set a single field to a value') and immediately scopes it by the ref origin. It names browser_invoke as the alternative when a typed tool exists, so an agent can distinguish it from siblings like browser_act or browser_click.

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 when-to-use ('pages Deputy could not graft into a typed tool — apps that build a form out of divs, or inputs sitting outside any <form>') and explicit when-not-to-use ('When a typed tool exists, browser_invoke is better'). Nothing 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.

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

Annotations carry the safety profile (readOnlyHint=true), and the description adds genuine behavioral context beyond that: what the return payload contains (refs with label, state and value) and the search reach into forms, open/closed shadow roots, and off-screen elements. It does not explain hidden-element handling despite an includeHidden parameter, which keeps 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?

Three sentences, each load-bearing: the match strategies first, then the return contract and downstream use, then the non-obvious reach capability. No filler and nothing buried.

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

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

There is no output schema, so the description correctly takes on the return contract (refs, label, state, value) and names the consuming tools. Given 7 parameters and no required fields, a few behaviors (result ordering/limit semantics, hidden elements) are still unaddressed, but nothing an agent needs to invoke it correctly is missing at a blocking level.

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?

With 43% schema coverage across 7 parameters, the description must compensate and partially does: it supplies the entire allowed role vocabulary (which the schema lacks, 0 enums) and clarifies text matching. But exact, limit, tabId, includeHidden and the match/multi-match behavior remain undocumented 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+resource ("Find elements") and immediately enumerates the three matching strategies (visible text, role, CSS selector). The role list and the mention of returned refs distinguish it clearly from siblings like browser_read, browser_look and browser_inspect.

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?

Tells the agent the follow-up path explicitly: the refs returned "you can pass to browser_act, browser_inspect or browser_screenshot," which is real when-to-use guidance. It stops short of naming when NOT to use it (e.g. versus browser_read or browser_look for pure content retrieval), so it is clear context without exclusions.

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 only supply readOnlyHint=true, so the description carries most of the burden and does well: it enumerates the categories of data returned and clarifies the output is numeric rather than an image. It stops short of stating cost, depth limits, or whether the page must be idle/loaded before inspection.

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

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

Two sentences, each mapping to one mode, with the targeting condition front-loaded before the payoff list. The enumerations are dense but every item is a distinct capability that changes what the agent gets back.

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, so the description usefully doubles as a return-value preview by listing the inspected dimensions. Gaps remain around output shape/size for whole-page audits and the role of tabId, but nothing essential for a safe read-only call 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 75%; the description compensates for the two targeting params by establishing that ref and selector are alternative ways to aim the tool, and 'the properties you name' clarifies that the properties array narrows the computed-CSS output rather than being required. The undocumented tabId is left unexplained, and precedence when both ref and selector are supplied is unaddressed.

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 the specific resource (element box model, position, computed CSS, flex/grid layout, contrast, overflow) and splits into two clearly named modes: targeted inspection vs. whole-page layout audit. An agent can distinguish this from browser_screenshot or browser_look purely from the text.

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

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

It explicitly states the condition for each mode ('With a ref or selector' vs. 'With no target'), which is genuine routing guidance. The closing phrase 'Numbers instead of a screenshot, for CSS debugging' implicitly contrasts with browser_screenshot, but no sibling is named outright and no exclusions are given.

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 are empty, so the description carries the full disclosure burden. It usefully warns that this acts in a real logged-in browser and fills/submits actual forms, which is important mutation context. However, it does not cover error behavior, tabId semantics, limits, or the fact that the invoked capability may itself be destructive.

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

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

The description is two short sentences, front-loaded with the core invocation rule and followed by an important real-browser caveat. Every sentence contributes without 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 complex meta-tool with arbitrary nested args, no annotations, no output schema, and no sibling-specific routing guidance, the description is too sparse. It omits when to use this versus direct browser tools, how tabId affects execution, and what the caller should expect in return.

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 67%, and the description mostly repeats what the schema already states: tool names come from browser_capabilities and args match the target inputSchema. It adds no meaningful detail for tabId and little beyond the schema for the nested args object.

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: call one of the tools reported by browser_capabilities, passing arguments that match that tool's inputSchema. It also clarifies that execution happens in the real logged-in browser and submits actual forms. It is clear about the meta-invocation purpose, though it does not explicitly distinguish when this indirect route should be used instead of the many direct browser_* 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?

There is no explicit when-to-use guidance beyond the implied instruction to call a tool listed by browser_capabilities. The description does not say when to prefer browser_invoke over direct siblings such as browser_click or browser_fill, nor does it state prerequisites or exclusions.

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?

readOnlyHint already covers the safety profile, and the description adds genuinely new context beyond annotations: the token cost profile, the fact that a separate vision model does the looking, and the client-compatibility constraint. It stops short of saying how long the call takes or whether it waits for page load, which matters for a remote-vision round trip.

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?

One dense sentence that front-loads the mechanism, then the two usage modes, then the cost and compatibility rationale. Nothing is redundant with the title, and every clause adds 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, the description correctly establishes that the return value is a text answer. For a two-parameter read-only tool that is nearly enough; only the tabId targeting behavior and any blocking/latency expectation are absent.

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 parameters. It does clarify the 'question' parameter's two modes (omitted = describe the page, supplied = answer about what is visible), but 'tabId' is never mentioned, leaving the agent unsure which tab is targeted or what the default is.

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?

A specific verb and mechanism: a vision model inspects the rendered page and returns a text answer, either a description or an answer to a supplied question. The 'text instead of an image' framing implicitly distinguishes it from browser_screenshot and browser_read, but no sibling is named outright, leaving the agent to infer the routing.

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 selecting condition: use it when the client cannot display images, or when a textual answer is enough and you want to spend a few hundred tokens rather than an image. It does not state when-not to use it or name browser_screenshot/browser_inspect as the alternatives, so the routing is implied 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 behavioral burden, and it does disclose two non-obvious traits: the call blocks until the page loads, and it refreshes the capability set so tooling can change underneath the agent. It omits failure behavior (bad URL, timeout, navigating with no open tab), 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?

Two sentences, zero filler, with the primary behavior (navigate and wait) front-loaded and the action-mode and follow-up caveats trailing. Every clause carries 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?

There is no output schema and no annotations, so the description must cover everything, and it is silent on the optional tabId (which tab is targeted, or the default) and on what a failed navigation looks like. Adequate for the happy path, incomplete around ambiguity and errors.

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 67%: url and action are documented inline, tabId is not. The description adds the either/or semantics of url vs action ('Instead of a URL'), matching the schema, but says nothing about the bare tabId parameter. Baseline 3 is appropriate.

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 concrete verb and resource ('point a tab at a URL and wait for it to load') plus the three history modes, which cleanly separates it from siblings like browser_click, browser_read, or browser_tabs. An agent can tell it is the navigation tool 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?

It tells the agent when to use 'action' instead of a URL and mandates a follow-up browser_capabilities call after the page changes, which is clear contextual guidance. It does not state exclusions (e.g. when to prefer browser_tabs for creating/closing tabs, or what to do if navigation fails).

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 only declare readOnlyHint=true, so the description carries meaningful extra weight and delivers: bodies are truncated to the first 4 KB, bodies are only available when they are text/JSON, and capture happens only while an agent drives the tab. These are real behavioral constraints beyond the annotation, though nothing is said about retention, buffer limits, or what 'clear' does.

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 what the tool returns, followed by the two behavior-altering flags. No filler, though the field enumeration and parameter notes make it denser than strictly necessary.

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 compensates by listing the returned fields, which is exactly what an agent needs to interpret results. Remaining gaps are the undocumented 'clear', 'limit' (pagination/cap behavior), and 'tabId' parameters, which leaves it short of fully complete for a 6-parameter tool.

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

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

Schema coverage is 17% (only 'filter' documented), so the description must compensate and it partially does by explaining failedOnly and includeBodies semantics. However, 'clear', 'limit', and 'tabId' remain undocumented in both places, and 'clear' in particular is ambiguous (clear the capture buffer vs. clear the response).

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 the exact resource (network requests the page made) and enumerates the returned fields (method, URL, status, time, type, size), covering fetch/XHR plus all resource types. It is immediately distinguishable from siblings like browser_console or browser_downloads, 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?

Usage is only implied: 'captured while an agent drives the tab' hints the tool is meaningful during an active session, and the failedOnly clause hints at a debug-failures use case. There is no explicit when-to-use versus alternatives such as browser_console or browser_downloads, and no exclusions.

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=true, so safety is covered. The description adds that output is raw plain text for the agent's own reasoning and that the alternative depends on a model key, but says nothing about truncation behavior, page-load state, or what happens on non-text pages.

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, purpose front-loaded, the routing rule following immediately. No filler and every sentence earns its place.

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

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

For a read-only text-extraction tool with annotations carrying the safety profile and no output schema, the description adequately answers what it returns and when to pick it. Only the tabId semantics and load/truncation behavior are left 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 coverage is 50%: maxChars is documented in the schema (default 6000) but tabId is undocumented in both schema and description. The description adds no parameter meaning and does not compensate for the uncovered tabId parameter.

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 (return page as plain text) and explicitly contrasts itself with the sibling browser_ask, so an agent can distinguish the two without opening 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?

Gives explicit when/when-not routing: use browser_ask when you need one fact via a model, use this tool when you genuinely need the content to reason over. The selection 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?

With no annotations at all, the description carries the full burden and does disclose the most important trait: this mutates the user's real window, not a sandboxed view, plus the reset escape hatch. It omits permission requirements, whether other tabs/windows are affected, and whether the change is visible to the user mid-call.

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

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

Two sentences, no waste. The primary behavior and units are front-loaded, and the cleanup instruction is placed second where an agent will read it before finishing.

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 mutation tool with no annotations and no output schema, the description covers the essential behavioral facts (what is changed, in what units, and how to undo it). The unexplained tabId parameter and unstated multi-tab scope are the remaining gaps.

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% (reset only). The description compensates for width/height by specifying CSS pixels and example values, and reinforces reset's purpose, but tabId is documented in neither the schema nor the description, leaving one of four parameters opaque.

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 (set/resize) and resource (page viewport) with the unit (CSS pixels) and a concrete example (375×812 mobile layout). This is unmistakably distinct from siblings like browser_scroll or browser_screenshot 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 clear usage context ('to check a mobile layout') and an explicit follow-up directive ('call with reset: true when done'). It does not name alternative tools or state when not to resize, 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?

Annotations only declare readOnlyHint=true, so the description carries the real behavioral load: it discloses the token cost band (1,000-1,600 tokens) and that fullPage costs more because it stitches off-edge content. That is genuinely useful context beyond the safety hint, though it does not mention image resolution limits or failure modes.

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 what the tool does, then cost, then when-to-use, then alternatives, then parameter behavior. Every sentence adds information; no filler or restatement of 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 6-parameter screenshot tool with an 83% covered schema, readOnly annotations and no output schema, the description covers purpose, cost tradeoffs, sibling routing, and the two parameters with non-obvious behavior. Nothing an agent needs 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 83%, so most parameters are already documented, but the description adds real semantics: fullPage stitches the whole scrollable page including content off the right edge, and ref/selector capture a single element whole even when larger than the viewport. That goes beyond the schema's one-line 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?

States a specific verb and resource ('Take a screenshot and return the image to you') and explicitly distinguishes itself from siblings by naming browser_ask/browser_read for facts and browser_capabilities for actions. An agent can route correctly 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 when-to-use condition ('use it when you need to SEE something: visual or frontend work, layout and styling, charts, images, canvas') and explicit when-not conditions with named alternatives for both the read-facts and action paths. Nothing 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.

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

With no annotations at all, the description carries the full burden and does a reasonable job: it explains what untilStable actually does (keeps scrolling while an infinite feed loads), that it reports growth, and that it locates the real scroll container. That is genuine behavioral context beyond the schema, though it omits return format for the normal scroll case.

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 sentences, front-loaded with the core action and then the two special behaviors. Tight and free of filler, though the second sentence is somewhat dense.

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 an 8-parameter, zero-annotation, no-output-schema tool, the description covers the interesting semantics well but leaves several parameters and the general return value unexplained. Adequate but with clear gaps.

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%. The description adds meaning for a few parameters by explaining 'by' pixels, 'to' top/bottom, and the untilStable behavior, but ref, selector, tabId, direction, and maxRounds get no prose explanation. It partially compensates but leaves half 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?

States a specific verb (scroll) and resource (page or element) with its modes: by pixels or to top/bottom. It is clear what the tool does, though it does not need to distinguish itself from siblings since no other tool in the list scrolls.

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 to use it (untilStable for infinite feeds, real scroll container in app layouts), which gives implicit usage context. However there are no explicit when-not conditions or alternatives named, and nothing tells the agent when scrolling is the wrong move versus using browser_look or browser_extract.

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 are empty, so the description carries the full burden. It does disclose two valuable side effects not present in the schema: "open" makes the new tab active and "select" changes the default target for other tools. However, it says nothing about error behavior, whether tab state survives a close, or what a "list" returns, leaving meaningful gaps for a mutation-capable 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?

One framing sentence followed by four compact clauses, each mapping a mode to its effect. Front-loaded with the resource and zero 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?

There is no output schema or annotation set, and for an action-dispatch tool the description covers the four modes and the active-tab contract adequately. Only the shape of the "list" result and failure modes are unaddressed, which are minor for this tool's complexity.

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 67% and the schema already maps url to "open" and tabId to "select"/"close". The description reinforces the action-to-parameter pairing but adds no format detail (e.g. what a tabId looks like, whether url accepts relative paths), so it does not compensate much for the uncovered portion.

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 the resource (browser tabs) and enumerates each of the four action modes the tool supports, tying each to a concrete effect. An agent can tell immediately what this tool does versus the many single-purpose browser_* siblings such as browser_navigate or browser_click.

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 real operating context: "select" makes a tab active and "other tools act on the active tab by default," which is exactly the routing information an agent needs. It implies but never explicitly states the boundary against browser_navigate (which presumably acts on the current tab), so the when-not guidance is only partial.

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 usefully discloses a size constraint ('25 MB total'), but omits other behaviorally relevant facts: what happens on success/failure, whether upload triggers automatically, and any permission or timing requirements. It adds real value but leaves meaningful gaps 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?

A single sentence that is front-loaded with the core action and constraint, with zero filler. Every clause (paths, size limit, file input, drop zone) earns its place.

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

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

With no annotations and no output schema, the description must do more work. It covers the action and a key constraint but says nothing about outcomes, error handling, or how 'ref' is obtained (only deferred to the schema's mention of browser_find). Adequate but thin for a state-changing browser tool.

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

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

Schema coverage is 50%, so the description should compensate. It adds genuine meaning by requiring 'absolute paths' and the 25 MB total limit, which the schema does not state for the paths parameter. However, 'tabId' remains undocumented in both schema and description, leaving half the parameters under-specified.

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 (Attach) and resource (local files) and clarifies the two target contexts (file input or drop zone). Clear enough to distinguish from read-oriented siblings, though it does not explicitly name the inverse tool (browser_downloads) or other browser_* tools. The core action 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?

The mention of 'file input' and 'drop zone' implies when the tool applies, giving the agent two usage scenarios. However, there is no explicit when-to-use vs when-not guidance and no alternatives are named, so usage remains inferred rather than directed.

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 supplied, so the description carries the full behavioral burden. It does disclose two useful traits the structured fields do not: the no-condition fallback to timeoutMs and that a timeout produces a failure with 'a clear message'. It omits what a successful wait returns, whether a failure is a thrown error vs. a soft result, and whether multiple conditions are combined (AND/OR).

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

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

Two sentences, both load-bearing: the first establishes modes and use context, the second covers the default and the failure mode. The most decision-relevant information (what it waits for) is front-loaded with no filler.

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

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

For a five-parameter, zero-required coordination tool, the description covers purpose, triggers, defaults, and failure behavior. The remaining gap is the return value: with no output schema and no annotations, an agent still doesn't know what a successful wait yields, so the definition is not fully self-contained.

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 80%, so the baseline is 3. The description adds meaning beyond the schema by stating the behavior when no condition parameter is supplied (falls back to timeoutMs), which the schema does not express, and by framing text/textGone/selector as alternative wait modes. It says nothing about tabId, the one undocumented parameter.

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 and resource ('Wait until...') and enumerates the three distinct modes the tool supports: text appears, text disappears, element visible. The scoping clause 'for pages that load content after the fact (search results, spinners, SPAs)' makes it immediately separable from siblings like browser_read, browser_click, or browser_eval.

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 when-to-use context via concrete triggers (search results, spinners, SPAs) rather than a generic statement. It also explains the degenerate case ('With no condition, waits timeoutMs'). It stops short of naming an alternative or an explicit when-not-to-use, so it is strong context without being complete routing guidance.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the agent knows the page, the signed-in session, and form semantics — important auth/context information. But it omits whether the call returns immediately or produces a task to poll, failure behavior, and rate limits, leaving a real gap for a delegation 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?

Two tight sentences, front-loaded with the core action and followed by the differentiating rationale. No filler; every clause earns its place.

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

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

For a delegation tool with no annotations and no output schema, the description covers purpose and preference well but is silent on the return contract (task handle vs. completed result) and how to follow up. Given the presence of task_status and answer_task siblings, this omission leaves the agent's next step ambiguous.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the 'plain language' nature of the goal parameter but adds no syntax, format, or tabId semantics beyond what the schema provides. Baseline 3 is appropriate.

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 (hand the browser agent) and resource (a goal in plain language), and explicitly positions itself against the low-level browser_* siblings by saying 'prefer this over driving the browser yourself.' An agent can distinguish it from browser_click/browser_fill/browser_navigate without opening 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?

Gives a clear when-to-use rule and a when-not ('you never need to see the page'), routing the agent away from the manual browser_* tools. It does not, however, mention the async workflow or point to task_status/answer_task for retrieving the result, which are the obvious follow-ups.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating call. The description adds only that the task may be 'running or interrupted', but says nothing about return shape, polling cadence, or what happens with an unknown/expired id — modest value above the annotation.

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

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

Two short sentences, action first and condition second, with no filler. Every clause earns its place.

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

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

With no output schema, the description carries the burden of explaining what comes back, yet it only hints at status via 'running or interrupted'. An agent still lacks the status vocabulary and the follow-up action (answer_task) once the task finishes.

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 single taskId parameter is undocumented by the schema; the phrase 'by id' only restates that an identifier is required and adds no format, source, or sourcing guidance (e.g. where the id comes from). With just one obvious parameter this is adequate but thin.

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 (poll) and resource (a task by id), and the framing 'delegation' links it to the delegate_goal/answer_task family so it is distinguishable from the browser_* siblings. It is clear, though it stops short of explicitly contrasting itself with answer_task, the other task-oriented sibling.

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 when a delegation is still running or was interrupted' gives an explicit triggering condition rather than leaving usage implied. It names no exclusion or alternative (e.g. use answer_task once the task completes), so it is clear context without full when-not guidance.

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