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

With no annotations, the description carries the full burden and delivers: steps are effect-checked, one snapshot returns at the end, the batch stops early on no-effect/failure/submit-pay-delete controls, selector 'skips ref safety checks', and allowSensitive defaults off and is audit-logged. These are exactly the mutation/safety facts an agent needs and cannot get from 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?

Front-loaded with the default behavior and uses every clause to carry information; nothing is padding. The telegraphic, backtick-dense style packs a lot into a small space, which is efficient but makes the middle ('cond = {...}') harder to parse on first read.

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 12-action batch tool with no output schema and no annotations, the description covers the return behavior (one snapshot at the end), batch limits (20 steps, repeat cap 25), early-stop conditions, block nesting depth, and a safety default with audit implications. An agent can invoke this correctly without further context.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond it: it spells out the shape of read ({ref|find|selector, attr?} or {contains}), the one-level block structure (repeat {steps,until,max}, if {cond,then,else}, assert {cond}), the cond union ({urlContains|selectorExists|textContains, not} OR-ed, or element state), and the ref-vs-find rule tied to re-render scope.

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+resource: batch browser steps in one call, with the snapshot returned at the end. It implicitly distinguishes itself from the single-action siblings (click, type, select, fill, key) by claiming to be the 'DEFAULT way to act' and by warning that batching saves a model turn. The name 'act' itself is vague, but the description resolves it well within the first 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?

Explicit when-to-use ('batch every step you can predict', default on form wizards), when blocks apply (repeat for pagination/load-more, if for optional banners, assert for page-match), and a crisp ref/find routing rule: inside repeat use find/selector never ref, elsewhere ref until re-render then find. Alternatives and exclusions are named rather than 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, the description carries the burden well: it discloses the side effects (tab focus, panel, target highlighting, desktop notification) and that the call blocks until the user acts. It also explains the semantic of a 'cancelled' result. It stops short of describing what happens when the timeout expires or how the user's answer is returned.

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?

Five tight sentences, front-loaded with the core behavior, then trigger conditions, then the cancellation contract. No filler, and the most decision-relevant rule (stop on 'cancelled') is last for emphasis without burying the purpose.

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 blocking tool with a nested object and no output schema, the description covers purpose, triggers, side effects, and result semantics adequately. The remaining gap is timeout-expiry behavior and how the user's response surfaces to the agent.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters thoroughly, including the nested 'until' object and target refs. The description adds only light reinforcement ('highlights your targets'), which is the baseline expectation when the schema does the heavy lifting.

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 action (hand control to the user for one step, then resume) with a unique verb-resource pairing that no sibling tool shares. An agent can immediately tell this is the human-in-the-loop pause tool and not a retry/wait/act mechanism.

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 triggers are enumerated (captcha, QR login, SMS/OTP, human confirmation) plus a positive routing rule: 'Use it instead of retrying a step that needs a human.' It also defines the terminal case ('cancelled' means the user said no: stop the task, do not look for another way), which is when-not guidance no sibling provides.

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 bears the full behavioral burden. It usefully discloses that x,y triggers a 'real' browser-level click and that dragTo performs a drag, but it does not state whether clicking waits for stability, whether it can navigate or submit, or what happens on failure. This is partial disclosure 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?

Three tight sentences with no waste. The core purpose is front-loaded, the alternative follows immediately, and the coordinate/drag fallback is efficiently packed into the final sentence.

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 11-parameter, nested-object tool with no output schema, the description covers the core purpose, names the main alternative, and addresses the special canvas/map/game case. It could say more about side effects and failure modes given the absence of annotations, but the structured schema carries most parameter detail.

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 high (82%), so the baseline is 3. The description adds useful meaning beyond the schema: x,y are CSS pixels from a screenshot, dragTo performs press-move-release, and ref comes from the latest snapshot. It leaves detailed semantics for find, expect, real, tabId, and spaceId to the schema, which 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 and resource ('Click ONE element by ref') and explicitly distinguishes itself from the sibling `act`. It also carves out the canvas/map/game case with x,y coordinates, so an agent can tell what this tool is for 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?

