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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds substantive context beyond that: it discloses the guardrails the server was launched with (read-only mode, origin rules, audit log) and the idle/activity gate, which are behavioral facts an agent needs and cannot derive from annotations.

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

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

A single sentence, front-loaded with "Report Arc state" so the purpose lands immediately, followed by a dense but relevant enumeration of the reported fields. The list is long, but each item corresponds to a distinct thing an agent would need to know, so little 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?

There is no output schema, so the description must carry the return-value burden, and it does so thoroughly by naming every reported field. For a zero-parameter, read-only status tool this leaves nothing material ambiguous.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description nonetheless explains what a call with no tab_id resolves to, which is a useful semantic note even without parameters.

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 (Report) and resource (Arc state) and enumerates the concrete dimensions returned: version, frontmost status, owned tabs, agent window details, idle time, activity gate, agent space, tab_id resolution, leftover tabs, and server guardrails. This clearly separates it from diagnostic siblings like cdp_status or snapshot.

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 it first" gives an explicit ordering directive, which is real usage guidance. It does not, however, name an alternative or state when not to call it, so it falls short of a full when/when-not pairing.

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

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

Annotations already declare it destructive, non-idempotent and open-world, so the bar is lower, yet the description still adds real behavior: execution stops at the first failure unless continue_on_error is set, and a 60000-character cumulative cap causes early termination with a truncated report. It does not cover ordering hazards or whether a partially executed batch can be resumed, 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?

Three sentences, all load-bearing, with the core definition front-loaded and the failure/truncation caveats following. It is dense without being padded, though the opening could name itself as a sequencer more tightly.

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 nested, write-capable orchestrator with no output schema, the description supplies the essentials an agent needs: shared tab state, fail-fast default, and the truncation behavior of the returned results. A little more on what the truncated response contains would make it 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 steps, args, tab_id and continue_on_error are already documented; the description only restates continue_on_error's stop/keep-going semantics. The mention of max_chars is arguably a hint about step arguments rather than this tool's own parameters, so it adds limited if any new meaning. 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 ('Run several tools in order in one call') and immediately frames itself as an orchestrator that threads one tab through steps, which clearly separates it from the single-action siblings like click, fill, or type. An agent can tell what it is without opening the schema.

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

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

Gives an explicit use case with a concrete sequence ('fill, fill, click, wait') and the goal ('cut round trips'), plus a routing rule for read-heavy work ('split a read-heavy sequence across calls'). It lacks an explicit statement of when NOT to batch (e.g., for a single step), but the 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?

Goes well beyond the annotations: discloses the 1000-event retention cap, the dropped counter when events are evicted, the ok=false failure mode versus a misleading empty list, and an explicit prompt-injection warning that page-sourced event text is data, not instructions. The clear semantics ('only the events returned are removed, so a capped read loses nothing') is the kind of side-effect detail annotations cannot express; note the mild tension with destructiveHint=false/idempotentHint=true, but the description resolves it by stating the exact scope of removal.

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 sentences, each carrying distinct payload (purpose/order, retention limit, failure mode, injection safety, clear semantics), with the core purpose front-loaded and no filler or restatement of the name.

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

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

With no output schema, the description carries the burden of return semantics and mostly succeeds — ordering, eviction/cap behavior, dropped reporting, and the ok=false shape. The only gap is the per-event object shape (fields beyond 'text'), which the agent must infer.

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 for `clear` beyond the schema's terse wording — it clarifies that only the returned window is removed and that a capped read therefore loses nothing. It does not add much for max/kind/tab_id, which is acceptable since those are fully documented in the schema.

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

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

Opens with a specific verb+resource ('Return what capture_start recorded on a tab') and immediately scopes it with ordering ('oldest first'). It clearly positions itself as the read side of the capture_start pair among siblings, so an agent can tell it apart from console_messages, network_requests, or get_page_content without opening the schema.

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

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

Gives clear context for invocation (it reads what a running recorder captured) and an explicit failure condition ('no recorder is running on the current page'), which tells the agent when not to expect data. However, it never routes between alternatives like console_messages/network_requests or says when the capture pipeline is preferable to those live-fetch tools.

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

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

Annotations cover readOnlyHint=false and idempotentHint=true, but the description adds rich behavioral context the annotations cannot: recorder lifetime tied to page navigation, CSP blocking behavior with ok false, the isolated-world/JS-world injection rationale, and the data redaction model (no bodies/headers, queries dropped unless include_query, fragments dropped).

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 primary purpose, which is good. However, the description is a single dense run-on paragraph mixing scope, redaction rules, failure modes, and frame limitations, making it harder to scan than necessary. Length is justified by complexity but structure could be improved with separation.

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

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

Given the tool's complexity (session lifetime, CSP failure modes, redaction model, capture surface), the description covers all essential behavioral details an agent needs. No output schema exists, so it correctly points to capture_read for results and network_entries as an alternative for CSP-blocked pages.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces include_query's effect but does not add syntax or new semantics beyond what the schema provides. 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 (Start recording) and enumerates the exact capture surfaces: console output, uncaught errors, unhandled promise rejections, fetch and XHR calls. It also explicitly ties itself to the sibling capture_read as the consumer, and distinguishes from network_entries which still works under CSP block.

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 call it again after navigation/reload, mentions the fallback behavior for tab_id vs open_url, and notes what is NOT covered (iframes, workers, WebSockets, sendBeacon, pre-call requests). Gives clear when-to-use and when-not-covered conditions.

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

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

Annotations already cover the safe-read profile, but the description adds substantial behavior beyond them: the default port and env-var controls, the failure mode (ok false plus setup steps when nothing answers), the fact that other tools are unaffected, and that it re-probes on every call so relaunches are detected. That is exactly the extra context annotations cannot convey.

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

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

Five tight sentences, front-loaded with what is reported before moving to defaults, the Arc launch prerequisite, failure behavior, and probe freshness. Each sentence carries distinct, load-bearing information with no filler.

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

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

There is no output schema, yet the description compensates by describing the returned fields (port, browser, target count, security warning) and the failure shape (ok false with setup steps). For a zero-parameter diagnostic tool this is complete enough to call correctly without any structured return definition.

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

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

The tool takes zero parameters, which is the baseline-4 case. The description correctly describes configuration via environment variables rather than parameters, so there is nothing further for it to clarify on this dimension.

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: it reports whether the CDP engine is usable and enumerates exactly what it returns (port, answering browser, page target count, security warning). It also distinguishes itself from the rest of the toolset by noting that every non-CDP tool is unaffected, so an agent can tell it apart from siblings like arc_status or get_current_tab.

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

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

Explains the operating conditions well: on by default, probes 127.0.0.1:9222, ARC_MCP_CDP_PORT overrides, ARC_MCP_CDP=0 disables, and Arc only serves the port when launched with --remote-debugging-port. It never explicitly says when to call it versus an alternative (e.g., as a preflight before CDP-dependent tools), so guidance is clear but not fully prescriptive.

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?

