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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and "Go back" discloses nothing: no mention of history exhaustion, whether it waits for load, or whether the page state is preserved. For an action tool with zero annotation coverage this is a serious gap.

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

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

Two words is not conciseness but under-specification; there is no front-loaded statement of effect, scope, or preconditions to compress. Nothing here earns its place because there is essentially nothing here.

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 six parameters, a required slot, no annotations, and no output schema, an agent needs at least the effect and failure mode of a history-back action. The description supplies neither, leaving it incomplete for even a simple navigation 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 six parameters (slot, tab, read, agent, summary, multiSlot) are already fully documented in the schema; the description adds nothing but is not required to. 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?

"Go back" states a navigational verb but never names the resource; the agent must infer from the tool name browser_back that this steps back through page history rather than, say, going back a form step or a tab. It is distinguishable from browser_forward by common sense, but the description itself contributes almost nothing beyond the name.

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 guidance on when to use this versus browser_navigate, browser_forward, browser_reload, or browser_tab_select, nor any note about behavior when no history exists. The agent must guess entirely from the name.

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: it states that matching requests fail, that the tab skips its cache while rules exist, that rules live only for the session, that they surface in the header to other agents, and that there is no-arg readback. These are exactly the behavioral traits an agent cannot infer from structured fields.

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

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

Front-loaded with the core action and consequence, then compresses a lot of pattern/lifecycle detail into relatively few sentences. Slightly dense and a couple of clauses ('add adds, remove removes') echo the schema, 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 an 8-param, no-output-schema, no-annotation tool, the description covers lifecycle, cache behavior, cross-agent visibility, pattern semantics, and no-arg readback. Slot/tab/agent/multiSlot semantics are left entirely to the schema, which is acceptable at 100% coverage but keeps it short of complete.

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

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

Schema coverage is 100% (baseline 3), but the description adds real meaning for the pattern values used by add/remove: wildcard syntax (* and ?), bare-domain expansion, and automatic trailing-wildcard append for query strings. This is genuine semantics beyond the schema descriptions of 'URL patterns to block'.

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 + resource ('Blocks tab network requests matching URL patterns') plus the observable effect ('they fail'), which distinguishes it from the sibling browser_network inspection tools. An agent can tell what this does and what changes in the browser 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?

The description explains each action mode (add/remove/clear) and the default behavior ('With no args, shows current rules'), giving clear context for how to invoke it. It stops short of naming alternatives or when-not-to-use (e.g. browser_network vs blocking), so it is not a full 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 meets it: it discloses occlusion handling (no click, reports the covering element), navigation wait behavior, new-tab reporting, and OS file-picker interception semantics. These are non-obvious runtime traits that go well beyond a generic 'click' contract.

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 short sentences, each adding a distinct operational fact, with the core action front-loaded ahead of the edge cases. There is no filler, restatement of the title, or redundant phrasing.

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

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

No output schema exists, and the description compensates by describing what the click returns/reports (occlusion report, navigation completion, new tab). Combined with a fully documented parameter schema, an agent has everything needed to invoke and interpret this 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. The description only indirectly touches the ref parameter ('ref element') and says nothing about double, tab, read, slot, or agent semantics beyond what the schema already documents.

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 — clicking a ref-addressed element with real mouse events — and immediately scopes it against sibling actions (browser_upload, browser_select). An agent can distinguish it from browser_type, browser_fill, and browser_hover 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 explicit when-not rules with named alternatives: file inputs and 'attach' buttons route to browser_upload, and <select> dropdowns route to browser_select. The conditions that select those alternatives are spelled out, which is exactly what an agent needs to route correctly.

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 delivers: it discloses that session and cookies are saved, that the profile/logins are kept, and that the result reports recent use by another agent. It omits error behavior (e.g., closing an already-closed or unknown slot), but the state-preservation semantics are unusually well covered.

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

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

Three short sentences, front-loaded with the action and immediately followed by the state-preservation facts. 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-param close tool with full schema coverage and no output schema, the description covers the essential behavioral facts (what is preserved, side-effect reporting). Only the error/edge-case path for an inactive slot is missing, which is a minor 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 100%, including the parsing hint for slot values and the agent display name, so the schema does the heavy lifting. The description adds no parameter detail beyond the slot concept, making 3 the correct baseline.

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: 'Closes slot Chrome cleanly.' The scope (whole slot, not a tab) is implied by 'slot' versus the sibling browser_tab_close, though the differentiation is left for the agent to infer 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?

No explicit when-to-use guidance. It never states when to close the slot versus using browser_tab_close, or what conditions precede closing. The implication is that this tears down the slot, but nothing routes the agent explicitly.

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 largely succeeds: it discloses that the tab is frozen while a dialog is open, that beforeunload accept loses input, and that prompt text is only used when accepting. It does not say what happens if no dialog is open (error vs no-op) or whether the call surfaces the dialog message back, which are the remaining behavioral gaps.

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 action and its default policy are front-loaded in the first two sentences, and the beforeunload/prompt edge cases follow. It is dense and uses nested parentheses, but every sentence carries actionable content 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the behaviorally risky parts (frozen tab, irreversible confirmation escalation, beforeunload tradeoff) while the schema fully documents plumbing parameters like tab, slot, agent, and read. Only the no-dialog-open failure mode is left 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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: accept:true/false is tied to OK/cancel semantics and to leave-page-vs-stay for beforeunload, and text is scoped to prompt dialogs when accepting. That is real semantic enrichment on top of the schema's shorter 'true = OK, false = cancel'.

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

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

