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

With no annotations, the description carries the full behavioral burden and delivers nothing: no statement of what happens at the start of history, whether it is a navigation/mutation, what the resulting page state is, or how it interacts with the multi-slot/agent model described in the schema.

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

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

Two words are technically concise, but this is under-specification rather than conciseness — the sentence does not front-load any actionable information and nothing meaningful is conveyed.

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 history-navigation action with no annotations and no output schema, the agent gets no information about behavior, side effects, or edge cases. The rich schema covers parameter mechanics, but the description leaves the actual behavior of "back" unexplained.

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

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

Schema description coverage is 100%, so all six parameters (slot, tab, read, agent, summary, multiSlot) are already fully documented in the schema. The description adds no parameter meaning, so the baseline of 3 for high coverage applies.

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

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

"Go back" restates the tool name and title (Back) without adding specificity. It does imply browser-history navigation, but it names no resource, no scope, and does not distinguish itself from the sibling browser_forward beyond the obvious opposite direction.

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_forward, browser_navigate, or browser_tab_select, nor any prerequisite such as having history to go back to. The agent must infer the condition entirely.

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

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

With no annotations, the description carries the full burden and delivers: rules skip the tab cache, rules last only for this session, rules are surfaced to other agents in the header, and matched requests fail. These are non-obvious side effects 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?

Dense but front-loaded: behavior and verbs lead, then pattern syntax, then lifetime/visibility caveats. Every sentence carries operational information, though the pattern-syntax block is lengthy enough to feel compact rather than elegant.

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 essentials: what is blocked, how rules are added/removed/cleared, how patterns are interpreted, session-scoped lifetime, cache side effect, and no-arg read behavior. Nothing critical to correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds pattern-language semantics the schema never states: * and ? wildcards, bare-domain expansion ('ads.example.com' → '*ads.example.com*'), and automatic trailing-star addition for query strings. That materially changes how an agent should write add/remove values.

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 ('Blocks tab network requests matching URL patterns') and immediately clarifies the consequence ('they fail'), which distinguishes it from the read-only browser_network / browser_network_detail siblings. The add/remove/clear verbs are enumerated so the agent knows this single tool covers the whole rule lifecycle.

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

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

It tells the agent how each mode is selected (add adds, remove removes, clear removes all, no args shows current rules), which is genuine usage guidance for a multi-mode tool. It does not explicitly say when to prefer this over browser_network for inspecting traffic, but the operating 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 the full behavioral burden, and it does disclose substantial behavior: real mouse events, occlusion detection (skips and reports the covering element), navigation-triggered loading waits, new-tab reporting, file-picker interception, and non-handling of <select>. However, it says nothing about permission/auth requirements, failure/error reporting beyond occlusion, or whether the action is irreversible. The disclosure is strong but the no-annotation baseline leaves gaps that a 4-5 would require closing.

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 dense sentences, zero filler, front-loaded with the primary action and its occlusion caveat before the secondary routing notes. Each clause conveys a distinct behavioral fact an agent needs.

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

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

For an 8-parameter, no-output-schema, annotation-free action tool, the description covers the highest-risk behaviors (occlusion, navigation waits, file pickers, select dropdowns). It stops short of describing error returns and multi-slot/agent coordination semantics, which are left to the schema, leaving a small but real completeness gap.

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

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

Schema description coverage is 100% across all 8 parameters (ref, tab, read, slot, agent, double, summary, multiSlot), so the schema already documents everything. The description adds only the implicit meaning of "ref element" (matching the schema's browser_snapshot ref), which does not exceed the structured field. Baseline 3 is correct 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 precise verb+resource ("Clicks a ref element with real mouse events") and immediately bounds the scope against siblings: it does not click <select> dropdowns and routes those to browser_select. An agent can distinguish it from browser_type, browser_fill, browser_select, and browser_upload 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?

Explicit when-not and alternative routing: file inputs/attach buttons are intercepted, so use browser_upload; <select> dropdowns are not handled, so use browser_select. This is exactly the when/when-not/alternatives pattern that lets an agent pick the right tool on the first try.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the session and cookies are saved, the profile/logins are preserved, and it reports recent use by another agent. This is genuinely useful state-persistence context, though it omits error cases (closing an already-closed slot) and any permission requirements.

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

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

Three short sentences with no filler, front-loaded with the action and its primary consequence. Every sentence carries distinct information (what closes, what persists, what is reported).

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 single-slot mutation with no output schema and no annotations, the description covers the key behavioral outcome and even describes the returned signal (recent use by another agent). Only error/edge-case behavior is absent.

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

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

Schema description coverage is 100%, so slot (1-30 mapping rules) and agent are already fully documented in the schema. The description adds no parameter meaning beyond that, 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: "Closes slot Chrome cleanly," which is enough to distinguish it from sibling browser_tab_close (closes a tab, not the slot/browser). It does not name the sibling it is contrasted with, so the differentiation is left to inference rather than stated 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 only implied: an agent infers this is the tool for shutting a browser slot down. No condition is given for when to use this versus browser_tab_close or slot_pause, and no prerequisites (e.g. the slot must be launched) 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 burden and does well: it discloses the frozen-tab state while a dialog is open, that beforeunload accept loses input while dismiss stays, and that text applies only to prompts. It does not say what happens if no dialog is actually open (error vs. no-op) or whether the call blocks until resolution.

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 accept/dismiss mapping in the first clause, then layers policy and edge cases. Dense but every sentence adds a decision rule; the parenthetical dialog-type list and the beforeunload/prompt sentences are the only slightly compressed spots.

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 dialog-resolution tool with no annotations and no output schema, it covers the dialog types, the ambiguity-resolution policy, and the frozen-tab side effect. It stops short of stating the failure mode when no dialog exists or what the agent will observe after resolution, which is a minor but real gap for an action tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning beyond the schema for two parameters: accept's direction is restated with dialog-type-specific consequences for beforeunload and prompt, and text is scoped to accepting a prompt only. It adds no semantics for slot, tab, read, agent, summary, or 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 precise verb pair (accept/dismiss) on a specific resource (an open dialog) and enumerates the four dialog types it covers. An agent can immediately distinguish this from browser_click or browser_press_key, which never resolve native dialogs.

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 decision policy: judge from content and handle it yourself, accept if it is part of the requested task, close unneeded notices/ads, and ask the user only for irreversible actions they did not request. It also names concrete alternatives to escalate to (the user) and case-specific rules for beforeunload and prompt.

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 does disclose useful traits: it targets the *most recently started* download, blocks only until completion, and returns the saved path in the user's Chrome download folder. However, it omits what happens on timeout (the schema's 120s default) or on download failure, which are the key risks for a wait-style 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, and "Returns as soon as it finishes" usefully clarifies that it does not block for the full timeout. 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?