Far beyond the annotations: modal backdrop/overlay coverage, disabled-control failure, pointer-events:none, stale ref re-resolution vs. failure, and post-click settle behavior are all disclosed. This is unusually rich for a click tool.

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

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

Front-loads the core purpose in the first sentence and keeps each subsequent sentence on one topic, though the single long paragraph packs many distinct behaviors and could be split for scanability.

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

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

For a 6-param, annotations-only tool with no output schema, the description covers matching semantics, tab-scoping, post-click settling, and failure modes. An agent has everything it needs to invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value: it explains that a short text label also matches longer ones (substring semantics), which the nth/exact parameter descriptions only imply, and provides the 'check matches then pass exact' workflow.

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 ('click') and resource ('an element'), then enumerates the accepted selector syntaxes, distinguishing it from trusted_click and hover in the sibling list.

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

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

Gives clear context for when to pass tab_id, when to follow with wait_for_load, and when to pass exact (matches > 1). Does not explicitly contrast against trusted_click or its other siblings, which is the one miss.

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

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

Annotations already mark this destructive, and the description adds significant scoping context: user tabs are untouched, stale tabs from dead sessions are excluded by default, and live agent tabs are never affected. This clearly defines the boundaries of the destructive action and prevents accidental data loss beyond the agent's own tabs.

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

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

Two sentences with no filler. The main behavior is front-loaded, and the stale-tab exception is placed immediately after. Every sentence earns its place and directly informs invocation.

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 single-optional-parameter cleanup tool, the description covers the action, the ownership boundary, the stale-tab behavior, and points to arc_status for relevant status. No output schema exists, but nothing needed to call the tool 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?

The schema already describes include_stale fully, including its default value and effect. The description mentions include_stale only in passing, matching the schema without adding new meaning. With 100% schema coverage, 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 uses a specific verb and resource: 'Close every tab this agent opened.' It precisely scopes the tool to tabs owned by this agent and distinguishes it from close_tab and user-tab operations. The mention of 'leaving the user's tabs alone' removes ambiguity about which tabs are affected.

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

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

The description makes the intended cleanup use clear: close all agent-opened tabs, not user tabs. It also gives explicit guidance for include_stale, noting stale tabs are left alone unless the flag is set. It does not explicitly mention sibling alternatives like close_tab, so it stops short of full alternative routing.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds genuinely new behavioral facts: the call is refused outright if the agent has not opened a tab, the user's tab is never a fallback target, closing is irreversible, and tab ids are not reused. These are exactly the failure modes an agent needs before invoking a destructive 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?

Four short sentences, each load-bearing: what it does, the implicit-tab rule and its refusal condition, the explicit-id path, and the irreversibility/id-reuse facts, closing with the preferred alternative. Front-loaded and zero filler.

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

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

For a single-optional-parameter destructive tool with no output schema, the description covers the implicit-vs-explicit targeting rule, the safety guarantee about the user's tab, irreversibility, and the sibling alternative. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the schema description already explains that omitting tab_id uses the agent's current tab. The description reinforces this and adds the 'pass this or call open_url first' guidance, but most of the parameter meaning is already carried by 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?

Specific verb (close) plus resource (one tab), and it immediately distinguishes the two modes of operation: implicit own-tab vs. explicit tab_id. An agent can differentiate this from siblings like close_own_tabs and switch_to_tab without reading 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?

States exactly when to omit tab_id, when to pass an explicit id from list_tabs, and names the preferred alternative (close_own_tabs) for cleanup with the condition that selects it. Exclusions are explicit: it will never close the user's visible 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?

Annotations only supply the safe-read profile, but the description discloses the real behavioral traps: capture begins only when a CDP tool first touches the tab, there is no history to read back, and pre-capture messages are unrecoverable. It also documents the caller's prerequisite (DevTools engine) and the ordering of results ('Newest last'), which the annotations cannot convey.

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

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

Five tight sentences, front-loaded with purpose and result content before the capture and ordering caveats. Every sentence carries distinct information (what is captured, ordering, prerequisite, capture window, call-order advice) with no filler.

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

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

With no output schema, the description must characterize the returned data, and it does: entry kinds plus 'Newest last'. What remains thin is the shape of an individual entry (fields such as timestamp, source, stack) and behavior under the clear flag, though the schema covers the latter.

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

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

With 100% schema description coverage the schema already explains all four parameters, including the tab_id fallback rule and the clear/level/limit semantics. The description adds the ordering context ('Newest last') that helps interpret limit, but nothing beyond that; baseline 3 applies.

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

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

Specific verb+resource ('Read the console output of a tab') with an explicit enumeration of what counts as console output: console.log and friends, uncaught exceptions, and browser messages such as blocked requests and CSP violations. This clearly separates it from the sibling network_requests/network_entries tools.

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

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

Gives a concrete when-to-use rule ('Call this tool ... before the action you want to observe') and names the alternative enabling path (cdp_status then any CDP tool). It does not state exclusions versus siblings (e.g. when to prefer network_requests for network data), so it falls just short of a 5.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false, openWorld=true. The description adds real value beyond that: the DevTools-engine requirement, the top-level-page restriction, and the nativeDrag=true return signal for HTML5 drag.

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

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

Four tight sentences, front-loaded with the core action, then endpoint format, then use cases and constraints. No filler; every sentence carries information.

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

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

For a 10-parameter tool with no output schema, the description covers mechanism, endpoint formats, engine prerequisite, and page scope. It does not detail step-count tradeoffs or failure behavior, but annotations and the rich schema fill most remaining gaps.

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

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

Schema coverage is 100%, so baseline is 3, but the description clarifies the dual-mode endpoints ('a selector (its center) or x and y in viewport pixels'), explaining the selector-vs-coordinate mutual exclusivity that the schema only implies per-field.

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 (drag) and describes the exact mechanism: press at start, move in steps, release at end. An agent immediately knows this performs a real-mouse drag, distinct from click/hover/trusted_click 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?

Enumerates concrete use cases (sliders, sortable lists, canvases, native HTML5 drag and drop) and states prerequisites/exclusions: needs the DevTools engine, top-level page only. No explicit 'when-not' or named alternative, but the 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds the return contract (expression value vs. statement return or null) and the helper namespace, which is real behavioral value, but it omits execution limits, error behavior, and serializability constraints that matter for arbitrary code execution.

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 action and result, then evaluation modes, then the helper surface. No filler or restatement of the title.

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

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

For an arbitrary-code-execution tool with no output schema, the description covers the action, the two code forms, the return contract, and the helper API, while annotations carry the destructive/open-world profile. It stops short of describing failure modes, timeouts, or result serialization, which are the remaining gaps.

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

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