States a specific verb pair (accepts/dismisses) and resource (an open dialog), and enumerates the dialog types it handles (alert/confirm/prompt/beforeunload). No sibling tool touches dialogs, so an agent can uniquely identify this one from name plus description alone.

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 decision rules: judge from content and handle it yourself by default, ask the user only when the dialog confirms an irreversible action the user didn't request (payment, deletion). It also maps accept/dismiss to concrete outcomes for beforeunload, which is exactly the when-to-choose guidance 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 disclosure burden. It usefully notes the return location ('user's Chrome download folder') and that it returns early, but it omits what happens on timeout, if no download is in progress, or whether it blocks other slots – meaningful gaps for a blocking wait 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, front-loaded with the core behavior. 'Returns as soon as it finishes' partially restates the waiting behavior but does clarify it is not a fixed-duration wait, so it 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 correctly explains the return value (saved file path in the Chrome download folder). It is complete on inputs and outputs but leaves the timeout/failure outcome 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 description coverage is 100%, so the schema already documents slot, agent, and timeout with examples and ranges. The description adds nothing about any parameter, 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 ('Waits') and resource ('the most recently started download') plus the return ('saved file path'). It does not name the relevant sibling browser_wait, so an agent must infer the distinction from context, but the scope ('most recently started download', Chrome download folder) is clear.

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?

'Call after clicking the download button' gives explicit timing, which is the key usage condition. It stops short of naming an alternative (e.g. browser_wait) or stating when not to use it, so it is clear but not fully routed.

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 and delivers real behavioral value: it discloses the execution mechanism ("real mouse: press → move in steps → release") and a non-obvious implementation detail ("HTML drag is handled without starting an OS drag"). It omits failure semantics, auto-scroll behavior, and any permission/side-effect context, keeping it below 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, front-loaded with the action and mechanism before the target options, with zero filler. The use-case enumeration doubles as routing signal rather than padding.

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

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

For an 11-parameter mutation-style browser action with no annotations and no output schema, the description covers the essentials: what it does, how it does it, target specification, and the HTML-drag special case. Slots, tabs, and the read/summary params are fully documented in the schema, so nothing critical is missing, though side-effect and error behavior are unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds selection-level meaning the schema does not: it groups to / to_text / dx+dy as the three alternative ways to specify the drop location (element ref, visible text, or pixel offset). That framing helps an agent choose among 11 params rather than blindly reading them.

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+resource ("Drags with the real mouse") and immediately enumerates the distinguishing scenarios: drag and drop, sliders, reordering, drag CAPTCHAs. The contrast with browser_click (drag-and-drop vs. discrete click) is inferable from the use-case list 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 context for when to reach for this tool via the enumerated drag scenarios, which implicitly distinguishes it from sibling action tools like browser_click or browser_press_key. It does not name an explicit alternative or state when-not to use it (e.g. single-click targets), 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 no annotations, the description carries the burden and does real work: it discloses the isolated-world execution model, that DOM read/write is possible, and that page-created globals (window.appVar) are invisible. That last point is exactly the kind of surprise an agent needs warned about. It does not discuss permission needs, mutation side effects, or rate 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?

Three short sentences, no filler. Purpose and return are front-loaded, then the escape-hatch restriction, then the isolated-world caveat — a well-ordered information hierarchy.

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 state the return is JSON. Combined with the isolated-world caveat, an agent has what it needs to invoke this correctly. Minor gaps remain around failure modes and whether mutations persist across evaluations.

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% across all 6 parameters, so the schema already documents slot, tab, agent, summary, multiSlot and expression. The description adds only that Promises are awaited and results come back as JSON, which the schema largely covers already. 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 (evaluates) and resource (a JavaScript expression in the tab) plus the return shape (result as JSON). The 'escape hatch' framing immediately distinguishes it from the dozens of purpose-built browser_* action tools.

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 scopes usage to 'only when other tools can't do it', which is a clear when-to-use rule and a de facto exclusion. It stops short of naming which alternative tool to reach for first, so it is not fully self-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?

With no annotations, the description carries the full burden and does well: it discloses clearing behavior, real key events, value verification, non-atomic failure handling (stops on page change, dialog, or failed field), and that it reports partial progress. It does not describe the shape of that report, nor latency or rate considerations, but the mutation and failure semantics are unusually well covered.

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: mechanics first, failure/partial-completion behavior second, submit semantics third, with the sibling pointer last. Every clause earns its place and nothing is repeated from the schema verbatim.

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 mutation tool with 100% schema coverage and no output schema, the description supplies the behavioral context the schema cannot: ordering, clearing, verification, and stop conditions. It could say more about what the returned progress report looks like or what state the page is left in after a mid-fill failure.

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 all eight parameters are already documented, including submit ("Enter" or a button ref to click) and field ordering. The description restates those semantics and adds the clearing/verification detail for fields, but does not add format or syntax guidance beyond the schema, 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 and resource (fills several inputs on the same page, in order) and explicitly differentiates itself from the single-value sibling browser_type and the dropdown sibling browser_select. An agent can tell what this does and what it is not 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?