There is no output schema, so the description correctly fills that gap by naming the return value (saved file path) and its location. It is nearly complete for a simple wait tool, missing only failure/timeout outcome behavior.

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

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

Schema description coverage is 100%, so slot, agent, and timeout are already fully documented in the schema (including the port-subtraction rule and the 120s default). The description adds no parameter-level meaning, 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 (waits) and resource (most recently started download) and adds the return value (saved file path in Chrome's download folder). It implicitly distinguishes itself from the generic browser_wait sibling, but never names that alternative, so differentiation is left 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?

"Call after clicking the download button" gives a clear triggering context and ordering. It does not state when-not to use it (e.g., vs. browser_wait) or what to do if no download was started, but the positive guidance is unambiguous.

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

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

No annotations are provided, so the description must carry the behavioral burden, and it does disclose the underlying mechanism (real mouse press/move/release) plus the important distinction that HTML drag is handled without starting an OS drag. It omits failure modes (e.g. what happens if the drop target isn't reachable) and does not describe the response, though the schema's 'read' parameter covers post-action reading.

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

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

Three tight sentences, front-loaded with the verb and mechanism, then targeting options, then the HTML-drag caveat. No filler and each clause carries distinct information.

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

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

For an 11-parameter action tool with no annotations and no output schema, the description covers the core behavior, drop-target alternatives, and the HTML-vs-OS drag distinction, while the schema fully documents slot/tab/agent/read/summary. It stops short of stating prerequisites (active tab, element visibility) or what a failed drag looks like.

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

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

Schema coverage is already 100%, so 3 is the baseline, but the description adds real meaning by presenting 'to', 'to_text', and 'dx/dy' as the three alternative ways to specify the drop target and clarifying that dx/dy are relative to 'from' — a choice the schema lists but never frames as mutually exclusive options.

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 mechanism ('Drags with the real mouse (press → move in steps → release)') and enumerates concrete use cases (drag and drop, sliders, reordering, drag CAPTCHAs). This clearly separates it from siblings like browser_click and browser_hover without needing to 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?

The enumerated scenarios (drag and drop, sliders, reordering, CAPTCHAs) give clear context for when this tool applies, and the target-selection sentence tells the agent how to aim the drag. There is no explicit 'when not to use this / use X instead' guidance versus browser_click, which keeps it out of 5 territory.

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 substantial work: it discloses the isolated-world execution model, that DOM can be read and modified, and that page-created globals (window.appVar) are invisible. It leaves out failure modes (CSP blocks, thrown errors) and persistence of DOM mutations, so it falls 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?

Three tight sentences, front-loaded with purpose, then usage constraint, then the critical execution-environment caveat. 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 tool with no annotations and no output schema, the description covers purpose, fallback usage, return format, and the isolated-world semantics that would otherwise surprise an agent. It could say more about error behavior and whether mutations persist, but it is largely 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 every parameter (tab, slot, agent, summary, multiSlot, expression) is already documented in the schema. The description adds no parameter-level syntax or format detail, 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 (evaluates) and resource (a JavaScript expression in the tab) plus the return form (result as JSON). It clearly differentiates itself from the DOM-oriented siblings by positioning itself as the escape hatch rather than a structured action 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?

"Escape hatch only when other tools can't do it" is an explicit when-to-use and when-not-to-use rule. Combined with the sibling list of purpose-built browser_* tools, an agent knows to reach for this only as a fallback.

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 discloses clearing each field, real key events, value verification, and the stop conditions (page change, dialog, failed field) plus partial-progress reporting. It omits any auth/permission prerequisites and rate-limit behavior.

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

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

Three dense sentences with zero filler; the core behavior is front-loaded and the alternative-tool hint is placed last where it's least disruptive. Every clause carries actionable information.

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

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

For an 8-param, no-annotation, no-output-schema tool, the description covers ordering, per-field mechanics, stop conditions, and partial failure reporting. It leaves return-shape details ("reports how far it got") and tab/agent parameter behavior to the schema, which is reasonable but not exhaustive.

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 meaning to the submit parameter that the schema lacks — "Enter" presses Enter in the last field and a button ref clicks that button. This clarifies the exact dispatch behavior beyond the schema's terse "Enter or a button ref to click."

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 distinguishes itself from browser_select by routing dropdowns elsewhere. An agent can tell it apart from browser_type (single input) and browser_select from the text 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?

Explicitly names the alternative for dropdowns ("For dropdowns use browser_select") and implies multi-field batching via "several inputs on the same page." It stops short of an explicit when-to-use-this-vs-browser_type statement, so it's clear context without full exclusion 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say what happens when there is no forward entry, whether it affects only the current tab, or how it interacts with the 'read' parameter that appends page content after 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?

One short, front-loaded sentence with no filler; the action is the first word. It is efficient, though arguably under-specified rather than deliberately lean given the tool's six parameters.

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 six-parameter navigation tool with no annotations and no output schema, the description omits failure conditions, tab/slot targeting behavior, and the side effect of the read parameter. The schema covers parameters, but the behavioral envelope an agent needs is largely absent.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters including tab targeting, the read enum, slot numbering, and multiSlot semantics. The description adds no parameter meaning beyond that, which is the expected baseline 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+resource (navigate browser history forward) and implicitly distinguishes itself from the sibling browser_back by the parenthetical 'after going back'. An agent can identify the action, though the phrasing is terse rather than explicit about scope (per-tab history vs. slot-level).

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?

'after going back' implies the usage context (undoing a back navigation), which is more than nothing, but it gives no explicit when-not guidance, no note that it fails when there is no forward history, and no named alternatives beyond the implied browser_back.

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 usefully discloses that this is a non-clicking move whose purpose is to open menus/tooltips and hints that hovering changes page state (hence read=changes), but it says nothing about timing, whether the hover must be followed before the menu closes, or any permission/slot prerequisites an agent needs.

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

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

Three short sentences, zero filler, front-loaded with the action and the click distinction, followed by purpose and the read tip. Everything earns its place.

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

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

For a 7-param action tool with no output schema and no annotations, the description covers the core interaction (non-clicking hover) and the read follow-up. It leaves the multi-tab slot/tab routing caveats to the schema, which does document them, so the coverage is nearly complete but the description itself does not reinforce those requirements.

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 adds genuine value on top by recommending the specific enum value read=changes for this tool's purpose, and by naming 'ref element' to reinforce the target parameter. It does not add syntax beyond the schema for other params, keeping it just above 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 and resource ('Moves the real mouse over a ref element') and immediately disambiguates from sibling browser_click with '(no click)', so an agent can route between hover and click without opening either schema. The use cases (hover menus and tooltips) further pin down the intent.

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?

'For hover menus and tooltips' gives clear context for when to reach for this tool, and 'Use read=changes to see the opened menu' guides the follow-up action. It stops short of 5 because no explicit exclusion or named alternative (e.g. 'if the menu requires a click, use browser_click') is offered.

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 meets it: it discloses attach-when-already-running behavior, that starting a closed slot without headless only yields a confirmation request, and that headless/proxy apply only on first launch. It stops short of describing the return payload or failure modes, 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?

Front-loaded with the governing rule and organized into discrete decision points, with almost every sentence adding operational content. The headless/closing paragraph is slightly repetitive ("ask first, then call with headless"), a minor structural cost.

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

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

For a 9-parameter, zero-annotation, no-output-schema tool, the description covers intent, safety gating, and parameter interplay thoroughly. The only shortfall is that, absent an output schema, it could have said more about what a successful launch returns beyond the confirmation-request case.

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 goes beyond by encoding user-intent mapping ("slot 3" → 3, port 14052 → subtract 14049) and cross-parameter interaction rules (slots/urls pairing order, count launch order, proxy first-launch-only). These rules are not derivable from the schema fields alone.

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?

"Starts slot Chrome" gives a specific verb and resource, and the description immediately delimits it against siblings: "other tools never start a closed slot." An agent can distinguish this from browser_tab_new or browser_status without touching 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?

Explicit when-to-use (only when the user explicitly asks), when-not (nothing else starts a closed slot), and how to choose between alternatives (headless vs windowed, slot vs slots vs count, ask first if unstated). It even routes follow-up work to subagents, 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?

No annotations are provided, so the description carries the full burden. It does disclose one meaningful trait — that the call blocks until the body loads — but says nothing about timeout behavior, what happens on DNS/HTTP failure, or whether navigation state is preserved. That is useful but incomplete disclosure for a no-annotation tool.

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

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

A single front-loaded sentence with zero filler; the verb and the blocking behavior are both stated up front. It is arguably terse given the tool's importance, but 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?

With no annotations and no output schema, the description should cover failure and timing semantics; it mentions loading but not timeouts or error results. The schema fully covers parameters, so the remaining gap is narrow, but the behavioral envelope is only partially described.

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 seven parameters (including the tab/slot disambiguation and the read enum) are thoroughly documented in the schema itself. The description adds no parameter-level meaning beyond what the schema already states, so the baseline 3 applies.

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

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

The description pairs a specific verb ("Navigates") with a specific resource ("the tab to a URL") and adds the observable outcome ("waits for the body to load"). It is clearly distinguishable from browser_back/forward/reload by naming navigation-to-URL, but it never explicitly contrasts with those siblings.

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

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

There is no guidance on when to use this versus browser_back, browser_forward, browser_reload, or browser_tab_select, nor any stated prerequisite (e.g. that a slot must be launched and a tab selected first). Usage is only implied by the verb.

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 and does disclose real behavioral traits: a bounded ring buffer of the latest 500 requests and newest-at-bottom ordering. It does not cover permissions, whether recording is always active, or rate/refresh behavior, so it is not fully 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 compact sentences, front-loaded with what the tool returns and its retention limit before moving to filtering and the detail-tool handoff. Every sentence contributes; only the parenthetical type list is mildly expendable.

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

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

With no output schema, the description usefully describes the result shape (list, newest at bottom, 500-record cap) and how to drill into a specific entry. Missing only minor operational context such as whether the list refreshes live or requires re-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 description coverage is 100% (filter, type, failed, tab, slot, limit all documented inline), so the baseline is 3. The description's mentions of filter ('URL part'), type categories, and failed ('failures only') largely restate the schema rather than adding new semantics.

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 ('Tab network request list') plus concrete scope ('latest 500 since CDPM first attached to the tab'). It also explicitly routes the agent to the sibling browser_network_detail for details, so it is distinguishable from its closest neighbor 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?

Explains how to narrow results with filter/type/failed and names the alternative (browser_network_detail) with the condition that selects it ('For details pass the n-number'). It stops short of explicit when-not-to-use guidance, but the routing 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 the full behavioral burden. It does disclose that the response body may be truncated ('start of it, if text'), which is genuine value not derivable from the schema, but it says nothing about permission requirements, binary/non-text payloads, or how multiSlot affects retrieval.

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 tight sentence plus one clarifying clause, with the return content front-loaded and the id provenance appended. No wasted words.

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

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

No output schema or annotations exist, so the description must define the result, and it does list the three payload sections plus the truncation caveat. It stops short of covering tab/slot targeting behavior or binary responses, but for a single-request inspection tool this is nearly 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 description coverage is 100% and all six parameters are documented in the schema, so the baseline is 3. The description only adds the cross-tool linkage for 'id'; it says nothing extra about tab, slot, body default, or multiSlot beyond what the schema already states.

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 (shows) and precise resource (one request's headers, sent data, response body), and distinguishes itself from sibling browser_network by explaining that the id comes from that tool. An agent can tell exactly what this returns versus the network list 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?

The clause 'id is the n-number from browser_network' implicitly routes the agent to call browser_network first, which is clear sequencing context. No explicit when-not or alternative for inspecting requests, but the workflow is unambiguous.

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

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

With no annotations, the description must carry the behavioral burden; it usefully discloses the default save location (Downloads), the naming convention (page title), and that the screen/window is unaffected. It omits other operationally important behavior: whether a save/download dialog can appear, whether the call waits for completion, and overwrite handling for an existing file.

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, the default-path fallback, and the non-disruptive guarantee. Front-loaded and every sentence carries information an agent needs.

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

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

For a five-parameter save tool with only one required parameter and no output schema, the description covers the essential behavior and the most likely agent question (where did the file go). It stops short of describing the return value or failure modes, a minor gap rather than a blocking one.

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 real value by defining the semantics of an omitted path (fall back to Downloads, name after the page title) — behavior the schema's path description does not state. The tab/agent/multiSlot parameters are left entirely to the schema, which is acceptable given full coverage.

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

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

States a specific verb and resource ("Saves the page as a PDF") with concrete examples (receipts, articles) that pin down the artifact type. This cleanly separates it from the image-producing browser_screenshot and the wait-only browser_download_wait sibling without needing 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 implies when to use it (when you want a durable PDF of the current page) and explains the path-omitted case, but it never explicitly contrasts with browser_screenshot or browser_download_wait, nor states prerequisites. Usage is inferable rather than directed.

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

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

No annotations, so the description carries the burden well: discloses that bubbles aren't in snapshot/screenshot, page tools can't click them, page often blocks, header warns when open, and platform limit (Windows, windowed slots). Does not cover return format or error behavior, hence not a 5.

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

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

Front-loaded with purpose, then mode behavior and constraints. Dense but nearly all sentences earn their place; the example button names are slightly verbose but illustrate localization.

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-schema tool, the description is nearly complete: what it does, why page tools fail, when header warns, platform limits. Return value of the list mode is only implied rather than stated.

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% and parameter descriptions are already rich (slot parsing, site filtering, button exact name). Description reinforces button semantics but adds little beyond schema 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 specific verbs (lists/answers) and a precise resource (Chrome permission bubbles), with a concrete example of bubble text. Clearly distinguishes from browser_dialog and page-level tools by explaining bubbles are browser UI.

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 both modes (without button = list, with button = press) and notes the page may wait until answered, plus header warning. Lacks explicit exclusion vs browser_dialog, but mode selection is well-defined.

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 discloses that the key goes to the focused element, but says nothing about side effects (form submission, navigation triggers), focus requirements, or failure modes when no element is focused — a meaningful gap for a browser-mutating tool.

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

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

Two short sentences, front-loaded with the action and followed by examples. Every element earns its place, though the example list is somewhat long relative to the small amount of substantive information conveyed.

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

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

For a 7-parameter tool in a busy multi-slot browser ecosystem with no output schema and no annotations, the description covers only the core action. Slot/tab targeting, the read-after-action behavior, and multi-slot coordination are left entirely to the schema, which is adequate but leaves behavioral context 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 per the baseline this is a 3. The description's key examples largely duplicate what the schema's key field already documents ("Control+A"), adding little beyond the structured fields.

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

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

States a specific verb+resource (press a key on the focused element) and gives concrete key examples like Enter, Control+A, Shift+Tab, which distinguishes it from text-entry siblings such as browser_type or browser_fill. It does not, however, explicitly name those siblings or state what makes it different.

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 comparison to browser_type/browser_fill, and no statement of prerequisites such as the element needing focus or a tab being active. The examples imply keyboard interaction but don't route the agent among alternatives.

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 the two traits that matter most: the destructive side effect ("unsaved user input on the page is lost") and the cache-bypass behavior of ignore_cache. It does not say whether the call waits for the page load to finish, which affects a subsequent snapshot.

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, the core action front-loaded, then the flag, then the risk. Nothing is padded and each sentence contributes.

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 action tool with no annotations and no output schema, the definition covers purpose, the cache flag, and the data-loss risk, with the fully documented schema handling targeting parameters. The one meaningful gap is whether reload blocks until load completes, which an agent needs to know before chaining reads.

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 seven parameters including ignore_cache. The description only restates ignore_cache=true, adding no format, default, or interpretation detail 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?

"Reloads the page" is a specific verb+resource, and "same as Chrome reload" anchors the semantics against a well-known browser action. It is clearly distinct from browser_navigate/back/forward in intent, though it never names a sibling to route against.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternative, so an agent comparing reload against navigate or back has nothing to select on. The destructive caution implies care but is not framed as a usage rule.

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 and does so well: it discloses that background tabs are captured without switching, that window size and viewport are never changed, and that full-page capture is impossible. It doesn't mention permissions or error behavior, leaving some 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?

Two dense sentences, front-loaded with the core capability and then the constraint and fallbacks. Every clause earns its place with no repetition.

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 screenshot tool with no output schema and full schema coverage, the description is complete enough: it covers what is captured, the background-tab behavior, and the full-page limitation. It could mention the return format (image vs. path) but the schema covers parameters.

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, including tab, slot, agent, and multiSlot. The description adds no parameter-specific meaning beyond the schema, so baseline 3 is correct.

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 (captures) and resource (visible area of the tab as PNG), and implicitly distinguishes itself from browser_pdf and browser_snapshot by naming PNG and the visible viewport. An agent can tell exactly what this produces.

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

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

Explicitly says full-page capture is unsupported and routes to alternatives (scroll then capture, or use snapshot/text), which is clear when-not guidance. It doesn't name browser_pdf as the full-page alternative, so the routing is slightly incomplete.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one genuinely useful trait — that the tool reports the actual resulting position (not just the requested delta) — but says nothing about permissions, whether the scroll animates/blocks, or failure behavior when a ref is stale.

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

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

One sentence, front-loaded with the action and the two modes, then the modifiers. No wasted words and nothing important buried.

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

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

With no output schema, the note that it reports the resulting position is important and present. The description adequately covers the tool-specific parameters; it could say a bit more about return shape or ref failure, but for a simple scroll action it is close to complete.

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

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

The schema leaves dy and ref entirely undocumented while covering the shared params (slot, tab, agent, summary, read) at ~75%. The description fills exactly that gap by defining dy's sign convention and default and explaining what ref does, which is real value 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 ('Scrolls') plus the two resources/modes it operates on: a ref element into view, or by dy pixels. No sibling tool in the list does scrolling, so differentiation is implicit and unambiguous.

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

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

Gives the mechanics of dy (positive = down, negative = up, default 600) but never says when to prefer ref-scrolling over dy-scrolling, or when scroll is needed versus browser_wait/snapshot. Usage is implied rather than guided.

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 interaction mechanism (focuses the dropdown, drives it with arrow keys on Windows/Linux and first-letter typing on macOS), that real events reach the page, and states the failure behavior ('If nothing matches, lists the available options'). It stops short of runtime traits such as timeouts, waiting behavior, or whether a selection triggers navigation.

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

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

Three sentences, front-loaded with the action, then the mechanism, then the failure mode — nothing is padding. The platform-specific keystroke parenthetical is slightly more detail than an agent needs to select the tool, which keeps it just under a 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 tool with 8 parameters, 3 required, and no output schema, the description covers the core action, its side effects on the page, and the error/no-match path. The auxiliary parameters (slot, tab, read, agent, summary, multiSlot) rely entirely on the schema to explain themselves, so the description is adequate rather than fully complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema's bare 'Option value or text' by adding 'partial match OK' and clarifying that either the value or the visible text is accepted, which is real semantic value for the required option parameter. The other seven parameters 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 concrete verb and resource — 'Picks an option in a <select> dropdown' — and even specifies the matching modes (value or visible text, partial match). This is unambiguous on its own, but it never names the sibling it is most confusable with (browser_tab_select) to make the disambiguation explicit.

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 purpose statement (use this to choose a value inside a select element rather than clicking), and the description hints that this is preferable because 'no list popup opens'. However, it never states when NOT to use it (e.g. custom non-native dropdowns) nor names alternatives such as browser_click or browser_fill.

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 well: it discloses the read model, ref-stability across pages, ref invalidation on page change, and the page-1-only default. It does not discuss auth, rate limits, or failure behavior, but for a read tool that is a minor gap.

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

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

Four tight sentences with no filler, front-loaded with what the tool returns, then the ref/pagination mechanics, then the critical 're-snapshot' warning. Every sentence carries information an agent needs to call it correctly.

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 tool with no output schema and no annotations, the description adequately covers output format, ref lifecycle, and pagination. The ancillary params (slot, agent, multiSlot) are left to the schema, which is reasonable at 100% coverage, but the description could have reiterated the multi-tab warning surfaced there.

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 8 params, setting a baseline of 3. The description adds real value beyond it by explaining the pagination contract (only page 1 shown, refs stay stable across pages) and the parent-context behavior of find=, which the schema does not fully convey.

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,' with concrete output detail (refs like [e12]). This is clearly distinct from a plain text extractor, but the description never names a sibling tool, so it stops short of explicit 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?

Gives real operational guidance: how to continue long pages (page=2), how to narrow with find= and ref=, and the key rule 're-snapshot before acting' once refs change. It never states when NOT to use this versus browser_text or browser_screenshot, so it lacks explicit alternatives.

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. "Shows running Chrome slots" implies a non-mutating read and it discloses the returned fields, but it says nothing about truncation, cost, permissions, or whether output scales with running slots. Adequate but thin for a zero-annotation tool.

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

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

Two tight sentences, no filler. The scope statement comes first and the optional-narrowing hint follows, so the agent reads the most important information first.

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 status tool with two optional parameters and no output schema, the description covers the return shape reasonably well (tabs, opener, last action, summary). What it lacks is any note on cost or output size when many slots are running, and there are no annotations to fall back on.

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 slot parameter already documents the 1-30 range and the port-subtraction rule. The description adds only the behavioral effect of passing slot (scope narrows to one slot) and says nothing about the agent parameter, so it matches the 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 ("Shows") and resource ("running Chrome slots (1-30)") plus the payload returned: tabs, opener, last action, one-line summary. That inventory partially distinguishes it from browser_tabs and slot_inbox, but no sibling is named explicitly, so the agent must infer the split.

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" gives a narrowing hint for the optional parameter, which is genuinely useful. However, there is no statement of when to prefer this over browser_tabs, slot_inbox, or browser_network, and no exclusions or prerequisites.

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 discloses almost nothing: it does not say whether the slot is released, whether the last remaining tab can be closed, what happens if the tab id is invalid, or whether the user's page state is destroyed. "Closes" implies mutation but no consequences are described.

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

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

Two short sentences with the action front-loaded and no padding. The second sentence is redundant with the schema's required list, which is the only minor waste.

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?

A destructive 3-parameter tool with no annotations, no output schema, and a one-line description is under-specified. An agent gets no signal about what state is affected after a close or how the slot parameter interacts with it.

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

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

Schema description coverage is 100%, so the schema already documents tab, slot, and agent in detail (including slot/port normalization). The description adds nothing beyond restating that tab is required, which is already in the schema's required list, 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?

"Closes a tab" gives a specific verb and resource, so the agent knows the operation. It does not, however, distinguish this from the sibling browser_close (close the browser) or browser_tab_select, leaving the tab-vs-browser scope 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 description offers no when-to-use or when-not-to-use guidance and names no alternative among the many tab/session siblings. "tab is required" is a parameter restatement, not usage context.

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 useful behaviors: the tool returns the new tab's ID, and tabs are per-agent within a shared slot to avoid interference. It omits whether existing tabs are affected, whether this creates a focused/active tab, and any slot-state assumptions.

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 action and return value front-loaded and the multi-agent guidance second. No filler or redundancy.

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

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

For a simple creation tool with full schema coverage and no output schema, the description covers the essentials: what it does, its return, and the shared-slot isolation concern. Minor gaps remain around tab focus/activation semantics and interaction with other tab tools.

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 documented with format hints. The description only references the slot indirectly and adds no syntax or constraint detail beyond the schema, so the 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?

The description names a specific verb+resource ("Opens a new tab") and states the return value (tab ID), which cleanly separates it from siblings like browser_tab_select or browser_launch. It does not explicitly name an alternative, but the action is unambiguous.

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

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

It gives a concrete when-to-use condition: "When agents share a slot, open your own tab and work only by its ID to avoid mixing." That is real usage context, though it stops short of naming sibling tools (browser_tabs, browser_tab_select) or stating when not to open a new tab.

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

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

No annotations are supplied, so the description carries the full burden. It adds real value by disclosing the return roster, the meaning of the '·front' marker, and the rule that per-tab summaries are only refreshed by summary-bearing actions — but it never states the tool is read-only/non-mutating or whether it requires an active browser session.

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

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

Front-loaded with the return-field roster and kept to two terse sentences with no filler. The '·front' clarification is embedded rather than given its own sentence, which is efficient though slightly dense.

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

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

With no output schema, this description effectively serves as the return-value documentation by naming every field, including the non-obvious '·front' marker. It is complete enough for a read-only listing call, with the only gap being the absent read-only/statefulness disclosure that annotations would normally cover.

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 slot description already explains the 1-30 range, the string-coercion cases, and the port-offset trick, so the schema does the heavy lifting. The description's mention of 'Slot tab list' confirms slot scoping but adds nothing the schema lacks; 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 enumerates exactly what the tool returns (number, ID, title, URL, opener, last action, per-tab summary) and is scoped to a 'slot tab list', so an agent can tell it apart from browser_tab_select, browser_tab_new, and browser_tab_close, which are mutation/selection siblings. It never states the verb 'lists' outright, but the noun phrase 'tab list' plus the field roster makes the read purpose unambiguous.

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

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

There is no when-to-use guidance and no routing to alternatives; the agent must infer that this is the discovery step before tab_select or tab_close. The clause about the per-tab summary being 'updated only by actions with summary' is behavioral context, not usage 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 transparency burden and discloses the key behavioral trait: it 'changes what the user sees,' and that background tabs remain read/operable/capturable without it. It does not cover failure modes (e.g., invalid tab) or that state is otherwise unaffected, so it falls short of a 5.

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

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

Two short sentences, front-loaded with the action and immediately followed by the usage constraint and the reason behind it. Every clause earns its place; 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 simple UI-visibility operation with no output schema and fully documented parameters, the description is nearly complete. The main omission is any note about behavior on an invalid/missing tab, which would round it out.

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 slot, tab, and agent are already fully documented (including the port arithmetic and subagent naming rule). The description adds no parameter-level meaning, 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+resource ('Brings a tab to the front of its Chrome window') with the scope (its window) made explicit. The parenthetical distinguishes it from read/operate tools like browser_snapshot or browser_text, so an agent can tell when this visibility-only action is warranted versus those siblings.

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

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

Explicitly states when to use ('only when the user wants it') and when not ('no need to bring them forward to work'). This is a rare case of clear when/when-not guidance that prevents an agent from pointlessly stealing user focus.

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 implies a read-only operation and discloses extraction behavior (main/article preference, ref narrowing) and long-output handling, but says nothing about failure modes, auth, or performance characteristics.

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 front-loaded sentences with no filler; the core purpose leads and routing hints follow. Telegraphed style costs it a point on readability but wastes nothing.

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 does describe what comes back (body text, main/article) and mentions pagination for long output. For a single-required-parameter read tool with fully documented schema, this covers what an agent needs.

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 modestly adds value: 'With ref, only that element's text' restates the schema, while 'Use page for long text' gives the rationale for the page parameter.

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

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

States a specific verb and resource ('Reads the page body text') with a scoping qualifier (main/article if present) and a ref-based narrowing. It is clearly distinguished from the sibling browser_snapshot, which it explicitly names as the heavier alternative.

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 (snapshot) and the condition that selects this tool ('articles/documents'), plus a follow-up routing hint for long output ('Use page'). Lacks explicit when-not-to-use guidance, but the context is clear enough to choose 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 does substantial work: it discloses that real key events are dispatched per character, that the resulting value is verified with mismatch reporting, that fast mode skips key events, and that date/time inputs bypass events entirely with isTrusted=false on the change event. It stops short of covering permissions, failure modes, or what a mismatch report looks like.

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

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

A single dense paragraph that front-loads the core behavior and then attaches the flag semantics in order of likely importance. Every clause conveys information; the date/time aside is the only slightly tangential piece and it earns its place by flagging the isTrusted caveat.

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 tool with no annotations and no output schema, the description covers the action-defining flags and states that the value is verified afterward, which partially substitutes for a missing output schema. It omits the shared session parameters (slot, tab, agent, read, multiSlot), though those are documented in the schema and shared across siblings.

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 a baseline of 3 applies, but the description adds real meaning beyond the one-line schema entries for clear ('clears existing content'), submit ('presses Enter after'), and fast ('inserts very long text at once without key events'). The remaining parameters (slot, tab, agent, read, summary, multiSlot) get no description-level treatment, which caps this below 5.

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

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

States a specific verb and resource ('Types text into a ref element') and goes further by describing the mechanism (real key events per character). However, it never distinguishes itself from the sibling browser_fill, which likely also writes text into an element, leaving the agent to infer the difference.

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

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

Usage is implied through flag semantics (fast=true for very long text, date/time inputs get direct value setting), but there is no explicit when-to-use guidance or any statement of when to prefer browser_fill, browser_press_key, or browser_select instead. The agent must infer selection criteria.

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

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

No annotations are provided, so the description carries the full burden, and it discharges much of it: it discloses that no OS picker appears, that CDPM intercepts the picker, and that the site receives the same events as a human file pick. It does not cover failure modes (e.g. invalid path, hidden input, upload rejection), 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?

Three sentences, zero filler, and the core behavior is front-loaded before the ref guidance. The final sentence about event fidelity is short and earns its place by explaining the observable effect of the call.

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 one genuinely non-obvious flow (click-then-upload-without-ref) and sets expectations about user-visible behavior. It leaves error handling and any preconditions about the target input unaddressed, but the schema already documents the remaining parameters.

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 each parameter is documented in-schema, so the baseline is 3. The description reinforces the ref/no-ref distinction, but the schema already states 'Omit to use the file picker just opened by a click', so it adds little beyond structured data.

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 ('Puts files into a file input') and immediately clarifies the mechanism ('no OS file picker shown to the user'), which separates it from browser_click and browser_fill. An agent can tell exactly what this tool does without opening the schema.

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

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

Gives the two explicit invocation paths: pass ref for a real <input type=file> or its label, or click a custom 'attach' button with browser_click first and then call without ref. This is a complete when/how decision tree with the alternative tool named.

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

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

With no annotations, the description carries the full burden and does well: it discloses read-only behavior ('Only reads, never touches the page, so the user's input is not lost'), that it returns as soon as the condition is met or a message arrives, and that response mode returns the body. It doesn't detail failure/timeout behavior beyond the schema, 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 mode enumeration, then usage guidance, then constraints; every clause adds value. However the sentences are long and dense, cramming several ideas (SPA advice, login detection, message interruption) into run-ons, slightly reducing 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 complex 12-param tool with no output schema, the description covers behavior, mode semantics, and safety adequately. Return-value detail is partial (fully described only for response mode), but the guidance an agent needs to call it correctly is largely present.

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

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

Schema coverage is 100%, so the schema already documents all 12 params and baseline is 3. The description adds interpretation beyond the schema: the response-mode timing nuance ('searches from this agent's last action on that tab, so responses that arrived during the click are caught') and concrete login-detection examples, which raise it above 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 (waits) and enumerates every condition mode (text/gone/url/enabled/response/network_idle/seconds) that the tool handles. It explicitly routes to a sibling ('to wait for other agents use slot_inbox wait'), so an agent can distinguish it from other browser 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?

Gives concrete when-to-use per mode plus the SPA recommendation to use response="/api/search" after a click instead of reading the page, and the login-detection pattern (url, gone="Password"). It also states when NOT to use plain seconds and points to the alternative. Exclusions and alternatives are explicit.

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

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

With no annotations and no output schema, the description carries the full burden and does add real behavioral detail: the deduplication rule ('messages already delivered in another tool's header are not unread') and the fallback when nothing is new ('recently received ones are noted for reference'). It stops short of describing return shape or auth/identity implications of the agent parameter.

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

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

Three sentences, front-loaded with what the tool returns before the wait semantics and the unread-definition caveat. Dense but each sentence carries information; minor awkwardness in the final clause.

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

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

For a 3-parameter messaging tool with no annotations and no output schema, the description covers the unread/wait semantics but never says what the returned messages actually look like or who sent them. It is adequate to invoke correctly but leaves the response shape to be discovered.

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, wait, and agent in detail — including the wait anti-polling rationale. The description's mention of wait largely restates the schema, adding no syntax or format beyond it; 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 your unread messages'), making it immediately clear this is the receive side of the inter-agent messaging pair with slot_send. It does not explicitly name slot_send as the counterpart, so sibling differentiation relies on inference from the resource noun.

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 the distinguishing parameter: use wait for real-time conversation, letting the agent block instead of polling. There are no explicit exclusions or named alternatives, but no alternative receive tool exists in the sibling list, so the missing 'when not to use' costs little.

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: action tools are refused, an in-progress browser_wait stops immediately, an action already dispatched to Chrome completes, reading still works, and the effect propagates to agents in other Claude sessions. This is exactly the async/concurrency behavior an agent needs before calling.

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 carrying distinct information (trigger, scope of refusal, in-flight behavior, read access, cross-session effect, all flag). The usage constraint is front-loaded with zero filler.

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

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

No annotations and no output schema, yet the description covers the mutation's blast radius, concurrency semantics, and cross-session scope thoroughly. It could state what the tool returns or how to confirm the slot is paused, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds real meaning for one parameter ("all=true pauses every running slot"), but says nothing about slot, slots, or agent 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 (pause a browser slot) and makes the inverse relation to the sibling slot_resume obvious. An agent can distinguish it from every browser_* action tool and from slot_resume without opening a schema.

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

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

Gives an explicit trigger condition with a concrete example ("pause 3") and a strong when-not rule ("agents never call it on their own"). It does not name the complementary tool (slot_resume) as the alternative, so it stops just 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 full burden and does disclose meaningful behavior: unpausing, messaging every agent on the slot, and that agents re-read the page and continue. It stops short of covering state preconditions (e.g. error when the slot isn't paused) or permissions, 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?

Three tight sentences with zero waste, and the critical usage constraint is front-loaded ahead of the behavioral and bulk-mode details.

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

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

For a 4-param, all-optional tool with no annotations and no output schema, the description supplies the usage rule, the observable effect, and the bulk-mode behavior. It omits only edge-case behavior (resuming an already-active slot, failure modes), 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 description coverage is 100%, so slot/slots/agent are already fully documented in the schema (including the port-subtraction hint). The description only adds a semantic gloss for 'all=true resumes every paused slot,' which is close to restating the schema's 'All paused slots.' Baseline 3 applies 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: 'Unpauses and messages every agent on the slot to wake it.' It clearly contrasts with the sibling slot_pause by describing the inverse operation and the wake-up effect, 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?

Explicitly names the trigger ('only when the user says to resume, e.g. continue 3') and an exclusion ('the agent owning a paused slot never calls it on its own'). It also routes the bulk case via 'all=true resumes every paused slot.' Both when-to-use and when-not-to-use are covered.

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 it does so well for a messaging tool: it discloses that recipients get messages instantly if waiting in slot_inbox, otherwise via their next tool-result header, and that a running browser_wait is interrupted immediately. It omits error/failure behavior and any rate or size limits, but the core delivery semantics are unusually well specified.

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

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

The purpose is front-loaded in the first sentence, and the remaining clauses each carry distinct information (targeting, broadcast, delivery timing, usage trigger). It is a dense single paragraph with no filler, though the parenthetical interruptions make it slightly harder to scan than a clean bulleted structure would be.

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

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

With no annotations and no output schema, the description must stand alone, and it covers purpose, targeting, delivery timing, and a usage trigger. Missing pieces are minor: what happens on an invalid slot, whether text is persisted or echoed, and confirmation of successful send.

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 genuine meaning beyond it: 'slot = the slot the recipient owns (to reach another slot's agent, use that slot number)' and 'Omit to to send to everyone on that slot' clarify the slot and to parameters respectively. The agent parameter is left to the schema, which already documents it as the sender's display name.

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

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

The opening sentence states a specific verb and resource: 'Sends a message to other agents (real-time collaboration).' The follow-up clarifies the routing model (slot targeting vs. broadcast). It references slot_inbox only indirectly via delivery behavior, so it does not fully contrast the send/receive sibling pair, but the purpose is unambiguous.

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

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

'When you finish a step, notify waiting agents right away' gives a concrete usage trigger, and 'Omit to to send to everyone on that slot' clarifies the broadcast case. However, there is no explicit when-not-to-use guidance or a named alternative for reading messages (slot_inbox is mentioned only in passing as a delivery target).

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