Names the alternative `act` and gives the condition for using it ('Know your next step already?'). It also specifies when to pass x,y instead of ref. Both the primary and fallback usage paths are explicit.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: that it is a fallback path, that Chrome settings/policy may trigger a save dialog, and that permission should be obtained before background use. It stops short of stating auth requirements, rate limits, or the return value, 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 of reasonable length, but the broken punctuation ('via:"page"', stray quotes) reads as garbled and hurts front-loading. The fallback rationale leads, which is good, but execution is sloppy.

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 4-param download tool with no output schema, the description covers the primary use context and a key risk (save dialog). It omits what success/failure returns, the timeout default behavior, and how savePath relocation interacts with the fallback, leaving gaps an agent would need.

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% and the schema already documents spaceId, timeout, and savePath. The description adds no syntax or format detail for these, and its 'via page' reference does not correspond to any declared parameter, which is more noise than signal. 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+resource (download a URL) and distinguishes itself from the fetch sibling by naming the exact condition (fallback when fetch with binary:true and savePath fails). The mangled 'Try via:"page"' fragment introduces a mode that doesn't map to any schema parameter, adding minor confusion to an otherwise clear purpose.

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 frames this as a fallback and names the alternative (fetch with binary:true/savePath). It also gives the 'page' condition for sites needing credentials/Referer and instructs obtaining permission before background use. No explicit when-not-to-use beyond the fetch comparison, so not quite 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 provided, the description carries the full burden, and it does disclose two real behavioral traits: likely failure on CSP-restricted sites and isolated-world execution scope. It does not mention that the expression can mutate page/global state or how the return value is surfaced, which matters for an arbitrary-code-execution 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?

Three tight sentences with zero filler; the core action is front-loaded and the caveats are ordered by severity (hard failure first, preference second, scoping third).

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 no-annotation, no-output-schema tool with a required expression parameter, the description covers failure modes and execution context well. It stops short of explaining what the agent gets back from the expression (serialization, return type), which is the one thing an agent cannot infer from structured fields here.

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?

Three parameters at 67% schema description coverage: tabId and spaceId are documented in the schema, but `expr` (the required one) has no description in either place. The description adds no parameter-level meaning, so the baseline 3 for middling coverage 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?