The closing sentence 'For dropdowns use browser_select' names an alternative and the condition that selects it. The multi-field, ordered nature of the tool also implies when it is preferable to repeated browser_type calls, but that comparison is left to inference rather than stated.

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 hints that the operation is state-dependent on prior back navigation, but says nothing about what happens if no forward entry exists, whether it errors or silently no-ops, or how it interacts with the tab/slot model.

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 short sentence with zero padding, and the operative condition is front-loaded in the parenthetical. It is efficient, though its brevity borders on under-specification for a six-parameter 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?

Given no annotations, no output schema, six parameters, and a multi-slot/multi-agent browser context, the description is far too thin. An agent gets no information about the empty-history case, error behavior, or how forward interacts with the slot and tab parameters beyond what the schema already states.

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 all six parameters (slot, tab, read, agent, summary, multiSlot) are already documented in the schema. The description adds nothing about any parameter, 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 action (go forward) and ties it to the browser history stack, and the parenthetical 'after going back' distinguishes it from the sibling browser_back. It's clear, though it never explicitly names the resource (browser history) or contrasts with other navigation siblings like browser_navigate.

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 phrase 'after going back' implies the condition under which forward navigation is meaningful, and that is the only usage guidance given. There is no statement of what to do when there is no forward history, nor any pointer to alternatives such as browser_navigate for fresh navigation.

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 burden. It usefully discloses that no click occurs and that the opened menu appears via read=changes, but says nothing about hover side effects (e.g. triggering JS hover handlers), timing, or failure when no element matches the ref.

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

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

Three short sentences, front-loaded with the action and immediate distinction from clicking. Every sentence adds 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 7-parameter, no-annotation, no-output-schema action tool, the description covers what the action does and how to observe its effect. Remaining gaps (slot/tab prerequisites, hover failure modes) are handled by the schema's own descriptions, so the agent is not left stranded.

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 genuine guidance by explaining that read=changes surfaces the newly opened menu — practical usage meaning beyond the schema's enum listing. It adds nothing for slot/tab/agent, but those are already fully documented.

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 ('moves the real mouse') plus resource ('a ref element') with an explicit negative ('no click') that separates it from browser_click. The added purpose clause ('for hover menus and tooltips') tells the agent exactly what interaction this serves.

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 context (hover menus, tooltips) and directs the agent to read=changes to capture the resulting menu, but never contrasts itself with browser_click or browser_drag, which are the nearest conflicting siblings.

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 non-obvious traits: attach-instead-of-relaunch on a running slot, a bare confirmation request when headless is unstated for a closed slot, and that proxy/headless apply only on first launch. It stops short of describing the response shape or failure modes, which is the remaining 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 the core action and the critical gating rule, then flows to multi-slot and subagent orchestration. Slightly dense and it duplicates the headless guidance already present in the schema, but every sentence still carries decision-relevant content.

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 nine-parameter, zero-annotation, no-output-schema tool, the description covers launch semantics, the headless decision, multi-slot batching, and post-launch subagent orchestration. What an agent gets back and how failures surface are left implicit, keeping it just under complete.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters, including the slot/urls pairing example and the port-minus-14049 rule. The description largely restates headless/count/slots semantics rather than adding new meaning, so baseline 3 applies.

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

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

States a specific verb+resource ("Starts slot Chrome") and immediately clarifies that an already-running slot is merely attached to, distinguishing launch from close/status/tab operations among the siblings. An agent can tell exactly what activation does without opening the schema.

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

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

Explicitly gates invocation: "Call only when the user explicitly asks (other tools never start a closed slot)", and prescribes the headless decision procedure (true only if user says headless/hidden, otherwise ask before calling). Names the alternatives (slots/count for multi-launch) and the follow-up pattern (per-slot subagents).

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?

There are no annotations, so the description carries the full burden. It discloses one genuinely useful behavioral trait — that the call blocks until the body loads — which tells the agent no explicit wait is needed. But it says nothing about error behavior on bad URLs, whether it resets page state, or how the 'read' capture interacts with the action.

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

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

A single front-loaded sentence with zero filler. It is arguably under-specified rather than verbose, but nothing in it is wasted text.

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

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

No output schema and no annotations, so the description should carry more weight. The schema compensates by documenting all 7 parameters well, but the description omits the multi-tab/slot coordination context and error semantics that make this tool distinct in a 35-tool browser suite.

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 the parameter docs are unusually rich (tab targeting, slot-to-port arithmetic, read modes, multiSlot semantics). The description adds nothing beyond the URL itself, 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?

Clear specific verb+resource: navigates a tab to a URL. An agent knows exactly what happens. However, it does nothing to distinguish itself from siblings like browser_launch, browser_reload, or browser_back, which all move a tab to a different page.

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 use this versus browser_launch (first navigation?), browser_reload, or browser_back/forward. No mention of the slot/agent coordination context that the schema hints is important. Usage must be inferred entirely.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: ordering ('newest at bottom') and a retention cap ('latest 500 since CDPM first attached'). It does not describe the return shape or how limit/type interact with the 500 cap, but the retention and ordering disclosure is above baseline.

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 clauses, front-loaded with the core purpose and ordering, then the retention cap, filter axes, and the escape hatch to the detail tool. No sentence 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 or annotations exist, so the description must stand alone; it covers purpose, ordering, retention, filters, and the handoff to browser_network_detail, and the 'n-number' reference implies numbered entries. Return format and pagination behavior are still undescribed, keeping 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 100%, so the schema already documents all eight parameters. The description restates the filter/type/failed semantics and gives type examples (Document, XHR, Fetch, Script, Image), which roughly mirrors the schema rather than adding new meaning beyond 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?