Schema description coverage is 100%, so both code and tab_id are already documented (baseline 3). The description goes beyond the schema by naming the A helper library and its members, giving the agent information about what is actually available inside the code parameter that the schema does not supply.

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 ('Run JavaScript in a tab') plus the outcome ('return the result'). The mention of the A helper library (A.click, A.setValue, A.all) implicitly separates it from the specialized DOM siblings, so an agent can place it without opening the schema.

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

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

The description explains two valid code shapes (bare expression vs. statement body with return), which is implied usage guidance for how to call it, but it never says when to reach for arbitrary JS versus the dedicated siblings (click, fill, query_elements, trusted_click) that overlap with the A helpers it advertises.

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

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

Annotations cover the safety profile (non-destructive, not read-only, open-world), and the description adds substantial behavior beyond them: native setter, input+change events for React, specific failure modes, ref re-resolution with reResolved/stale reporting, and settledMs/settled=false on the post-action quiet wait. It stops short of describing auth or rate-limit concerns, but for a DOM action tool that is not a meaningful gap.

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

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

Front-loads the action and the routing to alternatives, and nearly every sentence carries actionable detail. However it is a single very dense paragraph with long compound sentences, and a few clauses (settle cap details, verbose) restate schema content, so it is slightly overpacked rather than tight.

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

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

For a mutation tool with no output schema, the description covers the action, framework compatibility, all named failure modes, ref staleness handling, and the post-action settle contract including settledMs and settled=false. Nothing an agent needs to invoke and interpret it correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: ranking rules for text= matches (exact first, visible before hidden), what exact affects and does not affect, and reResolved behavior for ref=. Some of this duplicates the schema descriptions, so it is a modest lift over baseline rather than a full one.

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

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

Opens with a precise verb+resource ("Set the value of an input, textarea or contenteditable") and immediately distinguishes itself from siblings by naming click for checkboxes/radios/buttons and select_option for <select>. An agent can route correctly without opening another 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-to-use guidance (checkbox, radio, button → click; <select> → select_option) plus a workflow rule: check the returned matches count and pass exact when it exceeds 1. Alternatives and the condition that selects them are stated outright.

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

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

Goes well beyond annotations: it discloses that disabled/readonly/non-input targets fail with a reason, that all fields are attempted in order with per-field results, that `ok` is false if any field fails and `error` names the failures, and that values are not echoed back. These are exactly the mutation/partial-failure traits an agent needs and that the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) do not convey.

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

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

Front-loads what the tool does, then covers failure semantics, then the no-submit caveat. Every sentence carries information — no restated boilerplate or filler — and it fits in five tight sentences.

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

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

With no output schema, the description still explains the return contract (`ok`, `error`, per-field results, values not echoed) and the post-condition (must click submit separately). Nothing an agent needs to call this 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 both top-level parameters and the nested field properties are fully documented in the schema itself. The description adds little parameter-level detail (e.g., it does not explain tab_id behavior or the 50-field limit), so it sits at the documented-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 a specific verb and resource ('Fill several fields in one call') and immediately distinguishes itself from the single-field `fill` sibling by describing batching semantics. An agent can tell it apart from `fill`, `type`, and `select_option` 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?

Usage context is clear — use this when setting multiple fields at once, since each field behaves 'exactly as fill would'. It also gives the follow-up step ('Does not submit: click the submit button afterwards'). It never explicitly says 'use fill for a single field', so the alternative is implied rather than named.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it reads from Arc's own data file and needs no Apple Events, and it reports duplicates across the whole sidebar — details the annotations cannot convey.

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 primary purpose and behaviour. The appended 'pass its id to close_tab' is useful but slightly smushes a usage hint into the behavior block; still, virtually 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?

With no output schema, the description carries the burden of describing returns and does so (space, pin state, duplicate URLs), and it explains the data source. It stops short of describing result shape/pagination, but coverage is solid for this moderate-complexity query 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 days, limit, space, and include_duplicates are already fully documented in the schema. The description only loosely implies day-based idle filtering and duplicate reporting, adding no syntax or format detail beyond what the schema provides — the baseline 3.

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

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

States a specific verb+resource ('Find tabs the user has not touched for a number of days') plus ordering ('oldest first') and returned fields (space, pinned/unpinned/top app, duplicate URLs). An agent can distinguish this from list_tabs and sidebar_tree without opening either schema.

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

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

Gives clear context for acting on results by naming the follow-up tool ('pass its id to close_tab'), which routes the agent correctly. It does not state when-not-to-use or contrast against the similar list_tabs/sidebar_tree siblings, so it falls short of a 5.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds context annotations cannot express: it blocks until the user stops typing or moving the mouse, and fails with userActive=true if they never pause. That failure mode is exactly what an agent needs to handle this call correctly.

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

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

Three short sentences, front-loaded with the action, then the caveat, then the blocking/failure behavior. Every sentence earns its place with no redundancy.

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

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

With only one fully documented parameter and no output schema, the description supplies the remaining critical context: the user-visible side effect, the idleness wait, and the userActive failure signal. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% and the schema already states the parameter accepts a 'Space id or title from list_spaces.' The description adds no syntax or format detail beyond that, so the 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 ('Switch the front Arc window to a space') and immediately clarifies the effect on the user's view. This is clearly distinguishable from siblings like list_spaces or switch_to_tab, which operate on tabs rather than spaces.

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 the tool is 'rarely needed' and why: tabs in an unfocused space remain 'fully readable and scriptable.' That is an unusually strong when-not-to-use statement, effectively steering the agent away from unnecessary calls without naming a competing tool (none exists in the sibling list).

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

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world, so the safety bar is low. The description adds genuine behavioral context the annotations cannot: the fallback chain from the agent's own current tab to the active tab when none is set, which is the key nuance for predicting what a no-tab_id call touches.

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

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