Names a specific verb and resource ('Run a JS expression in the page') and immediately distinguishes itself from the sibling `query` tool by naming the data-extraction case it does not serve. The isolated-world note further separates it from any tool that would reach page-level JS state.

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-not conditions (strict CSP sites, page's own JS variables) and a named alternative ('Prefer `query` for data extraction'). What's missing is a positive statement of when eval is the right choice rather than query or `act`.

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 zero annotations, the description carries the full burden and does so: it discloses credential/cookie forwarding, same-origin constraints, that 403/406 indicates server-side request signing, an explicit prohibition against forging requests, and that servers silently cap page size. This is exactly the behavioral context an annotation-free tool needs.

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 core action and credential model, then layers the usage rule, the pagination rule, the error-handling rule in descending priority. Every sentence changes agent behavior; none 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?

For a 9-parameter tool with nested objects and no output schema, the description covers the response surface (the paging object), failure modes, and cross-origin behavior. An agent has enough to invoke this correctly on the first attempt.

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 78% and the descriptions there are strong, but the tool description still adds intent-level meaning: it tells the agent to pass `pages` and to always inspect the response's paging object, which explains why pages exists rather than just how it is shaped. It does not add detail for via, init, spaceId, or tabId beyond the schema.

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

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

States a specific verb and resource ('Call a URL from inside the page, carrying the user's cookies') and immediately positions itself relative to siblings by naming `network` as the discovery step that precedes it. An agent can tell this apart from navigate/network/eval 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 ('after `network` reveals an API'), an explicit anti-pattern ('never loop fetch by hand, each loop turn costs a model round'), and a named alternative path for the blocked case ('drive the site's own pagination UI and read via `network`'). 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, the description carries the full burden. It usefully discloses that submit runs only after success ('skipped if any field failed'), but says nothing about partial-failure behavior for fields, permissions/auth needs, or what the call returns on error.

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 batch promise and followed immediately by the field-shape cheat sheet. Nothing is padded or redundant.

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 carry the load; it covers the field shapes and submit behavior well, but leaves return values and error/partial-failure outcomes unspecified.

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 description adds genuine meaning by mapping field shapes ('{ref, text} for inputs, {ref, value} for <select>, {ref, check} for checkbox/radio') that the schema's item properties do not explain. It also clarifies the skip-on-failure semantics of submit.

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 ('Fill a whole form') and the key differentiator 'in ONE call', which separates it from the single-field siblings type/select. It never names those siblings explicitly, so the differentiation is implied 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?

The 'all refs from the same snapshot' constraint hints at when this batching is valid, but there is no explicit when-to-use guidance versus type/select/click, and no stated preconditions such as needing a prior snapshot.

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 disclosure burden. It adds the focus-targeting rule and a useful tip about arrows driving custom dropdowns, but says nothing about return values, whether the press waits for effects, or how failures/no-op keys are reported.

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, front-loaded with the action and key set, then the focus rule and the cross-reference. No filler or redundancy.

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

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

For a 7-parameter, no-annotation, no-output-schema tool, the schema is thorough and the description covers the common case. However, it omits outcome/error behavior and any indication of what a call returns, leaving an agent to guess about failure handling.

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

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

Schema description coverage is 100%, and every parameter (key, ref, real, tabId, repeat, spaceId, snapshotId) is documented in the schema itself. The description restates the key values and focus behavior already covered there, so it adds no syntax or format detail beyond the structured fields.

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 ('Press a key') and enumerates the supported key classes: Escape/Enter/Tab/arrows, Backspace/Delete, and modifier combos. It closes by naming the sibling it is not ('For entering text use type'), so an agent can separate it from `type` 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 clear routing context: 'Without ref it goes to whatever is focused' and 'For entering text use type.' That is an explicit alternative for one case, but it doesn't cover other plausible confusions (click vs key, select vs arrow keys, or when to prefer key sequences over repeated calls).

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 exist, so the description carries the full burden. It discloses useful behavior — 'no args = list sites', notes may embed runnable act scripts, save replaces the local note, and the hedged trust level 'Hints, never rules'. It does not cover whether notes are shared/synced across sessions, permission needs, or what list output looks like.

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?

Tight single paragraph with no filler, front-loading the resource then the read/write protocol. Phrasing like 'fill {{placeholders}}' and 'via {domain, save}' is terse to the point of being slightly cryptic, but every sentence 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?

For a dual-mode (read/write) tool with three optional params and no output schema, the description covers the core read and save flows well. It omits the spaceId parameter and any indication of what a list-sites or note-fetch response contains, leaving a modest gap.

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

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

Schema coverage is already 100%, so 3 is the baseline, but the description adds semantics beyond the schema: calling with no arguments lists sites, and the save param must be merged with a prior get rather than blindly overwritten. The spaceId param is not addressed in the description.

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

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

The description states a specific resource — persistent site notes (APIs, walls, pitfalls) — and distinguishes its read mode (call with domain, no args lists sites) from its write mode (save). It is clear what the tool is for, though it never names itself as the memory/notes sibling versus the other browser tools 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?

Gives clear when-to-use context: call before first acting on a site, run embedded ```act scripts instead of rediscovering, and save a note back after learning something non-obvious. No explicit exclusions or named alternatives, but the trigger conditions are concrete.

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 the authentication context (logged-in Chrome) and the return shape (new page snapshot), but says nothing about permissions, side effects, or what happens to the prior page state.

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

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

Two compact sentences with the action list and return value front-loaded, plus the environment note. Every clause earns its place and there is no filler.

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

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

No output schema exists, and the description compensates by stating that the new page snapshot is returned. For a simple navigation tool this is nearly complete; only permission/limit details 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 description coverage is 75%, so most parameters are already documented. The description implies url and action semantics but adds nothing beyond the schema, and neither tabId nor spaceId is clarified further.

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?

Specific verb (go to a URL / back / forward / reload) and resource (page), and it explicitly names its domain by pointing to the user's own logged-in Chrome. It doesn't distinguish itself from siblings like fetch or reload, but the scope 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?

"Runs in the user's own logged-in Chrome — prefer it over any other browser tool" tells the agent when this tool is the right choice versus other browser access paths. It gives no explicit when-not or prerequisite conditions, so it falls short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does reasonably well: it discloses that only requests the page already made are listed, that a reload is needed to capture load-time requests, that results are matched by URL fragment, and that paging is done via a parameter. It omits permission/auth requirements and whether captured bodies persist across navigations, which a mutation-free data tool arguably should note.

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?

It is front-loaded with the decisive instruction ("START HERE...") and every sentence except the final heuristic ("One page's API messy? Another page on the same site...") carries actionable guidance. It runs slightly long and is written in a conversational register, but there is little dead weight.

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

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

For a 7-parameter, annotation-free tool with no output schema, the description covers purpose, workflow ordering, capture timing, and paging well enough to invoke correctly. The remaining gap is the absence of any detail on permissions, failure modes, or the shape of the returned list beyond 'the XHR/fetch calls the page made'.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including body, index, match, reload and maxBody. The description's mentions of body/"<url fragment>" and "paging as a parameter" largely restate what the schema says, adding only mild emphasis rather than new semantics, so the baseline 3 applies.

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

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

The description states a specific verb and resource: it 'Lists the XHR/fetch calls the page made' and can return 'one response body' via a URL fragment. The opening "START HERE when you need DATA rather than an action" cleanly separates it from the action-oriented siblings (click, type, navigate), so an agent can classify it 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 gives real when-to-use guidance ("when you need DATA rather than an action", "Add reload:true if nothing was captured yet") and a workflow rule ("Never guess an endpoint name from memory — list first"). It stops short of naming a concrete alternative tool for the case where this tool isn't right, so it is clear context rather than full when-not 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?

No annotations are provided, so the description carries the full burden. It discloses that `contains` is case-insensitive and that a selector merely scopes that text search, and it documents the html-mode return (outerHTML), but it never states side effects, permissions, or that this is a non-mutating read — the safety profile an agent needs before invoking 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?

Two sentences, front-loaded with the core extraction capability before the text-find mode and the list workflow. It is information-dense to the point of being run-on with stacked backticked fragments, but almost 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?

No output schema exists and there are 7 parameters with nested objects, so the description should carry more return-shape detail. It does describe the `contains` return (matching visible elements with selector path and ref), but says nothing about what `extract` or plain-text mode return, and never mentions tabId/spaceId targeting.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters including `extract`'s field→sub-selector shape and '@attr' syntax. The description's example ({title:".name", link:"a@href"}) largely restates that, adding marginal value, so baseline 3 is right.

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 concrete verb+resource: extract structured data from the page by CSS selector, or find elements by text via `contains`. It explicitly contrasts itself with a named sibling ('use it instead of eval'), so an agent can separate it from eval, read_text, and snapshot 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?

It gives concrete use cases (check 'is X on the page', read a status label, find a dropdown option) and names the alternative to avoid (eval), plus an operational workflow for lists (pass `html:true` first to inspect markup, then `extract`). It lacks explicit when-not-to-use guidance relative to read_text/snapshot, 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?

No annotations are provided, so the description carries the full burden. It does disclose output form (markdown) and a processing trait (boilerplate stripped), but says nothing about read-only safety profile, whether the tab must already be loaded/awaited, or any size/truncation behavior on long 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?

Two short sentences with zero filler; the purpose is front-loaded and the routing hint follows immediately. 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 read-only extraction tool with no output schema, the description covers what it returns (markdown, boilerplate removed) and when to prefer the sibling. Minor gaps remain on long-page/truncation behavior and the empty-parameter default, but nothing blocks a correct call.

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%; tabId and spaceId are documented in-schema, while the format enum ('markdown'/'text') has no schema description. The description supplies the implicit default output ('as markdown') for format, adding modest value but not fully compensating for the bare enum.

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 ('Extract the main readable content of the page as markdown') with a clear scope modifier ('boilerplate stripped'). It explicitly distinguishes itself from the snapshot sibling, so an agent can route 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 both a when-to-use condition ('Use for reading articles/docs') and a named alternative with its selecting condition ('use snapshot when you need to interact'). This is exactly the explicit when/alternative routing guidance the rubric rewards.

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 and does so: it flags the call as DISRUPTIVE, explains the blast radius (shared by every tab and every other agent session; mid-flight work elsewhere gets cut), and gives recovery/timing facts (~2s, bridge auto-reconnects, tabs keep state). That is exactly the behavioral context an agent cannot get from the schema or the empty annotation set.

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 and mechanism, then timing, then the disruption warning, then the call condition — a sensible information order with no filler. It is dense and em-dash-packed but nearly every clause carries distinct information, so it is efficient rather than padded.

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

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

For a one-parameter mutation-ish maintenance tool with no annotations and no output schema, the description covers what it does, side effects, latency, recovery behavior, and the precondition for calling it. Nothing an agent needs to decide whether to invoke it is missing.

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

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

The single parameter spaceId is fully documented in the schema (100% coverage), including the requirement to also pass its tabId, so the baseline is 3. The description adds no further detail about spaceId and does not need to.

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 ('Reload the beat-browser extension') and even names the underlying mechanism (chrome.runtime.reload()), which immediately disambiguates it from page-level tools like navigate or scroll in the sibling list. An agent can tell this reloads the extension itself, not a tab or document.

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 ('only right after installing/updating, or when doctor/a version-mismatch warning says to') and an explicit when-not ('never speculatively'). The trigger conditions are named concretely rather than implied.

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

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

With no annotations, the description carries the load well: it discloses the default output format (60% scale JPEG), the override (full:true gives 1:1 PNG), that background tabs are included, and that focus interrupts the user. Only the inline-vs-savePath return behavior 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?

Two tightly packed sentences, front-loaded with what the tool does, then the cheaper alternative, then the output-format tradeoff. Every clause is actionable and none is redundant.

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

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

For a 7-parameter tool with no output schema, the description covers the critical decisions (cost vs. fidelity, whether to interrupt the user). Parameter-level detail is fully covered by the schema, so the only marginal gap is return-value behavior, which the schema's savePath field partly implies.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds rationale the schema lacks: why full is useful (read small text, measure pixels) and the cost implication of the default scaled JPEG, which helps the agent pick a value rather than just know its type.

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 ('Screenshot the controlled tab') and immediately scopes it ('background tabs included'), which distinguishes it from sibling tools like snapshot and read_text that also produce page representations.

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 steers the agent away from this tool toward snapshot/read_text on cost grounds, and gives a positive trigger for full:true (reading small text, measuring pixels). It stops short of stating the general condition under which a screenshot is the right choice, but the alternatives and one use case are named.

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

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

With no annotations, the description carries the full burden and does well: it discloses auto-detection of scroll containers, self-terminating behavior when height stops growing, and a subtle environmental failure mode (background tabs render no frames, IntersectionObserver lists may refuse to grow, and the tool reports this). It does not mention auth/permission needs or the return/diagnostic shape beyond implying it signals the stale-tab 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?

Four compact sentences, front-loaded with the core action, then behavior, then alternative, then the caveat. Nothing is redundant and every sentence adds decision-relevant 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 annotations and no output schema, so the description must supply behavioral context; it covers behavior, limits, and a known failure mode well. It does not describe what the tool returns on success (e.g., how much was loaded, whether a diagnostic is returned), which is the main remaining gap for a 7-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 description coverage is 86%, so the schema already documents nearly all 7 parameters (ref, wait, times, tabId, etc.). The description adds no parameter-level detail such as units, interactions between 'times' and 'wait', or how 'to' behaves with a specific 'ref', so it stays at the baseline for high-coverage schemas.

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 target ('Scroll to load more of a lazy list') and immediately scopes the behavior ('Auto-detects inner scroll containers, stops early once height stops growing'). An agent can distinguish this from sibling tools like fetch/network 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?

Explicitly routes the agent to an alternative ('Prefer network/fetch for bulk data') with the condition that selects it. It also names the scenario where the tool should be used (lazy lists) and a known failure context (background tabs with IntersectionObserver). No explicit 'when-not' for other interaction siblings, but the routing guidance is strong.

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

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

With no annotations, the description carries the full behavioral burden. It adds useful semantics (value matches the option value or its visible label) and the custom-dropdown caveat, but omits failure behavior, whether change events fire, and what a successful call returns. Moderate coverage 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?

Two tight sentences, front-loaded with the primary action, then the value-matching rule, then the exclusion. No wasted words.

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

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

For a 7-param tool with nested objects and no output schema, the description covers the core action and the key value-matching behavior; the remaining params (find, expect, tabId, spaceId, snapshotId) are documented in the schema. A brief note on failure/return behavior would complete it.

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 high (86%), so the baseline is 3, but the description adds meaning beyond the schema by clarifying that `value` matches either the option's value or its visible label and that `ref` is the primary locator. That is genuine added semantics over the bare string type.

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

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

The description states a specific verb (Choose) and resource (an option in a <select>) and scopes it 'by ref'. It implicitly distinguishes itself from siblings like click/fill/type by explaining that custom dropdowns are handled differently.

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

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

It gives an explicit when-not rule (custom dropdowns such as react-select, MUI, Element UI are NOT <select>) and routes the agent to the alternative workflow: click to expand, read options from snapshot, click one. 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, the description carries the full burden and does well: it discloses the return shape (refs plus value/checked/selected/expanded/disabled state), the iframe ref-routing rule (@fN refs pass through unchanged), and a cost signal ('Cheap'). It omits any note on output size limits or how stale a snapshot becomes, which is the only gap.

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

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

Three dense sentences, each earning its place: what it returns, when to call it, and the iframe ref caveat. The most decision-relevant guidance (call before click/type) is front-loaded.

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

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

For a zero-required-param read tool with no output schema, the description adequately covers return content, usage, and the iframe edge case. Only minor omissions remain (no mention of snapshot staleness or size 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 description coverage is 100%, so tabId and spaceId are already documented in the schema. The description adds nothing about parameter usage, so the baseline 3 applies.

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

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

States a specific verb ('Capture') and resource ('the current page as a compact list of interactive elements with refs and state'), and enumerates the returned content (dialogs, alerts, text excerpt). This clearly distinguishes it from siblings like screenshot, read_text, and 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 an explicit trigger ('Call this before any click/type') and names the alternatives it should beat ('prefer it over screenshots or eval'). The agent knows both when to use it and what to use instead.

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 does so richly: user focus pauses control, handoff alone brings the window forward, finish releases control while keeping evidence tabs, recovered tasks remain paused, and claim with userConfirmed:true can connect a new agent only after explicit user instruction. These lifecycle safety and control behaviors are exactly what an agent needs to avoid misuse. The only gap is minor, such as no error or permission model, but the disclosure is strong overall.

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 a single dense paragraph but is front-loaded with the core concept and contains little filler; most sentences convey a distinct lifecycle rule. It could be more scannable with action-oriented grouping, yet given the complexity of a 17-action tool it remains appropriately sized and earns most of its words.

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

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

For a complex multi-action tool with 15 parameters and no output schema, the description covers the critical lifecycle and routing behavior well, including reconnect recovery and paused-task handling. It does not explain all enum actions or return expectations, but it provides enough context for an agent to call the tool safely in common scenarios. The missing action-level detail keeps 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 description coverage is moderate at 67%, so the schema already documents many parameters. The description adds meaning for tabId usage, userConfirmed claim behavior, and some action routing, but it does not explain many parameters such as leaseMs, after, label, notifications, reportIntervalMs, or spaceId. It adds partial value over the schema but does not fully compensate for the remaining coverage gaps.

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 the resource clearly as a 'BeatBrowser-owned background task window' and explains core actions like open, handoff, resume, finish, and claim. It distinguishes the tool from sibling browser actions by framing it as a space/task-window controller rather than a page interaction tool. However, it does not explicitly define the tool as a unified space-management command surface, leaving some inference to the agent.

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

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

The description gives clear operational context: open creates a minimized Chrome window, pass tabId on browser calls, handoff brings the window forward, resume requires explicit user instruction, and list spaces restores routing after reconnect. These are useful when-to-use signals for several actions. It does not name alternatives or exclusions, so it falls short of the top score.

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 useful traits: it is user-visible ('shown on an on-page panel') and non-blocking ('Instant, never blocks'). It does not say whether successive calls replace or queue the previous status, whether it returns anything, or any rate/usage limits.

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 short sentences, front-loaded with what the tool is before the timing and behavior guidance. Every sentence carries distinct information; 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 two-parameter, no-output-schema UI tool, the description covers purpose, when to call, latency profile, and content of the argument. The remaining gap is undefined repeat-call behavior (replace vs. append), which matters for an on-page panel that a multi-step task will write to repeatedly.

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

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

Schema coverage is 100% so the baseline is 3, and the description adds real semantics on top: 'One short sentence' constrains the content of the required text parameter, and 'Use the user's language' is a localization instruction absent from the schema. The spaceId/tabId pairing is left to the schema.

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

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

States a concrete purpose: emitting one short sentence shown on an on-page panel to tell the user what the agent is about to do. It is a progress-narration tool, clearly not a browser action, which implicitly separates it from siblings like click/navigate. It does not name a sibling or explicitly contrast with e.g. 'ask', so it falls short of a 5.

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

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

Gives explicit call timing: 'Call before a multi-step task and whenever the plan changes.' That is a clear when-to-use rule. It stops short of stating when NOT to call (e.g. for trivial single-step work or after a task completes), and names no alternative 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?

With no annotations, the description carries the full burden and does so well: new tabs open in the BACKGROUND, background tabs support everything except screenshot, each session owns its controlled tab, and cross-session selection warns rather than blocks. It does not describe what action:"list" returns (ids, labels, structure) or any concurrency limits, which are meaningful gaps for a close-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?

The most consequential facts (background opening, per-session controlled tab) are front-loaded, and each subsequent sentence addresses a distinct operational hazard. It is dense with clauses but nearly every one earns its place; the 'label each tab' sentence could be tightened.

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 four-action, six-parameter tool with no annotations and no output schema, the description covers the destructive (close), mutating (new/select), and read (list) paths, plus the multi-agent concurrency story and the hint to recover the tab mapping via action:"list". 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 67%, and the description fills the important gaps: it explains the omission semantics of tabId, that label is surfaced in list/page panel/to the user, that focus forces the tab forward and interrupts the user, and that spaceId pins the command to an owned TaskSpace. url and the action enum values are left entirely to the schema.

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

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

The opening sentence gives specific verbs (list/open/switch/close) against one resource (tabs), so an agent immediately knows the tool's domain. It also implicitly differentiates from the screenshot sibling by noting screenshot is the one action that doesn't work on a background tab. It stops short of explicitly distinguishing itself from navigate, which handles URL changes.

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 states the selection rule for tabId precisely: omit it to use the session's controlled tab, but pass it explicitly on EVERY call when 2+ work-lines exist because the implicit slot is shared with subagents. It also explains when focus is warranted (it interrupts the user, off by default) and what happens when selecting another session's tab (warns, does not block). These are the exact decision points 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?

No annotations are provided, so the description carries the full burden. It discloses the single-element scope and that submit:true presses Enter, but says nothing about permissions, reversibility, settle/retry behavior, or side effects of typing. Adequate but thin for an un-annotated 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?

Three short sentences, each earning its place: the action, the submit modifier, and the alternative routing. Front-loaded and waste-free.

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?

Given 11 parameters but a 91%-covered schema and no output schema, the description needn't explain params or return values. It covers purpose and routing well; the only gap is behavioral context (settle window, error behavior) for a tool with no annotations, which keeps it short of 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 description coverage is 91%, so the schema already documents ref, find, clear, expect, submit, real, selector, tabId, spaceId and snapshotId. The description only restates the submit behavior, adding no syntax or format meaning beyond the structured fields; baseline 3 applies.

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

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

States a specific verb (type) and resource (input/textarea/contenteditable), plus a hard scope constraint (ONE element, by ref). It explicitly distinguishes itself from siblings fill and act, so an agent can route correctly 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?

Gives explicit routing: 'More fields coming? Use `fill` or `act`', which names the alternatives and the condition selecting them. It is clear when to reach for a sibling, though it offers no explicit when-not guidance for a single field beyond the word 'ONE'.

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, and it does disclose real behavioral traits: it cannot reach the OS file picker, it auto-detects inputs, and it states size limits (unlimited via file input, 48MB cap for drag-drop). Missing anything on permissions or return/confirmation behavior, but the constraints given are genuinely useful.

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 prerequisites, parameter routing, and constraints in four dense sentences with no filler. Every sentence contributes; slightly telegraphic phrasing but appropriately sized for a 5-param 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 annotations and no output schema, the description must stand alone, and it covers the key operational behaviors an agent needs (UI prerequisite, input auto-detection, drag-drop fallback, size limits). Return/confirmation behavior is unaddressed, but the essential calling information is 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 coverage is 100%, so the schema already documents all five parameters (baseline 3). The description nonetheless adds meaning beyond the schema by clarifying the selector-vs-dropSelector trade-off and the size consequence of each path, plus the auto-detect behavior for selector.

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 ('Attach a local file to the page'), which cleanly distinguishes it from the download sibling and the rest of the browser-control toolset. An agent immediately knows this is the file-upload action.

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 prerequisite ('Open the upload UI first') and explicit routing guidance: default auto-picks a matching file input, while 'editors that only accept drag-and-drop (X Article, Notion) pass dropSelector instead.' Names concrete contexts for the alternative parameter, though it stops short of naming a sibling tool or an explicit when-not-to-use.

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 must carry the full behavioral burden, and it largely does not. It never says whether the call blocks, what happens when the timeout elapses (error vs. silent return), or whether a failed wait has side effects on the page — critical questions for a synchronization primitive.

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, with the capability statement front-loaded and the timing advice second. Nothing is redundant with the title or restates the 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?

For a 5-parameter, annotation-free tool with no output schema, the description covers the what and the when but not the after. It omits return semantics and timeout failure behavior, so an agent cannot predict what a completed or timed-out wait yields.

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 80%, so the properties are mostly self-documenting and baseline 3 applies. The description does add useful semantics by pairing each wait mode with its meaning (selector vs. text vs. idle), but it says nothing about tabId or spaceId, the parameters most likely to be misused.

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

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

The description states a specific verb (wait) and enumerates the three conditions it can wait on — selector appears, text shows up, network idle — which map cleanly onto the 'for' enum. It does not, however, contrast itself with siblings like snapshot, read_text, or network, which an agent might consider instead for similar observation tasks.

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 after actions that load content' gives a clear, actionable timing cue that tells the agent when this tool belongs in a sequence. It stops short of stating exclusions or naming alternatives (e.g., when not to wait, or what to use instead when content is already present).

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