States a specific verb+resource ('Tab network request list') with an explicit scope note ('newest at bottom'), and explicitly routes detail lookups to the sibling browser_network_detail. An agent can distinguish this from browser_network_detail 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?

Names the alternative (browser_network_detail) and the condition for using it ('For details pass the n-number'), and explains the filtering axes. It lacks explicit when-not guidance or a note that this is a read-only view versus the detail tool, but usage context is clear.

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 more burden. It usefully discloses that response bodies are truncated ('start of it, if text') and that body is included by default, but says nothing about read-only nature, size limits, or how non-text responses are handled.

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 with zero waste; the core behavior is front-loaded and the id-provenance note follows immediately. Nothing is 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 read-only inspection tool with fully documented parameters and no output schema, the description adequately sketches the return content (headers, sent data, response body) and flags body truncation. Slight gaps remain around non-text responses and pagination/size limits, but the essentials are covered.

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 six parameters well, including slot normalization and tab ID guidance. The description adds only the cross-reference that id comes from browser_network and restates body's effect; 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?

Names a specific verb (shows) and resource (one request's headers, sent data, response body), and scopes it to a single request id, which cleanly distinguishes it from the sibling browser_network that lists requests. The truncation note ('start of it, if text') is a precise scope qualifier.

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 phrase 'id is the n-number from browser_network' establishes the precondition and effectively routes the agent from the listing tool to this detail tool. It stops short of an explicit when-to-use/when-not statement, but the dependency is clear.

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 two real behaviors: the default destination (Downloads, named after page title) when path is omitted, and that it 'doesn't change the screen or window'. It omits overwrite semantics, return value, and permission/error behavior, so it is solid but not complete.

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

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

Three short sentences, front-loaded with the action, then default behavior, then side-effect note. Every sentence earns its place with no 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 five-parameter tool with no output schema and no annotations, the description covers purpose, default path behavior, and non-intrusiveness. It leaves gaps around success output, overwrite behavior, and error cases, but the schema's 100% coverage carries the parameter documentation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning by explaining the default behavior of the optional path parameter (saves to Downloads named after page title). It adds no further detail for tab/slot/agent/multiSlot, which the schema already documents.

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 ('Saves the page as a PDF') with concrete examples (receipts, articles). The PDF output inherently distinguishes it from browser_screenshot, though no sibling is named explicitly.

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

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

The examples 'receipts, articles' imply intended scenarios but the description never states when to choose this over browser_screenshot or browser_download_wait, and gives no exclusions. Usage is only implied.

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

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

With no annotations, the description carries the full burden and delivers real behavioral context: bubbles are browser UI absent from snapshot/screenshot, page tools cannot click them, and the page often blocks until they are answered. It also discloses a platform constraint ('Windows, windowed slots only'). It stops short of describing reversibility or failure modes when a button name doesn't match, 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?

Front-loads what the tool does, then why it exists, then the two modes. Dense but every sentence carries information; the inline examples and Korean sample add real utility rather than padding. Slightly long but not wasteful.

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, it covers the essentials: what appears when no button is passed, how to answer, and the platform limitation. The main missing piece is disambiguation from browser_dialog, which would make it fully self-sufficient.

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 baseline is 3, but the description adds genuine value: it defines the two-mode contract for button (list first, then press the exact name as shown) and gives multilingual button-name examples. It reinforces the site selector's purpose in choosing among multiple open bubbles.

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 pair of verbs (lists/answers) on a precise resource (Chrome permission bubbles) and clarifies scope with the 'site wants to:' example. It partly distinguishes itself by noting that page tools can't click these, but it never names the closest sibling, browser_dialog, so an agent must infer the split. Clear purpose, incomplete sibling differentiation.

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

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

Explains the trigger context ('the header warns when one is open') and the two invocation modes (omit button to enumerate, supply button to press), giving solid when-to-use guidance. It lacks explicit exclusions or routing versus the browser_dialog sibling, which handles adjacent dialog UI.

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 a genuine behavioral trait beyond the schema: the key is sent to the currently focused element, which means focus must be established first. However it says nothing about side effects, whether the browser must be launched, or failure behavior when nothing is focused.

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 followed by useful examples; nothing is padded. The example list partially overlaps the schema's example but is still the most useful part of the description.

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

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

For a simple action tool with no output schema and no annotations, the description covers the core action but omits prerequisites (browser launched, target element focused, slot/tab context) and any routing against the many sibling action tools. 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 description coverage is 100%, so all seven parameters (key, slot, tab, read, agent, summary, multiSlot) are already documented in the schema, including key-combo syntax. The description's key examples roughly duplicate the schema's own example rather than adding new semantics, so baseline 3 applies.

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

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

States a specific verb+resource ('Presses a key on the focused element') and the example keys make the scope unambiguous. It implicitly distinguishes itself from browser_type/browser_fill (text entry) by implying single-key/shortcut presses, though it never names those siblings 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?

The examples (Control+A, Shift+Tab, PageDown) imply the intended use case of keyboard shortcuts and navigation keys, but there is no explicit when-to-use or when-to-prefer-alternatives guidance versus browser_type for text input or browser_click for activating 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 no annotations, the description carries the full burden, and it does disclose the most important behavioral trait: unsaved user input on the page is lost. It also explains the cache-bypass effect of ignore_cache. It omits any auth/permission context or return behavior, but the core destructive consequence is clearly flagged.

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, zero waste, with the primary purpose front-loaded and the warning properly positioned last where it is most likely to be read before acting.

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

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

For a simple page-reload tool with one required parameter, full schema coverage, and no output schema, the description covers purpose, the key behavior, and the main side effect. It is essentially complete, with only minor gaps around multi-tab/slot context.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, including ignore_cache's own description. The description adds little beyond restating that ignore_cache bypasses the cache, 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 ('Reloads the page') and clarifies the semantics with the analogy '(same as Chrome reload)'. It is clearly distinguishable from browser_navigate, browser_back and browser_forward, 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?

Usage is implied by the reload semantics and the ignore_cache note, giving the agent a sense of when to reach for a hard reload. However, there is no explicit guidance on when to reload rather than re-navigate, and no mention of prerequisites or tab/slot requirements for calling it.

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

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

With no annotations, the description carries the behavioral burden and discloses key traits: background tabs work without switching, viewport/window size is never changed, and output is PNG. It does not detail return encoding or error cases, but the core behavioral constraints are well covered.

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 main capability, then the key limitation and alternatives. No wasted text.

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

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

For a low-complexity screenshot tool with rich schema coverage and no output schema, the description is nearly complete. It states PNG output, but could clarify how the image is returned (data, path, or tool result).

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 four parameters. The description adds no parameter-specific meaning, which is acceptable at baseline 3 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 verb and resource ("Captures the visible area of the tab as PNG") and distinguishes scope from siblings by noting full-page capture is unsupported and pointing to snapshot/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 covers when-not to use it (full-page capture unsupported) and names alternatives (scroll then capture, or use snapshot/text). This is clear routing guidance an agent can act on.

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 direction semantics and that the resulting position is reported, but says nothing about permissions, multi-slot/tab interaction, or side effects on 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?

A single dense sentence that front-loads the verb and the two modes, with no wasted words. Direction and default are packed in parenthetically without distraction.

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 action tool with no output schema, the description covers the core scroll mechanics; remaining parameters (read, slot, agent, summary, multiSlot) are documented in the schema. Reporting the resulting position compensates for the missing output schema, leaving only minor gaps around tab/multi-slot 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?

With 75% schema coverage, the baseline is 3, but the description adds real meaning beyond the schema: the dy parameter has no schema description, and the description supplies sign convention (positive=down, negative=up) and the default of 600, plus clarifies that ref targets a ref element.

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 (scrolls) with two distinct modes: a ref element into view, or by dy pixels. It's clearly distinguishable from siblings like browser_click or browser_wait, though it doesn't explicitly name 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 implied by the ref-vs-dy alternative, but the description never states when to prefer scrolling a ref into view versus offset scrolling, nor when scroll is preferable to browser_wait or a snapshot. No explicit exclusions or prerequisites 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the interaction mechanism (focus plus arrow keys on Windows/Linux, first-letter typing on macOS), that the page receives real events, and the fallback behavior when no option matches (lists available options). It does not say whether it scrolls the dropdown into view or what happens if the ref is not a combobox.

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 tightly packed sentences, front-loaded with what the tool does, followed by how it works and the failure behavior. Every sentence carries information an agent needs; nothing is padding or restated from the title.

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

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

For an eight-parameter action tool with no annotations and no output schema, the description covers the operation, its mechanism, and its no-match behavior. The 'read' parameter already governs what page content comes back, so return values need not be explained, but the description is silent on error cases such as a stale or invalid ref.

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 meaningfully enriches the key domain parameter by explaining that 'option' accepts either value or visible text and permits partial matches - detail the schema's bare 'Option value or text' does not convey. It adds nothing about the other seven parameters, which the schema already documents thoroughly.

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 (picks) and resource (option in a <select> dropdown), and the mechanism described (keyboard-driven selection rather than clicking) cleanly separates it from siblings like browser_click or browser_fill. An agent can tell exactly what operation this is 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?

Usage context is strongly implied: the tool targets native <select> dropdowns and explains that because it moves with keys, 'no list popup opens' - implying it is the correct choice over browser_click for these elements. It also documents a partial-match tolerance, but never explicitly names an alternative tool to use for non-<select> dropdowns.

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 delivers: refs are assigned as [e12], long pages are paginated with refs stable across pages, find and ref narrowing behavior are described, and critically it warns 'Refs change when the page changes, so re-snapshot before acting' — a non-obvious, action-relevant behavioral trait.

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

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

Front-loaded with the core purpose, then dense behavioral facts, ending on the most important operational warning. Every sentence conveys distinct, actionable information 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 an 8-param, no-output-schema tool, the description explains the return shape (a11y tree with refs), pagination, and ref lifecycle well. Slot/tab/agent/multiSlot semantics are left entirely to the schema, which is acceptable given their 100% coverage, but the description adds nothing about them.

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 adds meaning beyond the schema: it documents cross-page ref stability (schema says only 'page=2 to continue') and gives concrete usage examples for find ("text") and ref ("e40") subtree behavior.

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: 'Reads the tab as accessibility-tree text.' This immediately separates it from siblings like browser_text (raw text) and browser_screenshot (image) by naming the distinct output format and the ref-annotated tree structure.

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 workflow context: 're-snapshot before acting' establishes that this must precede action tools, and the find/ref guidance explains situational usage. It stops short of explicitly naming when to prefer this over browser_text or browser_screenshot, so no exclusions are stated.

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 discloses the read-only nature implicitly ("Shows running") and describes the information returned, which is genuinely useful, but omits what happens when no slots are running, ordering, and any cost or rate considerations.

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

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

Two tight sentences with the resource and returned fields front-loaded. The second sentence is short and useful for a multi-slot vs single-slot decision, though it is partly restating schema behavior, which keeps it from a clean 5.

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 2-parameter, annotation-free tool with no output schema, the description does well by enumerating the returned fields in place of a schema. It is still incomplete on lifecycle context (must a slot be launched first?) and empty-state behavior, which an agent needs to call and interpret it correctly.

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

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

Schema description coverage is 100%, so the schema already fully documents both slot and agent, including the port-to-slot conversion. The description's only addition is confirming that omitting slot returns all slots and supplying it narrows to one, which is a minor clarification rather than new semantics. 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 and resource ("Shows running Chrome slots (1-30)") and enumerates the returned contents (tabs, opener, last action, one-line summary), which differentiates it from generic siblings like browser_tabs or browser_snapshot. It stops short of naming a sibling explicitly, so an agent must still infer which of the 30+ browser_* tools to prefer.

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?

"Pass slot for just that slot" is calling mechanics, not when-to-use guidance. Nothing says when an agent should call browser_status versus browser_tabs, browser_snapshot, or slot_inbox, nor does it state prerequisites such as whether a slot must already be running.

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 of behavioral disclosure, and it says almost nothing. It does not reveal what happens to unsaved state, whether closing the last tab closes the browser, how the active-tab pointer behaves, or whether the call errors on a stale tab id.

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

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

The description is short and front-loaded, which is appropriate for a simple tool. The second sentence ('tab is required') is pure redundancy with the schema's required list and does not earn 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 mutation tool with no annotations and no output schema, the description is too thin. It never mentions the slot parameter that must accompany the close, nor the agent identity parameter, and it omits any error/edge-case behavior an agent would need to call it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3 – the schema already documents tab formats ('t7' or number), slot 1-30, and the agent display name. The description's 'tab is required' adds no meaning beyond the schema's required array.

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 ('Closes a tab'), which is enough to distinguish it from siblings like browser_tab_new or browser_tab_select at a glance. However, it offers no differentiation from browser_close (closing the whole browser) vs. closing a single tab, leaving the boundary to inference.

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 only guidance is 'tab is required,' which restates the schema's required list rather than explaining when to use this tool. There is no mention of alternatives such as browser_close when no tabs remain, or prerequisites for calling it.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully states that the call returns the tab ID and warns about cross-agent tab mixing, but says nothing about whether the new tab becomes the active/focused tab, its interaction with the slot's current state, or any permission requirements. Some behavioral value added, clear gaps remain.

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, zero filler. The core action and return value are front-loaded, and the multi-agent caution follows as supporting context.

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

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

With no output schema, the description helpfully notes the returned ID, and the 100% schema coverage handles parameter detail. It is nearly complete for a small connector tool, only missing behavioral detail such as whether the new tab takes focus.

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 all four parameters (url, slot, agent, summary) are already richly documented, including slot parsing rules and the agent display-name default. The description adds no format or meaning beyond the schema. 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 and resource ('Opens a new tab in the slot') and adds the useful side effect that it returns the tab's ID. It is naturally distinguishable from browser_tabs, browser_tab_close, and browser_tab_select by operation, though it never names those siblings 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?

Provides clear context for use: 'When agents share a slot, open your own tab and work only by its ID to avoid mixing.' This tells the agent a concrete scenario and the behavioral convention to follow. However, it gives no exclusions or explicit alternatives (e.g. when to re-use an existing tab instead of opening a new 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 exist, so the description carries the full burden. It does disclose real behavioral detail: the '·front' marker semantics (one per window) and that per-tab summaries are refreshed only by actions carrying a summary. It says nothing about whether the call is read-only or what side effects/permissions are involved, though listing is inherently low-risk.

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 dense sentence, front-loaded with what the tool yields, with the field list following. It is efficient, though the parenthetical about summaries and the quoted '·front' marker make it slightly harder to parse.

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 the description usefully compensates by enumerating returned columns and explaining the '·front' marker, which is genuinely helpful. However it omits usage context relative to sibling tools and any note on whether the list is filtered or paginated.

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 both parameters (slot, agent) are fully documented in the schema, including the slot range and port conversion rule. The description adds only an incidental mention of 'slot' with no syntax detail beyond the schema, so 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 the tool produces a tab list for a browser slot and enumerates the returned fields, so the resource and result are clear. It does not explicitly name the verb 'list open tabs' nor differentiate itself from the near-sibling browser_status, which also reports browser 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as browser_status or browser_snapshot. The agent must infer that this is the way to enumerate tabs.

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

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

With no annotations, the description carries the full burden and it does disclose the key side effect: it changes what the user sees, and it clarifies that tab visibility is not required for read/operate/capture operations. It omits failure/edge behavior (tab already active, unknown tab or slot), so it is strong but not exhaustive.

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 plus a parenthetical; the action is front-loaded and the parenthetical earns its place by preventing an unnecessary tab switch. 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 no-output, no-annotation tool this covers purpose, user-visible effect, and when to avoid it, with parameters fully handled by the schema. Only minor gaps remain (error/edge cases, whether the previous tab is affected).

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 the schema already documents slot (with port math), tab, and agent semantics richly. The description adds no parameter-level information, 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?

Specific verb ('brings to the front') and resource ('a tab of its Chrome window'), with an implicit scope that separates it from browser_tabs (listing) and browser_tab_new/close. An agent can identify the operation and its effect on visible state 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 an explicit when ('use only when the user wants it') and a when-not ('background tabs can be read, operated and captured; no need to bring them forward to work'), effectively steering the agent away from unnecessary calls. This is exactly the kind of routing guidance the dimension 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?

There are no annotations, so the description carries the full behavioral burden. It usefully discloses the main/article extraction fallback, the ref-narrowing behavior, and that output can be paged, but it does not describe truncation limits, the return shape, or read-only guarantees, leaving meaningful gaps for a 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 the core behavior front-loaded and no filler. The final clause 'Use page for long text' is slightly cryptic but still earns its place as an operational hint.

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

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

For a read-only extraction tool with no output schema or annotations, the description covers purpose, the key fallback behavior, narrowing via ref, and pagination guidance. It is nearly complete; only return-format and truncation details are absent, which the missing output schema makes somewhat more noticeable.

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 six parameters, making 3 the baseline. The description adds minor value by tying ref to element-only text and page to long output, but introduces no syntax or format detail 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 (reads) and resource (page body text), plus the main/article fallback logic. It explicitly contrasts itself with a named sibling (snapshot) as 'shorter and easier... for articles/documents', so an agent can distinguish it 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?

Names the competing tool (browser_snapshot) and the condition that favors this one (articles/documents), and directs long output to the page parameter. It gives clear positive context but no explicit when-not-to-use or edge cases, 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 burden and does so: it discloses per-character key events, value verification with mismatch reporting, fast-mode bypass of key events, and the notable quirk that date/time inputs are set directly with isTrusted=false. These are non-obvious behaviors an agent could not infer 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 core operation, then the option flags, then the date/time edge case. Dense but every sentence adds operational detail; 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 for this by explaining that the resulting value is verified and mismatches reported. Combined with the mode semantics, an agent has enough to call the tool correctly; only sibling-differentiation is thin.

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 baseline is 3. The description largely restates the schema's own parameter documentation (clear, submit, fast) rather than adding meaning beyond 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?

States a specific verb and resource ('Types text into a ref element') and immediately distinguishes itself by disclosing real per-character key events, which separates it from value-setting siblings like browser_fill. An agent can identify the tool's operation 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 clear conditional guidance — clear=true to wipe existing content, submit=true to press Enter, fast=true for very long text — which tells the agent which mode to pick. It does not explicitly contrast with browser_fill or browser_press_key, so selection against siblings is left partly 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?

No annotations exist, so the description carries the burden, and it does disclose real behavior: no OS file picker surfaces to the user, the CDPM layer intercepts the native picker, and the site receives the same events as a human file pick. It stops short of error/permission behavior (unsupported inputs, failed uploads, size 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?

Three tight sentences: what it does first, then the two ways to target an input, then the fidelity guarantee. No filler and the critical scoping detail leads.

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, no-output-schema action tool, the description fully covers the request-specific semantics an agent needs to call it correctly, while generic parameters (slot, agent, summary, read, tab) are adequately handled by the schema. Only failure/edge-case behavior is omitted.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning to 'ref' by explaining the two operating modes (native input vs. just-opened picker) that the schema's one-line property description only hints at. It also implies the local file-path nature of 'files'.

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 ('Puts files into a file input') and immediately clarifies the non-obvious mechanism ('no OS file picker shown'). An agent can distinguish this from browser_click and browser_fill 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 two explicit invocation modes with the deciding condition: pass ref for a native input, or click the site's custom attach button first with browser_click and call without ref because CDPM intercepts the picker. It names the alternative tool and when to pair it.

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

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

With no annotations, the description carries the full burden and does so: it declares the tool "Only reads, never touches the page, so the user's input is not lost," states it returns as soon as the condition is met or a message arrives, and explains the response mode returns the body and searches from the agent's last action. This is rich behavioral disclosure beyond what the schema states.

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 key information — the mode list — is front-loaded effectively, and each subsequent sentence (SPA shortcut, read-only safety, minimal waits) earns its place. However the first sentence is a dense semicolon run-on, which slightly hurts scannability.

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

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

For a 12-parameter tool with no annotations and no output schema, the description is nearly complete: it covers modes, timing, safety, and return-body for response. It does not state what a text/gone/url wait returns or what happens on timeout expiry, leaving a couple of 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 100%, so the baseline is 3, but the description adds real value by explaining mode precedence ("otherwise for seconds") and the semantics of response wildcards and returned bodies that tie the parameters together. It stops short of fully documenting timeout-failure behavior, so it is above baseline but not exhaustive.

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 concrete verb ("Waits until") and exhaustively enumerates the condition modes — text, gone, url, enabled, response, network_idle, seconds — so an agent knows exactly what the tool does. It also names the sibling it is not ("to wait for other agents use slot_inbox wait"), distinguishing it from the other wait-style tools.

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

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

It gives explicit when-to-use guidance per mode and an alternative: for SPAs use response="/api/search" "instead of reading the page," and it routes agent-message waiting to slot_inbox wait. It also constrains duration ("Keep waits minimal: long waits only for humans"), leaving little 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 it does disclose several non-obvious behaviors: blocking semantics for wait, the unread-message definition (header-delivered messages excluded), and what happens when nothing new exists (recently received ones are 'noted for reference'). It leaves unclear whether fetching marks messages as read, and does not describe message shape or size limits, which matters for a receive 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, purpose front-loaded, then wait behavior, then the unread edge case. No restatement of the name, no filler, and each sentence conveys something an agent could act on.

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

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

With no output schema and no annotations, the description supplies the return semantics an agent needs (unread-only, fallback of recent messages, blocking behavior). Remaining gaps — whether reads are consumed, and what a message looks like — are modest for a simple polling endpoint but would be worth one clause.

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 all three parameters are well documented in the schema itself (including the wait-vs-polling hint and the slot port arithmetic). The description adds only the conversational framing of wait ('for real-time conversation'), so the baseline 3 applies — the schema, not the description, does the parameter work.

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: 'Shows your unread messages.' It also clarifies a non-obvious boundary (messages delivered in another tool's header are not unread), which lets an agent reason about what it will get back. It does not name a sibling alternative (slot_send) or reference slot_pause/slot_resume, so differentiation comes mostly from the distinctive 'inbox' concept rather than explicit 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?

The description explains the polling mode ('with wait, waits up to that long for a new message (for real-time conversation)'), which is real guidance, but usage conditions are only implied — there is no explicit 'use this when X, use slot_send when Y' statement or statement of when not to call it. The agent must infer that this is the receive half of a send/receive pair.

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 behavioral burden and does so richly: it discloses what is blocked (all action tools), what is interrupted (browser_wait in progress), what survives (an action already sent to Chrome finishes; reading still works), the cross-session reach, and the all=true scope. This is far more than a restatement of the name.

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 important constraint (only call on explicit user request) is front-loaded, and nearly every sentence is terse and load-bearing. A couple of clauses, such as the note about other Claude sessions, are useful but slightly tangential for a pause 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?

For a mutation-style control tool with no annotations and no output schema, the description covers effect scope, timing, and cross-session behavior well. It does not state what the call returns or confirm whether an ack is produced, which is a minor gap given the absence of an output schema.

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 four parameters, making a baseline of 3 correct. The description adds the meaning of all=true ('pauses every running slot') beyond the schema's terse 'All running slots', but gives no guidance on choosing between slot, slots, and all.

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+resource (pause a browser slot) and immediately distinguishes it from its counterpart siblings by stating it is only for user-requested pauses, with slot_resume implied as the inverse. It also scopes the effect precisely ('All action tools on the slot are refused', 'all=true pauses every running slot'), so an agent can separate it from other slot tools 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?

Explicit when-to-use ('Use only when the user says to pause, e.g. "pause 3"') and explicit when-not ('agents never call it on their own') are both stated, which is exactly the exclusion guidance an autonomous agent needs. 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 side effect (messaging every agent on the slot) and the wake semantics (agents re-read the page and continue). It does not cover failure cases (e.g. what happens if the slot is not paused) or permission requirements, keeping 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?

Front-loads the critical usage constraint before describing behavior, and every clause earns its place with no filler. Two tight sentences cover usage, mechanism, and the all-flag.

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 when to call it, what it does, and the wake side effect. It omits edge-case behavior (unpausing a non-paused slot) and error/return expectations, but is otherwise complete enough to call 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 100%, so the baseline is 3; the description adds real meaning by explaining the effect of the flag — 'all=true resumes every paused slot' — which is more than the schema's terse 'All paused slots'. The slot/slots/agent params are left entirely to the schema.

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

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

States a specific verb and resource — 'Unpauses and messages every agent on the slot to wake it' — and describes the concrete consequence (agents re-read the page and continue). An agent can distinguish this from slot_pause and slot_send 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?

Explicitly scopes invocation to 'only when the user says to resume (e.g. "continue 3")' and adds a hard when-not rule: 'the agent owning a paused slot never calls it on its own.' This is exactly the routing guidance 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 disclosure burden, and it does so well: it explains delivery timing (instant if the recipient is waiting in slot_inbox wait), fallback delivery (next tool result header), and side effects (a running browser_wait stops at once). It omits rate limits or ordering guarantees, but the key behavioral mechanics are present.

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, then layers scoping, delivery, and timing notes in dense sentences. The parenthetical '(real-time collaboration)' is mild filler and the slot explanation is repeated twice, but overall it is efficient.

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-parameter tool with no annotations and no output schema, the description covers the essential semantics: recipient selection, broadcast behavior, and delivery timing. Return values are the delivered message on the other side, which the description implies; nothing critical is missing for correct invocation.

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

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

Schema coverage is 75%, and the description adds real meaning beyond it: it explains what 'slot' means from the recipient's perspective and what omitting 'to' does (broadcast to the slot). It does not address the optional 'agent' display-name parameter, but the schema's own description covers that.

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 ('Sends a message to other agents') and distinguishes itself from siblings like slot_inbox by describing the send direction. An agent can tell immediately this is not a browser-control tool.

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

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

Gives clear usage context ('When you finish a step, notify waiting agents right away') and routing guidance ('Omit to to send to everyone on that slot'). It does not explicitly name when to prefer slot_inbox or slot_pause over this, but the trigger condition is concrete.

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