A single front-loaded sentence that defines the resource and its resolution rule with no filler. Every clause carries meaning and the key scoping fact is stated 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 no-param read tool with full annotation coverage and a fully documented schema, the description supplies the essential resolution semantics. The only minor omission is what the tool returns (tab id/url/title), though with no output schema an agent might want a hint about the shape.

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% for the single tab_id param, so baseline is 3. The description goes slightly beyond the schema by spelling out the full fallback resolution ('this agent's current tab, or the active tab if it has none'), which the schema only summarizes as 'this agent's current tab'.

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 ('Get the tab') and immediately disambiguates the loaded term 'current tab' by defining it as the tab a no-tab_id call would act on. This lets an agent distinguish it from list_tabs or snapshot 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?

The description frames the tool as a resolver for default tab_id behavior, which implies when to use it, but it never explicitly states when to call this vs. siblings like list_tabs or arc_status, nor any exclusions. The concrete guidance ('pass this or call open_url first') lives in the schema, not the description.

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

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

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the safety profile is free. The description adds genuinely new behavior: only one element is returned, the match count is reported, and 'nth' selects among matches. That is real operational context the annotations do not convey.

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 purpose, then the usage cue, then the return-shape caveat. No filler and no repetition of schema content.

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

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

With no output schema, the description usefully states what comes back (one element, plus a match count) and how to pick another. It does not mention truncation behavior tied to max_chars, but that is documented in the schema, so the definition is essentially complete.

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

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

Schema description coverage is 100%, so the schema already documents nth, outer, tab_id, selector, and max_chars in detail (including selector grammar). The description's note about nth picking 'a different one' is largely redundant. 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 (get the HTML of a page or element) and immediately distinguishes itself from text-oriented siblings by saying it is for 'markup, attributes or structure rather than text.' An agent can separate this from get_page_content 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?

'Use when you need markup, attributes or structure rather than text' gives a clear selection condition and implicitly names the alternative (get_page_content), but no explicit when-not or exclusions are given. Strong context, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real context beyond them: hrefs are 'resolved' (not raw), and the unique flag collapses repeats and reports how many were dropped, explaining a non-obvious mutation of the output.

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

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

Two tight sentences, front-loaded with the core action and then the conditional flag behavior. 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 read-only listing tool with full annotation coverage and complete parameter descriptions, the description is nearly sufficient. It notes the returned fields, so the absence of an output schema is not a problem, though a word on ordering/pagination 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 coverage is 100%, so the baseline is 3. The description nonetheless adds motivation for the unique parameter (bulk repeats in navigation/footers) that the schema's terse description does not convey, nudging 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 ('List links on the page') plus the returned fields ('text and resolved href'), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from nearby siblings like query_elements or get_page_content, which also surface page data.

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 set unique ('which navigation and footers produce in bulk'), giving useful implied guidance, and the schema's tab_id note covers the fallback gotcha. But it never states when to prefer this tool over query_elements/get_html, nor any explicit exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuine behavioral context beyond them: it always reports 'matched' so partial results are never silent, and nested matches duplicate text. It does not mention truncation semantics, though max_chars in the schema hints at it.

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

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

Three tight sentences, front-loaded with the core action before the two behavioral caveats. Every sentence earns its place, and none restates the title or parameter names.

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

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

With no output schema, the description carries the burden of explaining returns, and it does reasonably well: joined text with blank lines, matched reporting, duplication on nesting, and truncation via the schema. An explicit note on the return shape (e.g., plain string) 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 the schema already documents tab_id, selector syntax, max_chars, and first_only thoroughly. The description adds only 'joined with blank lines' and 'nested matches repeat their text,' which is modest value over the structured fields. Baseline 3 applies.

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

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

States a specific verb and resource ('Get the visible text of a page') and clarifies the selector variant plus the blank-line joining. It is distinguishable from siblings like get_html and query_elements by the 'visible text' framing, though it never names them 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?

Offers one real selection guideline ('prefer a leaf-ish selector') because nested matches repeat text, which is useful. It gives no guidance on when to use this versus get_html, query_elements, or snapshot, and no when-not conditions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful context by listing the exact returned fields and describing the tool as 'cheap orientation,' which helps set expectations without an output 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 sentences, zero waste, and the most important information (what fields are returned) is front-loaded. The second sentence adds usage value without being verbose.

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

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

For a simple read-only tool with full parameter coverage and rich annotations, the description is nearly complete: it names the return fields and gives a usage cue. It could better distinguish itself from sibling tools such as get_current_tab or get_page_content, but nothing essential 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%, and tab_id is thoroughly documented in the schema itself, including fallback behavior and the requirement to call open_url first when changing tabs. The description adds no additional parameter semantics, 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?

The description states a clear verb+resource: it returns a page overview with specific fields (title, url, ready state, meta description, headings, form/frame counts). It does not explicitly differentiate itself from siblings like get_current_tab, get_page_content, or get_html, so it falls short of a 5.

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

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

The phrase 'Cheap orientation before deciding what to do' implies when to use the tool, but it gives no explicit alternatives, exclusions, or when-not conditions. Usage is inferable but not spelled out.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, leaving real room for the description to add value, and it does: it discloses that navigation actually goes through the page (enabling background-tab use), and that the result is verified against the tab URL rather than assumed. That verification detail is genuine behavioral context not present in any structured field.

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

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

Two sentences with the core action front-loaded, and no filler. The second sentence is a slightly sprawling clause chain, but every element (background-tab capability, URL verification) 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 navigation tool with no output schema and fully documented parameters, the description covers the mechanism and the verification behavior an agent would want to know. It stops short of describing return values or failure modes, but the safety profile is carried by annotations.

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

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

Schema description coverage is 100%, so the schema already fully documents tab_id, timeout_ms, and wait_until_loaded. The description adds no parameter-level detail beyond what the schema provides, making the baseline 3 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 and resource ('Navigate a tab back in history'), which is immediately distinguishable from go_forward. It does not explicitly name the sibling it complements, so differentiation relies on the agent inferring the back/forward pairing, but the purpose itself is unambiguous.

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

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

The description implies when this is preferable by contrasting it with Arc's own back command on background tabs, but it never states when to use this versus go_forward, reload_tab, or switch_to_tab. The tab_id guidance (omit for current tab, or call open_url first) lives in the schema rather than the description, so usage guidance is only implied.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description nonetheless adds a real behavioral trait: it verifies the tab actually moved before reporting success, which tells the agent the return is a confirmed result rather than an optimistic ack.

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, zero filler, action front-loaded. It could be marginally tighter, but nothing is wasted.

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

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

For a simple navigation action with a fully documented schema and clear annotations, the description covers what the tool does and how success is determined. With no output schema, a brief note on failure behavior (e.g., no forward entry) would close the last 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% and the schema already explains tab_id fallback behavior, the timeout cap, and wait_until_loaded. The description adds no parameter meaning beyond that, so it sits at 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+resource ('Navigate a tab forward in history'), which cleanly distinguishes it from siblings like go_back, reload_tab, and open_url. An agent can select it without opening the schema.

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

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

Usage is implied by 'forward in history', but the description never names go_back as the counterpart or states when not to use it (e.g., no forward entry available). The tab_id schema description carries the 'pass this or call open_url first' guidance, so routing context exists but outside the description.

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

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

Annotations already declare non-read-only, non-idempotent, open-world behavior, but the description adds real context: the dialog blocks page execution, other tools redirect here, and the DevTools engine is required. It does not cover failure behavior when no dialog exists, so it is strong rather than 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 sentences, front-loaded with the action and its target, then the blocking condition, then the prompt_text nuance. No filler or 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 3-parameter tool with no output schema, the description supplies the engine prerequisite, the blocking semantics, and when prompt_text matters. The only gap is expected behavior when a dialog is not actually open.

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 action, tab_id and prompt_text are already fully documented, including the accept/dismiss enum meaning and the tab fallback rule. The description's note that prompt_text applies when accepting largely restates the schema, so baseline 3 is appropriate.

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

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

States a specific verb pair (accept/dismiss) and a narrow resource (the JavaScript dialog), and enumerates the covered dialog types (alert, confirm, prompt, beforeunload). No sibling tool touches dialogs, so the agent can route here unambiguously.

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 gives the triggering condition: a dialog is open and the page cannot run anything, with other CDP tools pointing here. It also flags the DevTools-engine prerequisite. It stops short of stating what happens if no dialog is open or naming a fallback, so it is clear context rather than full when/when-not 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?

Annotations cover the safety profile (readOnly false, idempotent true, destructive false, openWorld true), so the bar is lower. The description still adds genuine behavioral context beyond them: it scrolls the target into view first, fires a specific ordered event set, and reports coveredBy when an overlay intercepts the center point — useful for diagnosing failed hovers.

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

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

Front-loads the core action before the event list, and each sentence carries distinct information (behavior, caveat, return signal). Slightly long — the enumerated event list could be trimmed — but nothing is wasted.

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

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

No output schema exists, and the description compensates by explaining the coveredBy signal returned like click. Combined with the scrolling and :hover caveats, an agent has enough to call and interpret it, though a note on return shape beyond coveredBy would complete it.

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

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

Schema description coverage is 100%, so all five parameters (nth, exact, tab_id, verbose, selector) are already fully documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and target ('Move a pointer onto an element') and enumerates the exact events fired (pointerover, pointerenter, mouseover, etc.) at the element center. Very clear what the tool does, but it does not name or differentiate itself from the sibling trusted_hover, leaving the agent to infer the distinction.

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

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

Gives a clear when-to-use ('Opens menus and tooltips that listen for those events') and an important when-it-won't-work caveat ('a menu driven only by :hover will not open'). It stops short of naming the alternative tool (trusted_hover) for cases this one can't handle, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds front-window scoping, the fact that pinned tabs are excluded from space counts, and the reconciliation formula (tabsInSpaces + topAppCount = totalTabs). This goes beyond annotation coverage, providing useful behavioral context, though it doesn't describe the exact return structure.

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

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

The description is three sentences, front-loaded with the core purpose, followed by two concise clarifying details. No redundant or vague phrasing.

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

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

Given zero parameters and no output schema, the description provides sufficient context: what it returns (tab counts, active indicator), the window scope, reconciliation with pinned tabs, and the relationship to list_tabs. An agent can call it correctly and interpret results without additional information.

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

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

The tool takes no parameters (input schema is empty), so there is nothing for the description to add. Baseline of 4 for zero-parameter tools 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 states a specific verb (list), resource (Arc spaces), and scope (front window), and adds tab counts and which space is active. It explicitly differentiates from list_tabs by noting the window coverage ('Counts cover the front window only, while list_tabs covers every window'), making the 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?

It explicitly contrasts with list_tabs ('Counts cover the front window only, while list_tabs covers every window'), giving a clear selection rule. It also explains the reconciliation logic for pinned tabs (topApp), helping the agent decide when this tool's output is appropriate.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds useful behavioral context by explaining row flags and the default scope, which is valuable beyond what annotations provide.

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

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

The description is two sentences with no filler, front-loading the core purpose before the behavioral details. Every clause earns its place and contributes to correct tool invocation.

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 listing tool with four optional parameters, the description covers the essential behaviors: default scope, row flags, and narrowing via scope. Minor details like ordering or result limits are not specified, but they are not critical for an agent to call this tool correctly.

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

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

The input schema is fully documented at 100% coverage, so the schema already carries the parameter meaning. The description adds only a minor clarification about the scope parameter's default and effect, which is otherwise already present in the schema.

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

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

The description uses a specific verb and resource ('List Arc tabs') and immediately clarifies the key row semantics ('mine' and 'isActive'), making the tool's purpose unambiguous. This is enough to distinguish it from siblings like get_current_tab or close_tab even without naming 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 description clearly states the default behavior ('Defaults to every tab') and the way to narrow it ('pass scope 'own' to narrow'), giving agents concrete context for invocation. It does not explicitly discuss when to prefer this tool over alternatives, so it stops short of a 5.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: only finished requests appear, ~250 entry cap, cross-origin entries hide size/status unless Timing-Allow-Origin opts in, data: URLs are absent, no bodies/headers, and query strings are stripped by default. These are exactly the caveats an agent needs to interpret results correctly.

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

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

It is a single dense paragraph, but it is front-loaded with the core action and mechanism before listing limits, and every clause carries real information (no filler or restatement of the title). Length is justified by the number of behavioral caveats, though it could be broken into purpose/limits/parameters segments for easier scanning.

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

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

With no output schema, the description carries the return-value burden and does so fully, enumerating entry fields (url, initiator, start, duration, size, status) and the conditions under which fields are missing. Combined with the deferred-param and limits context, an agent has everything needed to call and interpret 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 limit, filter, tab_id, since_ms, and include_query thoroughly, including the default-comparison rationale for include_query. The description reinforces a few of these (the query-string drop and the entry cap that bounds limit) but adds no per-parameter syntax beyond the schema, so baseline 3 applies.

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

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

The description names a specific verb and resource (list the page's network requests) and immediately distinguishes itself from siblings by naming the mechanism (performance.getEntriesByType) and the alternative it replaces (capture_start, blocked by CSP). An agent can tell it apart from network_requests and the capture_* family 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?

It states a clear use condition: works on any page with no recorder, including pages whose CSP blocks capture_start, which implicitly routes agents away from the recorder-based tools. It does not explicitly name network_requests or state when that sibling should be preferred instead, so the exclusion guidance is incomplete.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context on top: bodies excluded, header credential redaction rules, query-string and fragment stripping, and the CDP capture-window limitation with no historical readback. This is exactly the behavioral detail an agent needs to interpret results correctly.

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 returned fields, then the constraints, then the ordering instruction — a sensible sequence. Slightly redundant: the redaction of cookie/authorization/set-cookie is stated once for include_headers and then restated in the broader credential-header rule, costing a sentence.

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

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

For an 8-parameter, no-output-schema read tool, the description covers the return shape, the capture prerequisite, redaction policy, and the tab-resolution quirk. Nothing an agent needs in order to call it correctly appears to be 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 genuine meaning beyond the schema: the include_query/url_contains interaction ('url_contains then matches the url without its query') and the header-redaction scope for include_headers. It also reinforces the tab_id refusal semantics. This exceeds what the schema text alone conveys.

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 with an explicit enumeration of the returned fields (method, url, status, type, timing, transferred size), so an agent knows exactly what this produces. It does not, however, differentiate itself from the sibling 'network_entries', which sounds like an overlapping network-listing tool, so an agent cannot disambiguate between the two from the description alone.

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

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

Gives concrete ordering guidance: 'Call this tool (or cdp_status then any CDP tool) before the action you want to observe,' and warns that capture only begins once a CDP tool touches the tab. It also flags the tab_id divergence from other read tools ('never falls back to the tab the user is looking at'). It stops short of naming an alternative tool to use instead in any scenario, so no explicit when-not.

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

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

Annotations only declare the generic profile (not read-only, open-world, not idempotent, not destructive). The description adds substantial context the annotations cannot convey: dedicated agent window placement on a second display, restoration of the user's focused window, the pause-until-idle gating, the userActive failure mode, and the activate side effect.

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

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

Purpose and launch behavior are front-loaded, and nearly every sentence carries load-bearing operational facts. It is somewhat dense in a single paragraph and could be segmented, but there is no wasted filler.

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

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

For an open-world, non-idempotent action with no output schema, the description covers launch, window targeting, idle-wait semantics, the failure signal, retry advice, and activation. The schema fully covers parameters, so nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all eight parameters, including the nuanced tab_id and timeout_ms notes. The description only echoes activate ('Pass activate to bring the tab to the front'), which the schema already states, so it adds little beyond 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?

The description opens with a specific verb+resource ('Open a URL in Arc') and immediately scopes behavior ('Launches Arc if needed'), making it trivially distinguishable from siblings like close_tab, get_current_tab, or reload_tab. An agent knows 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?

It gives clear operational context: tabs land in a dedicated agent window, the user's focused window is restored, and on userActive failure the guidance is 'retry later'. It also notes when to pass activate. However, it names no alternative sibling tools and states no explicit when-not-to-use exclusion, so it stops short of a 5.

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

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

Substantially exceeds the annotations: it discloses that only the page's own handlers react, that a synthetic key types no character, moves no focus and submits no form, that an unknown key name fails, and that defaultPrevented signals handler capture. It also explains the settle/quiet behavior and the settled false cap outcome, which the annotations do not cover.

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

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

The action, the handler caveat and the escape hatch ("To type, use fill") are front-loaded, and the return/settle details come after. It is dense and slightly long for a single-key tool, but nearly every sentence carries distinct information and none is redundant with the schema.

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

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

There is no output schema, so the description carries the return contract and does so: defaultPrevented, the minimal element identity with its fallback to query_elements, and settledMs/settled. Combined with the handler-effect caveat, an agent has everything needed to call it correctly and interpret the result.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: omitting selector targets the focused element, and an unrecognized key name fails rather than silently no-oping. These are semantic behaviors the schema text does not state, lifting 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?

The description states a specific verb and resource ("Dispatch a key press to an element") and immediately scopes the target ("or to the focused element when no selector is given"). It explicitly distinguishes itself from siblings by routing typing to fill and full-element inspection to query_elements, so an agent can separate press_key from type/fill/trusted_press_key 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?

It gives explicit routing ("To type, use fill") and notes query_elements when the abbreviated return is insufficient, plus tab_id guidance about not falling back to the user's tab. It stops short of clearly positioning this against the trusted_press_key sibling and vs click, so the alternative coverage is good but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds non-obvious behavior: substring vs whole-text matching and that exact matches are ranked first, which materially affects result interpretation.

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

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

Two tightly packed sentences with the return payload and the primary use case front-loaded, followed by matching semantics. No filler, though the exact-match clause partially restates the schema's exact parameter.

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, yet the description enumerates the returned fields, and annotations cover the safety profile, so an agent has enough to decide and invoke. Minor gaps remain around result count/pagination and subtree scoping, both partially covered by the limit parameter.

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 reinforces the text= substring/exact distinction and the ranking rule, but adds little on limit, tab_id, verbose or visible_only beyond what the schema already documents in detail.

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 (find) and resource (elements) plus the exact payload returned: text, value, href, visibility, disabled state, attributes. That lets an agent tell it apart from raw-content siblings like get_html, though no sibling is named explicitly.

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

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

"The main way to see what is on a page before acting on it" gives clear usage context (pre-action inspection) and the selector section implies the lookup scenarios. It stops short of naming alternatives or when-not-to-use cases (e.g. vs snapshot or get_page_content).

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

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

The annotations already cover safety hints (readOnly false, idempotent, non-destructive), so the description goes further by explaining the failure mode: ok=false when the document is unchanged, and why (slow server, unload handlers). This is genuinely valuable behavioral context beyond the annotations.

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

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

Three sentences, front-loaded with the primary action and verification behavior. Reasonably tight, though the final clause about 'a page holding on to unload' is slightly long despite being informative.

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

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

Given the tool has no output schema, the description helpfully explains return fields (from, to, tab) and the ok=false failure condition. It's nearly complete, though it could note whether the tab_id is required for background tabs versus current.

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 tab_id, timeout_ms and wait_until_loaded in detail. The description confirms which params are shared with sibling navigating tools, adding minor cross-tool context but not new parameter meaning.

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

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

States a specific verb (reload) and resource (tab) with added scope: verification that the document actually changed, and background-tab support. This distinguishes it from neighbors like wait_for_load or stop_loading without naming them directly.

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?

Implies when to use it (reloading a tab and detecting a stale document) and notes it works on a background tab. It references 'the other navigating tools' generically but doesn't name specific alternatives or explicit when-not conditions.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), but the description adds real behavioral context: capture works on a background tab, activate blocks until the user pauses and then restores focus, full pages are capped at 16384px with a cut indicator, and large PNGs cost tokens. These are meaningful traits beyond the structured annotations.

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

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

Front-loaded with the core action and mode options, and each sentence carries information. It is somewhat dense in the parenthetical about activate/focus restoration, but nothing is padding.

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

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

For a read-only capture tool with no output schema, the description covers modes, prerequisites (cdp_status), tab selection behavior, truncation reporting, and cost tradeoffs. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value: it links format='jpeg' with a quality setting for long pages and clarifies that selector and full_page are mutually exclusive. That is genuinely useful guidance beyond the per-parameter schema text.

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

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

The opening sentence gives a precise verb+resource and immediately enumerates the three capture modes (viewport, full_page, selector), so the agent knows exactly what it gets without opening the schema. It also distinguishes itself from other read tools by noting the DevTools engine requirement and pointing to cdp_status.

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

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

It states when to use which mode (selector vs full_page), when to pass activate true ('only if you want Arc to show it'), and the recommended format/quality tradeoff for long pages. It also explains the refusal case when no tab_id and no owned tab exist, routing the agent to open_url first.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true). The description adds genuinely useful behavioral detail by disclosing that page scrolls return scrollY, pageHeight and viewport, which matters because there is no output schema. It doesn't explain why the operation is flagged non-read-only, so it's strong but not complete.

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

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

Two tight sentences with no filler. The core action is front-loaded and the return-value note is secondary, so an agent gets the essential 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?

With no output schema, the description usefully compensates by naming the returned scroll metrics. All parameters are covered by the schema and the safety profile by annotations, so nothing critical is missing, though the tab_id fallback caveat is left entirely to the schema.

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

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

Schema description coverage is 100%, so all six parameters (selector, direction, amount, exact, tab_id, verbose) are already documented in the schema. The description only restates the page-versus-element distinction that the selector parameter already conveys, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (scroll) and resource (page or element), and explicitly separates the two operating modes: page scrolling versus scrolling an element into view. It is immediately clear what the tool does, though it doesn't explicitly differentiate itself from any sibling since no sibling overlaps this behavior.

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 usage via the return-value note ('so you can tell how much is left'), suggesting it's used for pagination-style navigation, but it never states when to prefer scroll over alternatives or any preconditions. Usage is inferable but not 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?

Annotations already establish read-only, idempotent, non-destructive. The description adds real behavioral context beyond them: result ordering (newest first), strict AND matching semantics ('every word in query must match'), and the data source ('read from Arc's own data file'). It doesn't cover return shape or empty-result behavior, but it meaningfully lowers call uncertainty.

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

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

Four tight sentences, front-loaded with the resource and scope before the matching rule and parameter hint. No filler; each clause 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 zero-required-param search tool with full schema coverage and no output schema, the description covers purpose, ordering, match semantics, and data source. It omits only return-field detail, which is a minor gap given no output schema exists.

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

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

Schema coverage is 100%, so baseline is 3. The description nonetheless adds semantics not present in the schema: the AND-matching rule for query words and the precise meaning of reason 'auto'. These directly affect how query is constructed, so it earns 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: search tabs that Arc archived or the user closed, explicitly scoped to the sidebar's Archive. This is a distinctive resource that separates it from history search, though it does not name the sibling search_history to make the distinction 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?

Offers guidance for the reason parameter ('use reason auto to see only what Arc archived on its own'), which is useful. But there is no explicit when-to-use vs search_history or other retrieval siblings, so tool selection guidance is only implied.

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

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

Annotations only cover the read-only/idempotent safety profile; the description adds genuinely useful behavior the schema cannot convey — the environment-variable gate, the ok:false failure mode with remediation instructions, and the AND-matching semantics. This is exactly the kind of auth/prerequisite disclosure that earns top marks.

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, front-loaded with what is searched and what is returned, then the critical gating caveat, then the matching rule. No filler and nothing repeated from the schema.

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

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

With no output schema, the description does carry return-shape information (visit counts, last visit time, ordering) and the disabled-path response. It stops short of describing pagination or how the time window interacts with limit, but nothing essential to a correct call is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds non-obvious semantics beyond the schema: every word in the query must match (AND, not OR), and results are ordered newest first. No syntax details for the time window (since_days/until_days) are added 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+resource (search Arc's browsing history) and scopes it precisely by saying it matches text in the title or url and returns pages with visit counts and last visit time, newest first. It never names a sibling such as search_archive, so the boundary between 'history' and 'archive' is left to inference, which keeps it short of a 5.

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

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

Gives clear operational context: the tool is OFF unless the server was started with ARC_MCP_ALLOW_HISTORY=1, and explains what happens when it is disabled. It also states the matching rule ('Every word in query must match'), but offers no guidance on when to prefer this over the sibling search_archive.

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

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

Annotations only cover the safety profile (readOnly=false, destructive=false, openWorld=true). The description adds real behavioral context: disabled elements fail, a failed match enumerates the available options for the next call, success waits for the DOM to settle, and settledMs/settled=false are reported so the next read is accurate.

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 sentences, front-loaded with the purpose and then failure/settle semantics. Mostly efficient, though the settle wait and settledMs reporting are largely duplicative of the settle_ms schema description.

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

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

There is no output schema, so the description carries the return-value burden and does so: it explains settledMs, the settled=false cap condition, and the options-listing failure payload. For a 4-param, non-read-only action this is complete.

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

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

Schema description coverage is 100%, so the schema already documents selector, tab_id, option and settle_ms in detail. The description restates the option-matching rule and the settle/wait behavior rather than adding new 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 and resource ('Choose an option in a select element') and pins down the matching basis (exact value or exact visible label). That scope distinguishes it from the generic fill/type siblings, which cannot target a <select>.

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 strongly implied by the need to set a select element, and the description notes that disabled selects/options fail rather than being set. However, it never explicitly names an alternative (e.g. fill/type) or states when not to use this tool; the 'text=' limitation only appears in the schema, not the description.

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

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

Annotations already cover the safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), and the description adds real context beyond that: reads a periodically-written file so results may be stale, points to asOf, and notes match_live costs an Apple Events call and requires Arc running. This is exactly the kind of extra behavioral detail the annotations cannot express.

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, with the core purpose first and secondary facts (id pass-through, staleness, match_live) following in tight order. 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?

There is no output schema, so the description carries the return-shape burden, and it does name the key fields (spaces, pinned/unpinned, folders, favourites, tab ids, asOf) plus the cross-tool id correspondence. Minor omissions remain (ordering, favourites structure) but the agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, which sets the baseline at 3. The description adds only marginal meaning (that match_live checks each tab against Arc's open tabs, and that asOf reflects staleness) and repeats intent already in the schema.

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

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

The description gives a specific verb and resource ('Read Arc's sidebar from its own data file') and enumerates exactly what is returned: spaces, pinned items with nested folders, unpinned tabs, and top-app favourites. It explicitly distinguishes itself from list_tabs, so an agent can tell the two apart 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?

It states the comparative advantage over the sibling ('Gives what list_tabs cannot: pinned versus unpinned, folders, when each tab was last active') and tells when to add match_live. It never spells out an explicit when-not condition, so the routing is clear but not fully prescriptive.

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

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

Annotations only cover the safety profile (readOnly, idempotent, openWorld, non-destructive); the description adds substantial behavior beyond that: ref stability across snapshots, re-resolution by role and name for re-rendered elements, the explicit failure mode when an element is truly gone, shadow-root and same-origin iframe traversal, hidden-subtree skipping, name capping at 100 chars, and an untrusted-data warning.

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

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

Front-loaded with purpose and a format example, then usage, then edge-case behavior — no filler sentences. It is dense and somewhat long, but the length is justified by a 7-parameter tool with no output schema; a couple of behavioral clauses could be tightened.

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

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

With no output schema, the description carries the return-format burden and does so: it shows the tree line format, explains refs, truncation reporting, and diff output ('unchanged' vs added/changed/removed). Combined with the per-document ref caveat and untrusted-data warning, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining how refs are consumed as selectors and by steering parameter choice ('Prefer interactive_only...', 'diff to see only what changed'). It adds practical semantics for diff and interactive_only beyond their schema text, though depth, boxes, scope and max_chars are left to the schema.

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

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

States a specific verb and resource — 'Read the page as a compact tree of roles, accessible names and refs' — and immediately shows the output shape with a concrete example (`- button "Save" [ref=e12] (disabled)`). This clearly separates it from get_page_content, get_html, query_elements and screenshot, all of which expose the same page differently.

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

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

Gives actionable routing: pass a ref as the selector of click, fill, select_option, press_key, scroll, query_elements, wait_for_selector or get_page_content, and explicitly recommends interactive_only for 'a menu of things to click' and diff for change detection. It also flags the navigation caveat (refs are per document, snapshot again). It stops short of stating when to prefer a sibling like get_page_content or get_html over snapshot.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), yet the description adds genuinely new behavior: rendered content is preserved, the return reports whether the tab was loading, and it fails if the tab is still loading afterward. That is substantive context the annotations cannot convey.

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

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

The core action is front-loaded and the rationale follows. Every clause carries information, though the explanation of Arc's script-blocking behavior is slightly verbose for a one-parameter tool.

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

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

No output schema exists, and the description compensates by stating what it reports (whether the tab was loading) and its failure condition. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single tab_id parameter is fully documented in the schema, including the omit-to-use-current-tab behavior. The description adds no parameter-level detail beyond that, 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?

Opens with a specific verb+resource ('Stop a tab that is still loading') and grounds it with a familiar analogy ('as the browser's stop button does'). An agent can distinguish this from reload_tab and wait_for_load without opening any schema.

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

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

Gives an explicit when-to-use condition ('Use it on a page that never finishes (a hung request, a stuck iframe, a stream)') and explains the failure mode that motivates it. It doesn't name sibling alternatives directly, but the triggering context 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?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), but the description adds non-obvious behavior the annotations do not: it blocks until the user stops typing/moving the mouse, and returns userActive true on timeout. That is exactly the kind of blocking/failure semantics an agent needs to avoid hanging.

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

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

Three short sentences, each earning its place: the core action first, then the routing advice, then the blocking/failure caveat. 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 no-output-schema mutation tool, the description covers the key gaps (visibility impact, blocking, failure signal). It could note that activate controls whether Arc is brought to the front, though the schema already describes that parameter.

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 tab_id and activate are already fully documented in the schema. The description adds no syntax or format detail beyond echoing 'a tab by id,' 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 and resource ('Make a tab the active tab in its window'), which clearly distinguishes it from siblings like get_current_tab (reads) and list_tabs (enumerates). An agent can pick it apart from close_tab or open_url without opening the schema.

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

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

Gives an explicit when-not rule: 'prefer reading a tab by id when you only need its content,' which steers the agent away from switching when only content is wanted. It stops short of naming the specific alternative tool (e.g. get_page_content), leaving a small inference step.

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

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

Goes well beyond the annotations: discloses the engine dependency, that disabled controls are refused, that coverage by another element is reported via coveredBy, and that only top-level page elements are reachable. These are exactly the gotchas an agent needs before invoking a real-input click.

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

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

Front-loaded with the core purpose, and each subsequent sentence carries distinct information (engine requirement, refusal behavior, coveredBy, iframe limit). It is dense and slightly long, but no sentence is filler.

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

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

For a mutation tool with no output schema, it covers the engine prerequisite, the failure/refusal conditions, the return signal (coveredBy), and the reachability limitation, leaving nothing an agent needs in order to call it correctly.

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

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

Schema coverage is 100%, so the schema already documents all six parameters in detail (including the click_count double/triple semantics and the button enum). The description's mention of "double clicks, right clicks" maps loosely to click_count and button but is redundant with the schema text, so baseline 3 is appropriate.

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

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

States a specific verb and resource (click an element with a real mouse event) and immediately distinguishes itself from the sibling synthetic `click` tool by its isTrusted mechanism and scroll-into-view behavior. An agent can tell exactly which of the two click tools to pick without inspecting 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?

Explicit when-to-use: "Use it when the synthetic click tool is ignored" with concrete triggers (widgets gated on event.isTrusted, autocomplete/menus on a real pointer, double/right clicks). It names the alternative tool and the condition that selects it, and adds a prerequisite (needs the DevTools engine) and an exclusion (iframe elements unreachable).

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

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

Annotations declare idempotent, non-destructive, open-world behavior, so the safety bar is partly covered. The description adds genuinely new behavioral detail: that it dispatches a 'real' pointer event rather than a synthetic one, requires the DevTools engine, and returns hoverApplied indicating whether the browser now considers the element hovered. That is meaningful extra context beyond the annotations.

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

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

Three tight sentences: the action first, the engine prerequisite second, the return value last. No filler, and the most important information is front-loaded.

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

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

With no output schema, the description usefully documents the return field (hoverApplied) and the engine requirement, and annotations cover the safety profile. The only remaining gap is guidance on when this beats the untrusted 'hover' tool.

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

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

Schema description coverage is 100%, so all four parameters (nth, exact, tab_id, selector) are already fully documented in the schema. The description adds no syntax, format, or selector details beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Move a real mouse pointer over an element') plus the observable effect (hover menus, tooltips, :hover styles). It is clear, but it never explicitly distinguishes itself from the sibling 'hover' tool, leaving the agent to infer the difference from the 'real mouse pointer'/'trusted' wording.

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 one real prerequisite – 'Needs the DevTools engine' – which is useful usage context. However, it never says when to prefer this over the plain 'hover' sibling, nor any conditions or exclusions, so routing guidance is only implied.

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

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

Goes beyond the annotations (which only cover safety/idempotency) by explaining that real key events are dispatched, how modifiers map (Meta is Command), the macOS editing-shortcut caveat, and that it reports the focused element afterward. Missing details on error behavior or what happens if no selector matches, but the added behavioral context is substantial.

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: the core behavior and consequences come first, followed by accepted key formats, platform caveats, and the optional focus behavior. Every sentence carries information, though the macOS editing-shortcut sentence is slightly tangent.

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

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

For a 5-param, non-idempotent, open-world interaction tool with no output schema, the description covers the mechanism, platform caveats, tab targeting, and focus behavior, and even notes the post-action return value (focused element). Lacks only explicit failure/edge-case handling.

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

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

Schema coverage is 100%, so baseline is 3; the description nevertheless enriches key format (named keys, single chars, modifier combos like Control+Shift+K) and clarifies that the selector is focused first while omitting it presses into current focus, adding meaning 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+resource ('Press a key or shortcut') and immediately distinguishes its mechanism from a plain key press by emphasizing 'real key events' with concrete consequences (Enter submits, Tab moves focus, Escape closes). An agent can tell this apart from the sibling press_key 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?

Provides one concrete prerequisite ('Needs the DevTools engine') and the implied case for use (when synthetic events won't do), plus a note that a tab-changing tool won't fall back to the user's tab. However, it never explicitly contrasts this with the sibling press_key, so the when-to-choose-this-over-alternative guidance is only implied.

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