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

With no annotations, the description carries the full burden and does so well: it discloses the ownership gate (TAB_NOT_OWNED, TAB_INCOGNITO_NOT_SUPPORTED, TAB_OUT_OF_SCOPE), the concurrency cap and AGENT_CAP_REACHED payload, agent-scoped tab addressing, and that it is background-tab compatible and does not steal focus. It also enumerates status outcomes (ok, no_history, cross_origin, bf_cache, fragment_only) and typed error codes, which is exactly the kind of behavioral context an agent otherwise cannot infer.

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 correctly, but the middle is bloated with duplicated content: cross-agent rejection/TAB_NOT_OWNED appears twice, and the typed error codes are enumerated once in prose (NO_BACK_HISTORY, CROSS_ORIGIN, BF_CACHE, FRAGMENT_ONLY) and again inside the status list. Tightening would remove roughly a third of the text without losing 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?

Given no annotations and no output schema, the description is complete enough to invoke safely: it documents targeting scope, ownership rules, the return shape { status, resultingUrl, historyDepth }, the change_report payload, its truncation behavior, and the error codes. An agent has everything needed to call it 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?

Only one parameter, and schema coverage is 100% (including the 'defaults to the agent's active tab' semantics), so the schema baseline is 3. The description adds genuine meaning on top: tab_id is agent-scoped and only tabs owned by the calling agent are addressable, with named rejection codes for incognito and cross-window tabs.

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

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

Opens with a specific verb and resource plus scope: 'Navigate one step back in browser history on the agent's active tab,' and immediately constrains it ('Single-step only (no back(n))'). However, it never addresses the near-identical sibling `go_back` (nor `go_forward`), so an agent cannot fully disambiguate this tool from its own siblings 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 useful conditional context: targets the agent's active tab 'unless tab_id is supplied,' and recommends using change_report 'without calling read_page next.' But there is no explicit when-to-use/when-not guidance and no routing to the obvious alternative (`go_back`), which is the single most important selection question here.

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

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

With no annotations, the description carries the full burden and does so: it discloses the output channel (native image plus private managed file, or transient attach under autopilot with no file created), overlay hiding and restoration, temporary emulation that never spoofs the user agent or reloads, and multi-agent tab scoping with the TAB_NOT_OWNED rejection. These are non-obvious behavioral traits an agent could not get from the schema.

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

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

The description is dense but front-loaded: purpose and modes come first, then inclusions/exclusions, then output and multi-agent behavior. Most sentences earn their place, though the run of behavioral clauses (emulation, overlays, multi-agent) is packed tightly and slightly increases cognitive load.

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 15-parameter tool with no annotations and no output schema, the description covers capture content, exclusions, output form, and multi-agent constraints well. It leaves minor gaps around parameter interactions (e.g., which params are valid per mode beyond the schema's own notes), but nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond it: tab_id should only be passed to disambiguate an owned tab, FSB overlays are hidden by default and restored, and responsive emulation is temporary and non-spoofing. It still does not explain coordinate_space or device_scale_factor semantics in prose, so it stops short of full compensation.

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

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

States a specific verb (capture) and resource (live Chromium-composited page as lossless PNG) and enumerates the four capture scopes (viewport, full document, region, element). It also draws the boundary of what is included versus excluded (browser chrome, desktop), so an agent knows exactly what this tool produces.

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

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

Positions the tool for 'visual inspection and UAT' and explains how the mode/device_mode choices select behavior, which gives clear usage context. However, it never contrasts itself with close siblings like get_page_snapshot, get_dom_snapshot, or read_page, so the agent must infer when a screenshot is preferable to a DOM/page 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?

With no annotations provided, the description carries the full burden and delivers: agent-scoped tab ownership, the TAB_NOT_OWNED cross-agent rejection, a configurable concurrency cap (default 8, range 1-64), and a detailed change_report return contract including truncation signaling. This is unusually rich behavioral disclosure for a mutation tool.

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

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

Front-loaded with purpose and return value, then organized into labeled blocks (When to use / Related / Multi-agent / RETURNS). It is dense and slightly repetitive on tab_id ownership, but nearly every sentence carries actionable information, especially the change_report contract that no output schema covers.

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, yet the description fully specifies the return value (new checked state plus change_report fields) and its truncation escape hatch. Combined with the multi-agent and cap behavior, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including tab_id's single-vs-multi-tab rule. The description restates the tab_id guidance rather than adding new syntax or format detail, 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 ('Toggle a checkbox element') and immediately names the return ('Returns the new checked state'). It also distinguishes itself from siblings by naming get_dom_snapshot for selector discovery and click as the alternative for custom checkbox UI.

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

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

Explicit 'When to use' clause covers both checkboxes and toggle switches, and the 'Related' section names two alternatives with the condition that selects each (get_dom_snapshot to find selectors, click for custom components). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden and does so: it discloses multi-agent tab ownership, the cross-agent rejection code TAB_NOT_OWNED, the configurable cap and its range, and the change_report return shape including truncation flags and the read_page fallback. That is substantially more than the name or schema conveys.

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 when-to-use, then layered into Related, multi-agent, and RETURNS blocks that each carry weight. It is dense and slightly bloated, and the orphaned cap sentence is wasted space, but nothing else 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?

There is no output schema, so the description must describe the return value, and it does in detail: change_report fields, the truncated flag, and the read_page escape hatch. Combined with multi-agent and error-code coverage, an agent has everything needed to invoke and interpret this tool.

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

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

Schema coverage is 100% and the description's tab_id guidance largely restates the schema text, so there is little added meaning. The "cap configurable (default 8, 1-64)" clause is not anchored to any declared parameter, which adds ambiguity rather than clarity, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ("Clear the contents of an input field") plus the immediate outcome ("Returns clear confirmation"). The Related line separates it from type_text and get_dom_snapshot, so an agent can route without opening sibling schemas.

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

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

Gives an explicit trigger condition ("before typing new text into an already-filled field to remove existing content") and names the adjacent tools with their roles. The relationship to type_text in particular makes the when-to-use decision unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states that the tool returns whether the click succeeded, documents the change_report field and its subfields, notes truncation behavior and the follow-up read_page path, and discloses multi-agent tab ownership rules and the TAB_NOT_OWNED rejection.

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 front-loaded and well-sectioned with labels for usage, dropdown pattern, related tools, multi-agent behavior, and return format. It is longer than typical for a click tool, but most detail is justified by the edge cases it covers.

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 absence of annotations and output schema, the description is complete enough for correct invocation: it covers purpose, prerequisites, failure recovery, custom dropdown handling, tab scoping, and the shape of the returned change_report.

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 input schema already documents all six parameters in detail. The description adds some workflow context for text versus selector and tab_id ownership, but largely duplicates what the schema already provides, 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 immediately: "Click an element on the page." It then explicitly distinguishes usage contexts (buttons, links, controls, selections) and names related alternatives such as click_at, hover, and select_option, so an agent can tell it apart from siblings without opening schemas.

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

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

Provides explicit when-to-use guidance, a prerequisite (get selectors from get_dom_snapshot first), fallback behavior if the click fails, text-based targeting, a full custom dropdown pattern, and named alternatives for native selects and hover menus. The routing is unusually complete.

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

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

No annotations exist, so the description carries the full burden and does so well: it discloses the CDP trusted-event mechanism and exact dispatch order, multi-agent tab scoping with TAB_NOT_OWNED rejection, the configurable agent cap (default 8, range 1-64), and the change_report return including the truncated/hint fallback. This is far beyond what bare structured fields 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?

Front-loads the core action and organizes the rest into labeled segments (When to use, Related, Multi-agent, RETURNS). It is dense and slightly long, but each sentence maps to a distinct decision (invocation, alternative selection, ownership, return handling), 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?

With no annotations and no output schema, the description compensates fully: it explains the mechanic, the coordination model, error behavior, and the change_report contents plus the truncation escape hatch (call read_page). Nothing an agent needs to invoke or interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine context: it reinforces that coordinates are CSS pixels relative to the viewport and clarifies when tab_id should be passed versus auto-resolved. Required fields (visual_reason, client) are not elaborated, keeping it above baseline but not exhaustive.

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

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

States a specific verb+resource+mechanism: 'Click and hold at specific viewport coordinates for a specified duration using CDP trusted events.' It then names the exact sequence (mousePressed, wait, mouseReleased) and explicitly distinguishes itself from siblings click_at and drag. An agent can pick it out of the ~70-tool list 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?

Provides an explicit 'When to use' clause (record buttons, long-press menus, sustained press UIs) plus a 'Related' line contrasting click_at ('without hold') and drag ('click, move, and release'). It also gives the tab_id selection rule (pass only when owning multiple tabs) and the cross-agent rejection behavior, so both invocation and routing conditions are covered.

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

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

No annotations exist, so the description carries full behavioral burden and does so: CDP trusted events, multi-agent tab ownership with TAB_NOT_OWNED rejection, a configurable concurrency cap (default 8, 1-64), tab_id auto-resolution semantics, and a detailed change_report return contract including truncation handling.

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?

Long but front-loaded and sectioned (purpose, when-to-use, related, multi-agent, returns), with each block serving a distinct decision. It is verbose in places—the change_report paragraph could be tighter—but almost nothing is pure filler for a tool with this much surface area.

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?

Despite no output schema, the description explains the return value (change_report fields, truncation flag, read_page fallback) and covers multi-agent ownership and tab targeting. Nothing an agent needs to invoke 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%, so the baseline is 3, but the description adds meaning beyond it: shift+click is explained as multi-select, coordinates are pinned to CSS pixels relative to the viewport with getBoundingClientRect() as the source, and tab_id's omit-vs-pass behavior is spelled out.

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 at specific viewport coordinates using CDP trusted events') and immediately scopes it against the sibling click tool. An agent can distinguish it from click, double_click_at, and drag without opening any schema.

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

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

Explicit 'When to use' clause names the target cases (canvas, SVG, overlays) and positions it as a fallback for click failures. The 'Related' section names the preferred alternative (click) and the exact condition for switching ('use click_at only when click fails'), plus get_dom_snapshot and drag.

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

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

With no annotations, the description carries full behavioral burden and does so thoroughly: active-tab protection, agent-scoped ownership, cross-agent rejection with TAB_NOT_OWNED, configurable tab cap, tab_id auto-resolution, and a detailed change_report return contract including truncation behavior.

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

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

The description is front-loaded with the core action and scope, then proceeds through usage, related tools, multi-agent constraints, and return behavior. Each section earns its place given the tool's complexity and the absence of annotations or an output schema.

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

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

For a mutation tool with no annotations and no output schema, the description is complete enough: it covers safety, multi-agent ownership, error conditions, parameter disambiguation, and the shape of the returned change_report.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful nuance beyond the schema for allow_active and tab_id, explaining when active tabs may be closed and when tab_id must be supplied, though it does not further clarify visual_reason, client, or is_final.

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 and resource: "Close an agent-owned browser tab without changing the foreground tab." It immediately distinguishes the tool from siblings like open_tab, list_tabs, and switch_tab by naming them in a Related section.

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

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

It gives explicit when-to-use guidance: clean up background tabs after work is complete. It also states the default refusal to close the active tab and the narrow condition for allow_active:true, plus related alternatives.

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

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

With no annotations, the description carries the full behavioral burden and delivers: a hard security constraint (never include passwords, tokens, API keys, or sensitive form values), multi-agent scoping semantics with a named rejection error (TAB_NOT_OWNED), and a configurable cap (default 8, 1-64). This is unusually rich behavioral context for a completion 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 action and completion condition, then layers constraints in descending priority. Dense and slightly run-on in the multi-agent clause, but essentially every sentence earns its place.

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

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

No annotations and no output schema, so the description must carry the full load, and it does: trigger condition, safety rules, multi-tab and multi-agent semantics, and session-token scoping. Nothing an agent needs to invoke 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%, so the baseline is 3, but the description adds real meaning beyond the schema: tab_id is scoped to multi-tab/session disambiguation and session_token is restricted to sessions started by start_visual_session. It does not, however, clarify summary formatting or length limits.

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 terminal state ('Signal that the task is fully complete') and clearly distinguishes itself from siblings like partial_task, fail_task, and stop_task by defining the exact completion condition. An agent can route correctly without opening the schema.

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

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

Gives an explicit ONLY-call-when condition ('all data collected, all entries made, all actions performed') and conditional guidance for both optional params: tab_id when multiple tabs could be active, session_token only for client-owned visual sessions created by start_visual_session. Alternatives and exclusions are 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?

No annotations are provided, so the description carries the full burden and does so well: it discloses cross-agent rejection with TAB_NOT_OWNED, tab ownership semantics, a configurable concurrency cap (default 8, range 1-64), and detailed return behavior including the change_report structure and truncation handling. This is exactly the behavioral context an agent needs for an unannotated mutation tool.

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

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

Front-loaded with purpose and usage before the denser multi-agent and return sections, which is the right ordering. It is somewhat verbose and the 'Returns click confirmation' line is redundant with the later RETURNS block, but each section is purposeful.

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

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

For a complex, unannotated, no-output-schema tool, the description covers purpose, usage, ownership/error semantics, and return shape (change_report plus truncation fallback). 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 schema already documents all five parameters. The description's note that tab_id should only be passed when the agent owns multiple tabs largely restates the schema's own tab_id description rather than adding new format or syntax meaning. Baseline 3 is appropriate 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 (double-click) and resource (element), and immediately distinguishes itself from siblings by naming click, select_text_range, and get_dom_snapshot as related-but-different tools. An agent can route between double_click and click 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?

Explicit 'When to use' clause with concrete scenarios (selecting a word, opening items in file managers, activating edit mode) plus a 'Related' clause naming the alternatives and their distinct roles. When-to-use and when-to-use-something-else are both covered.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses CDP trusted events, the exact event sequence (two mousePressed/mouseReleased cycles, clickCount=2 on the second), modifier support, coordinate semantics, multi-agent tab ownership behavior with TAB_NOT_OWNED and a configurable cap (default 8, 1-64), and the change_report return including truncation handling.

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

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

Front-loaded with purpose, then usage, related tools, multi-agent notes, and return behavior in a logical order. Dense but nearly every sentence earns its place; the multi-agent and change_report paragraphs are long and slightly overlap with what the schema says about tab_id.

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 coordinate-action tool with no output schema, the description is complete: it covers invocation semantics, coordinate system, modifiers, concurrency/ownership rules, and even describes the change_report payload and truncation escape hatch so the agent need not call read_page reflexively.

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 beyond the schema: it clarifies that coordinates are viewport-relative CSS pixels, that modifiers are applied during the double-click, and gives guidance on when to pass tab_id (only when the agent owns multiple tabs; auto-resolves otherwise).

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 ('Double-click at specific viewport coordinates') and immediately distinguishes itself from siblings by naming click_at (single click), double_click (DOM by selector), and insert_text. An agent can route correctly without opening any schema.

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

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

Explicit 'When to use' section names concrete scenarios (Excalidraw text boxes, Google Sheets cells, contenteditable word selection) and a 'Related' section contrasts each alternative. When-to-use and alternatives are both 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?

No annotations are provided, so the description carries the full burden. It discloses the emitted event sequence (mousePressed, N mouseMoved, mouseReleased), modifier-key support, coordinate semantics, multi-agent tab scoping, and the change_report shape. These are genuine behavioral disclosures. However, it does not explain what happens when coordinates fall outside the viewport, how failures surface, or whether steps affect reliability, leaving some behavioral ground uncovered for a trusted-event CDP action.

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

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

Front-loaded with the core action and its event mechanics, then alternatives, then multi-agent rules, then the return contract. The change_report paragraph is long but justified because no output schema exists. Minor redundancy between the description's modifier note and the schema's shift description keeps it from a 5.

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

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

With 13 parameters, no output schema, and no annotations, the description covers everything an agent needs: coordinate basis, event sequence, sibling disambiguation, tab ownership behavior, and the full change_report return contract including truncation and the read_page fallback.

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

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

Schema description coverage is 100%, so the schema already documents all 13 parameters, including modifiers, steps, stepDelayMs, tab_id, and visual_reason. The description restates coordinate semantics ('CSS pixels relative to the browser viewport') and the shift constraint without adding format or edge-case guidance beyond the schema. 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 ('Drag from one viewport coordinate to another using CDP trusted events') and immediately differentiates itself from drag_drop, drag_variable_speed, click_at, and click_and_hold by naming each sibling and its distinct mechanism.

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

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

Explicitly names when to use it ('canvas drawing tools, sliders, and map interactions where DOM drag events are ignored') and routes the agent elsewhere for element-to-element drag, CAPTCHA drags, and simple clicks. Also gives the tab_id ownership rule and the cross-agent TAB_NOT_OWNED failure mode.

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

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

With no annotations, the description carries the full burden and does so: it discloses the three-method fallback order (HTML5 DragEvent, PointerEvent for react-beautiful-dnd, MouseEvent), that it reports which method succeeded, the multi-agent tab ownership rule (cross-agent reject with TAB_NOT_OWNED, cap default 8 range 1-64), and tab auto-resolution behavior. These are non-obvious operational traits an agent could not infer from the schema.

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

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

Front-loaded with purpose, then use cases, alternative, related tools, multi-agent constraints, and return behavior in a logical order. It is long, but the length is justified by the tool's complexity; the only mild redundancy is re-explaining the change_report after already covering returns.

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, so the description must explain returns, and it does so thoroughly: the change_report field contents (URL, dialogs_opened, nodes_added/removed, attrs_changed, inputs_changed, focus_shift), its truncation flag/hint, and the read_page fallback. Combined with the method fallback and tab constraints, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so the schema already documents all nine parameters including tab_id semantics and the steps/holdMs/stepDelayMs timing knobs. The description restates tab_id usage ('pass only when this agent owns multiple tabs; auto-resolves otherwise') and frames source/target as element references, but adds little beyond what the schema states, so the baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Drag and drop one DOM element onto another using element references,' and immediately scopes it as interaction between two identifiable DOM elements. It explicitly distinguishes itself from the coordinate-based sibling ('For canvas/coordinate-based drag, use the drag tool instead') and from drop_file, so an agent can route correctly without opening any schema.

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

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

Gives concrete when-to-use cases (Kanban reordering, sortable lists, file drag targets) plus the explicit when-not-and-use-instead rule pointing to the drag tool. It also lists related tools (drag, drop_file, get_dom_snapshot) with one-line disambiguation for each, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses the emitted event sequence (mousePressed / N mouseMoved / mouseReleased), the slow-fast-slow delay behavior, the multi-agent ownership constraint with the TAB_NOT_OWNED rejection, and the configurable cap (default 8, 1-64). It omits any statement of safety/reversibility for what is an input-simulating action, which keeps it short of a 5.

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

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

Front-loaded correctly: purpose, event sequence, use case, and the sibling alternative all come before the ancillary notes. It is on the long side — the multi-agent and change_report paragraphs are verbose — but each section is scoped and none is filler.

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

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

There is no output schema, so the description must describe returns, and it does: the change_report fields (URL, dialogs_opened, nodes_added, nodes_removed, attrs_changed, inputs_changed, focus_shift), the truncation flag/hint, and the escalation to read_page. Combined with purpose, exclusion criteria, error case, and tab scoping, 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 description coverage is 100%, so the baseline is 3. The description supplies conceptual context for the timing parameters (the slow-fast-slow curve explains what steps/minDelayMs/maxDelayMs are doing) and repeats tab_id ownership semantics, but adds no syntax, ranges, or defaults beyond what the schema already documents.

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

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

States a specific verb+resource with precise scope: 'Drag from one viewport coordinate to another at variable speed using an ease-in-out timing curve.' It names and differentiates its siblings — 'drag (uniform-speed drag for canvas/maps)' and 'drag_drop (DOM element-to-element drag)' — so an agent can disambiguate without opening a schema.

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

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

Explicit when-to-use with an alternative: 'Essential for slider CAPTCHAs and puzzle CAPTCHAs where constant-speed drag is detected as bot behavior. For uniform-speed drag (canvas drawing, map panning), use the regular drag tool instead.' It also lists related tools and their distinct scopes.

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

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

With no annotations, the description carries the full burden and does so: it discloses the synthetic File construction, the exact event sequence dispatched, multi-agent tab ownership rules with the TAB_NOT_OWNED cross-agent rejection, the configurable concurrency cap (default 8, range 1-64), and when tab_id is required. It also documents the change_report return, its fields, and the truncation behavior.

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

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

Front-loaded with the core action and mechanism, then alternatives, then the operational notes and return shape. Nearly every sentence earns its place, though the multi-agent/tab-ownership and cap paragraph is dense enough to slightly dilute the main guidance.

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 tool with no output schema, it covers execution mechanics, concurrency semantics, and the return payload including the truncated/hint fallback to read_page. The one notable gap is that the sibling upload_file is never mentioned, so the distinction between dropping a file onto a dropzone and uploading via a file input is left implicit.

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

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

Schema coverage is 100%, so the schema already documents all eight parameters and the baseline is 3. The description adds genuine context for tab_id (ownership-based resolution) and clarifies how fileName/fileContent/mimeType combine into the synthetic File, but it adds nothing for selector, client, visual_reason, or is_final beyond the schema.

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

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

States a specific verb and resource ("Simulate dropping a file onto a dropzone element") and explains the mechanism: a synthetic File plus an HTML5 DragEvent sequence (dragenter, dragover, drop). It explicitly distinguishes itself from drag_drop for DOM-element dragging, so an agent can route correctly without opening either schema.

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

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

Names the target use cases concretely (Dropzone.js, react-dropzone, native HTML5 drop handlers) and gives an explicit exclusion with the alternative: "For drag-and-drop of DOM elements (not files), use drag_drop instead." It also points to get_dom_snapshot for finding dropzone selectors.

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

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

With no annotations, the description carries the full burden and does so: it discloses the exact return behavior (typed TOOL_REMOVED error plus a migration recipe pointer) and the lifecycle semantics that replaced it. An agent knows calling this is a no-op that yields a structured error, not a state mutation.

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 removal notice is front-loaded in brackets before any explanation, and each subsequent sentence earns its place by naming the error type, the two replacement mechanisms, and the migration docs. No 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 deprecated stub with no output schema, the description covers everything an agent needs: don't call it, what happens if you do, and exactly what to do instead, including doc pointers.

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 enum on reason is documented in-schema, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already states, which is acceptable given the tool is a removed stub.

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 immediately and unambiguously states the tool's current status and behavior: it was removed in v0.9.0 and calling it returns a typed TOOL_REMOVED error. This is a specific, actionable purpose that an agent can distinguish from start_visual_session and every action tool 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 explicitly says when NOT to use this tool and names the alternatives: sessions now clear automatically after 60s of silence or immediately when an action tool is called with is_final: true. That is a complete routing instruction with no inference required.

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

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

With no annotations, the description carries the full burden and does so thoroughly: code runs as a function body, `return` is required, results are stringified, Promises are NOT awaited (poll on window.__yourKey), multi-agent tab scoping with TAB_NOT_OWNED rejection, a configurable cap of 8 (1-64), and a returned change_report with truncation behavior. This is behavior an agent could not infer from the schema.

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

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

Front-loaded and clearly sectioned ('Typical patterns:', 'FALLBACK TO NATIVE TOOLS WHEN:', 'RETURNS change_report:'), with concrete code snippets the agent can adapt. Dense but nearly every sentence earns its place; the repeated advise-to-verify-with-read_page/get_page_snapshot is slightly redundant but purposeful.

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?

Although there is no output schema and no annotations, the description documents the return payload (change_report fields: URL, dialogs_opened, nodes_added/removed, attrs_changed, inputs_changed, focus_shift) and its truncation flag, plus execution semantics and fallback policy. Nothing needed to invoke or interpret the call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: tab_id should only be passed when the agent owns multiple tabs (auto-resolves otherwise), is_final clears the visual session on resolution, and `code` semantics (no awaited Promises, stringified returns) extend the schema's terse 'use return to send a value back'.

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 ('Run JavaScript directly in the active page') with an explicit statement that it is the PRIMARY INTERACTION TOOL for DOM work. It is immediately distinguishable from siblings like click, type_text, and drag_drop, which it deliberately enumerates as fallbacks.

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?

Exceptional routing guidance: 'try execute_js FIRST' plus a numbered FALLBACK TO NATIVE TOOLS WHEN list specifying exactly when native click/type/drag must be used (swallowed synthetic events, React controlled inputs, drag libraries, validated form submission). Both when-to-use and when-not-to-use are explicit.

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

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

With no annotations, the description carries the full burden and delivers unusual value: a hard prohibition on including secrets/tokens/form values, cross-agent rejection semantics with the TAB_NOT_OWNED error code, and agent-scoped tab ownership. It still doesn't say what happens to the session/task afterward (does it terminate the run?) or what the outcome looks like, and the trailing 'cap (default 8, 1-64)' is never explained.

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

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

Front-loaded with the action and the safety constraint, and every sentence is purposeful. The final 'Multi-agent: ... cap configurable (default 8, 1-64)' is telegraphic and ambiguous about what is being capped, which slightly hurts readability.

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/terminal-state tool with no annotations and no output schema, it covers safety, ownership, error behavior, and parameter conditions well. Missing are the post-call consequences (task/session state after failure) and the meaning of the mentioned cap, so it is not fully self-contained.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds conditional semantics the schema lacks: tab_id is for disambiguating when multiple tabs/sessions are active, and session_token applies only to a client-owned visual session created by start_visual_session. That materially improves correct invocation of the optional params.

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 outcome: 'Signal that the task cannot be completed,' which is unambiguous against siblings like complete_task, partial_task, and stop_task. It also clarifies the alternative behavior it replaces ('instead of just stopping'), so an agent can pick it 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 a clear triggering condition ('unrecoverable problem') and a when-not for session_token ('otherwise omit it and keep the normal task-failure semantics'), plus conditional guidance for tab_id when multiple tabs are active. It stops short of naming the nearest alternative tools (partial_task vs. fail_task) explicitly, so it is strong but not a full routing instruction.

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

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

With no annotations, the description carries the full burden and does so richly: the password never crosses the WebSocket bridge, the domain is resolved internally for security, the vault must be unlocked, and cross-agent access is rejected with TAB_NOT_OWNED. These are exactly the security and failure-mode details an agent needs before invoking.

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

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

Front-loaded with what the tool does, then security model, then multi-agent/tab behavior. Five dense sentences each carry information, though the domain backward-compatibility point is stated twice (description and schema).

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

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

For a sensitive 2-param mutation of a login form with no output schema and no annotations, the description covers prerequisites (unlocked vault), security (credential never leaves extension), multi-agent ownership, and the error code — 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% and the schema already documents that domain is ignored/derived and how tab_id resolves. The description largely restates this, so beyond the baseline 3 it adds little 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+resource (auto-fill login form) with the exact target (saved credential on the active tab). This is clearly distinguishable from siblings like list_credentials (which only lists) and use_payment_method (different resource).

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 when to pass tab_id (only when the agent owns multiple tabs) versus omitting it (auto-resolves otherwise), and flags the prerequisite that the vault must be unlocked. It doesn't explicitly name alternatives, but the use case is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose agent-scoped tabs, cross-agent rejection with a specific error code, and a configurable cap (default 8, 1-64). It also explains the change_report return and truncation behavior. It stops short of stating permission/auth requirements or reversibility, so not a full 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?

Purpose is front-loaded in the first sentence, and the when-to-use and related-tool guidance follows logically. The RETURNS change_report block is somewhat verbose but earns its place since there is no output schema; overall tight despite the length.

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

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

With no output schema, the description compensates by detailing the change_report fields and truncation/hint behavior. Combined with ownership rules, error code, and cap limits for a 7-parameter mutation tool, an 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 the schema already documents all seven parameters including tab_id disambiguation, csvData format, and is_final semantics. The description's note on tab_id ('only when this agent owns multiple tabs; auto-resolves otherwise') largely restates the schema, 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?

States a specific verb and resource with scope: 'Fill cells in a spreadsheet starting from a given cell with CSV data.' It names the sibling read_sheet and navigate as related, so an agent can position this tool among many sheet/page tools without opening a schema.

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

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

Explicit when-to-use ('for bulk data entry into Google Sheets') plus related-tool routing (read_sheet to read before filling, navigate to go to the spreadsheet first). Multi-agent ownership rules and the TAB_NOT_OWNED rejection condition are also spelled out, leaving little to inference.

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

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

No annotations are provided, so the description carries the full burden and does well: it discloses the return value ('focus confirmation'), multi-agent tab scoping, the TAB_NOT_OWNED cross-agent rejection, and a configurable cap (default 8, 1-64). It omits any permission/auth prerequisites or failure modes beyond tab ownership, but the behavioral coverage is unusually strong for a focus 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 action, then segments 'When to use', 'Related', and 'Multi-agent' into scannable clauses. Dense but every sentence adds distinct, actionable information with no filler.

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

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

For a focus tool with no output schema and no annotations, the description supplies the return value, the related-tool map, and the multi-agent/tab-ownership model. 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 description coverage is 100%, so the schema already documents all five parameters including client, tab_id, is_final, selector, and visual_reason. The description reiterates tab_id resolution semantics ('pass only when this agent owns multiple tabs; auto-resolves otherwise'), which is minor added value; baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Move keyboard focus to an element') and separates itself from siblings by naming type_text, press_key, and click with their relationships. An agent can distinguish this tool from the many click/type tools without opening any schema.

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

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

Explicit 'When to use' clause covers both the input-preparation and accessibility-focus-ring cases, and 'Related' names alternatives with the condition that selects each. Nothing about when-to-use-vs-alternatives is left to inference.

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

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

With no annotations, the description carries the full burden and does add real behavior: agent-scoped tabs, cross-agent rejection with the TAB_NOT_OWNED error code, and tab auto-resolution. It omits edge cases such as what is returned when the attribute is absent, and the stray "cap configurable (default 8, 1-64)" reads like it belongs to a tab-listing tool and is confusing here.

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 is front-loaded and the description is organized into clear When-to-use, Related, and Multi-agent segments. The multi-agent segment is dense and the tab-cap clause is likely irrelevant noise for a single-attribute read, slightly diluting an otherwise tight definition.

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 tool with no output schema or annotations, the description covers usage, alternatives, and multi-agent ownership adequately. It stops short of describing the return when the attribute is missing, but nothing critical for correct invocation is absent.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the description's attribute examples (href, src, value) largely restate them. It does reinforce the tab_id auto-resolution rule, but adds little beyond the schema, warranting 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 ("Get an HTML attribute value from an element") and the return ("Returns the attribute value"). It explicitly names the sibling reads it is distinct from (get_text, get_dom_snapshot), so an agent can route without opening other schemas.

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

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

Provides an explicit "When to use" clause enumerating the exact cases (href, src, value, data attributes, ARIA properties) and a "Related" line disambiguating get_text and get_dom_snapshot. Both the when and the alternatives are stated rather than inferred.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the return shape (tag, text, attributes, position), the error code TAB_NOT_OWNED for cross-agent access, agent-scoped tab ownership, and the tab cap. It stops short of explicitly stating read-only semantics and the cap's relation to maxElements is ambiguous, keeping it out of 5 territory.

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 critical 'When to use' guidance is front-loaded and every clause carries information, but the trailing multi-agent/cap sentence is dense and introduces a number that conflicts with the schema default, mildly muddying an otherwise tight structure.

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

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

For a no-annotation, no-output-schema read tool, the description covers purpose, usage trigger, return shape, and multi-agent behavior, so an agent has what it needs. The unresolved cap-vs-maxElements discrepancy is the only material gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the tab_id ownership rule ('pass tab_id only when this agent owns multiple tabs') which the schema already documents, and it never explains maxElements, instead referencing a differently-scaled 'cap (default 8, 1-64)' against a schema default of 2000, so it adds no clarifying value.

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 a structured DOM snapshot with element references') and immediately differentiates itself from siblings by naming read_page as the quick-text alternative. An agent can tell it apart from get_page_snapshot and get_text without opening any schema.

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

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

Explicitly says 'BEFORE any interaction tool (click, type_text, etc.)' as the trigger condition, and the 'Related' line routes the agent to read_page for plain text and to click/type_text/hover as consumers of the refs. Both when-to-use and the alternative are stated, not 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?

No annotations are provided, so the description carries the burden. It does add valuable behavioral context by disclosing that results include an error/warning summary report, which is not in the schema. However, it says nothing about ordering, retention window for 'recent', truncation behavior, or that the call is a non-mutating read.

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 what it returns and follow-up with when to use it; every sentence carries information. Minor waste in the slightly generic 'understand what FSB has been doing' phrasing, and 'FSB' is an unexplained acronym.

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 two-optional-parameter read tool with no output schema, the description covers the retrieval modes and hints at the return content (error/warning summary), which is enough to call it correctly. Missing only ranking/retention specifics and sibling disambiguation, neither of which is essential here.

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

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

Schema coverage is 100%: the schema already documents 'count' (default 50, max 200, ignored when sessionId is provided) and 'sessionId' (filter to one session). The description only restates the session-scoping idea and adds no syntax or interaction detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource (get automation logs) and names both retrieval modes: recent logs or logs for a specific session. It also discloses the payload ('error/warning summary report'), so the agent knows what it gets. It stops short of differentiating itself from adjacent siblings like get_session_replay or get_session_detail.

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 to debug issues or understand what FSB has been doing' gives a clear purpose context for when to reach for this tool. There are no exclusions or explicit alternatives (e.g., when to prefer get_session_detail or replay_session instead), so it lands at clear-context-without-routing rather than 5.

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

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

No annotations are provided, so the description carries the full burden. It is implicitly a read-only aggregate query and discloses what is returned, which is helpful, but it says nothing about cost, permissions, or whether the counts are scoped/filtered — thin disclosure for a tool with zero annotation coverage.

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

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

Two sentences, front-loaded with what the tool returns before the usage note. Tight and waste-free, though the second sentence is more soft framing than load-bearing information.

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

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

With no output schema, the description compensates by naming the returned fields (total count, type breakdown, storage usage), which is what an agent needs to decide whether to call it. The remaining gap is the absence of any sibling routing against search_memory.

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; there are no parameter semantics the description could add or omit.

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 (Get) and resource (FSB memory system statistics) and enumerates the return content: total count, type breakdown, storage usage. It does not distinguish itself from the sibling search_memory, which is the nearest related tool, so it stops short of a 5.

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

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

"Use to understand how much FSB has learned from past sessions" gives an implied context for when the tool is useful, but there is no explicit when-not guidance and no mention of the alternative search_memory for inspecting actual memory contents rather than aggregate stats.

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

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

With no annotations, the description carries the burden and does well: it discloses multi-agent tab scoping, the cross-agent rejection error (TAB_NOT_OWNED), and a configurable cap (default 8, range 1-64). It stops short of describing output shape/pagination or auth nuances, but the error and limit disclosure is genuinely useful context not present anywhere else.

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 purpose then layers usage, related tools, and multi-agent constraints in a scannable order. It is dense and repeats the schema's tab_id guidance, which is mild redundancy, but every sentence carries operational value.

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

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

There is no output schema, and the description compensates by stating what is returned (markdown DOM snapshot with interactable elements and ref IDs). Combined with usage triggers and the tab-ownership error path, an agent has everything needed to call this correctly for a single-parameter read 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% and the tab_id schema text already explains the single-tab vs multi-tab rule in detail. The description restates the same rule ('pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise'), adding confirmation but no new syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb (Get) and resource (markdown snapshot of the current page DOM), then specifies what the return contains (interactive elements with ref IDs for targeting). It explicitly distinguishes itself from siblings read_page and get_text by their differing outputs, so an agent can choose without opening any schema.

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

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

Gives explicit trigger conditions: 'BEFORE any click/type/interaction' and 'call this at the start of each new page or when you need to find elements.' It also names the alternatives (read_page for plain text, get_text for single element) so the routing decision is unambiguous.

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

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

With no annotations, the description carries full burden and does disclose a non-obvious behavior: in-flight sessions return a partial snapshot with `final: false`, and the full payload only arrives after completion. It also discloses the read-vs-write nature implicitly and output format options. It does not mention permissions or rate limits, but for a read tool the disclosed partial-payload semantics are the key risk and are covered.

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

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

Front-loaded with purpose and usage before the in-flight caveat and related-tools list. Every sentence carries information, though the 'Related:' enumeration is slightly verbose relative to the rest.

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

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

There is no output schema, and the description compensates by describing what the payload contains, the two output formats, and the partial-vs-full return behavior. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so both parameters (sessionId, format enum) are already fully documented in the schema. The description's mention of 'structured JSON or human-readable text report' restates the format parameter rather than adding new semantics. Baseline 3 applies.

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

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

States a specific verb and resource ('Get full detail for an automation session') and enumerates the payload contents (logs, action history, timing). This clearly separates it from siblings like get_logs, get_session_replay, and list_sessions 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 trigger ('Use after list_sessions to inspect what happened') and names three alternatives with their distinct roles: list_sessions (find IDs), get_logs (raw entries), get_task_status (in-flight check). An agent can route between these siblings directly from the text.

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

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

With no annotations, the description carries the burden and does well: it discloses that the manifest is verified and structurally redacted, enumerates what the return contains (step structure, logical tab targets, risk classifications, manifest hash), and explicitly states what is withheld (signing receipts). It stops short of stating required auth or permissions.

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 with zero filler; the core capability is front-loaded and the routing guidance and return contents follow in order of usefulness.

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

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

With no output schema and no annotations, the description adequately compensates by enumerating the manifest's contents and the withheld signing receipts. It is complete enough to call correctly, missing only incidental detail such as permissions or size/format of the manifest.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents sessionId with its source (list_sessions). The description adds no format or constraint detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (Get) plus a precisely qualified resource (the verified, structurally redacted replay manifest for a recorded session). It even names the sibling alternatives it is not (list_sessions, replay_session), so an agent can route without opening schemas.

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

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

Explicitly says 'Use this instead of reconstructing a replay from logs' and then maps the two related siblings to their distinct roles (find a session vs request a consent-gated replay). Both the when and the when-not are supplied.

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

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

With no annotations, the description carries the full burden and does disclose output content plus multi-agent constraints (agent-scoped tabs, TAB_NOT_OWNED cross-agent rejection, cap default 8 max 1-64). However, the tab/cap details are tangential to a guidance-lookup tool and add noise rather than clearly describing freshness, caching, or side-effect-freedom.

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

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

Front-loaded with purpose, then use-cases, then related tools, so the most important content comes first. The trailing multi-agent cap sentence is somewhat disconnected boilerplate that dilutes the otherwise tight structure.

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 one-parameter lookup with no output schema, the description adequately explains what is returned and when to call it. It stops short of clarifying whether guidance is cached/versioned, which matters for repeated calls.

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 'domain' parameter already documents format and examples, so the schema does the heavy lifting. The description adds no syntax or constraint detail beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get site-specific automation guidance for a domain') and enumerates the return content ('selectors, navigation patterns, and tips'). It is clearly distinguishable from the snapshot/text-reading siblings it names.

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

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

Gives explicit triggering conditions: 'when starting work on a new site or when standard selectors fail.' It also names related tools (get_page_snapshot, get_dom_snapshot) as contrasts, though it does not state when NOT to use this tool.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the returned fields (percent complete, current phase, ETA) and a key behavioral constraint, 'Agent-scoped: returns the calling agent's task status only'. It does not explicitly confirm read-only semantics or permission requirements, leaving a small gap.

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

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

Four short sentences, all front-loaded with the core action first, then usage condition, return values, and scope restriction. Every sentence adds information an agent can act on; 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?

A simple zero-parameter read tool with no output schema, and the description compensates by naming the returned fields and the agent-scoping rule. Nothing an agent needs to invoke 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?

The schema declares zero properties, so there is nothing for the description to disambiguate; baseline is 4. The description correctly implies the call needs no arguments, matching the empty 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 ('Check') and resource ('task status') plus scope ('whether a task is currently running and its progress'). It explicitly distinguishes itself from run_task (the monitored task) and stop_task (cancellation), so an agent can route without opening sibling schemas.

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

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

Gives a concrete trigger condition: 'Use to poll status when not receiving progress notifications'. It also names the related tools and their relationship. It stops short of stating when not to use it (e.g., vs. get_trigger_status or session tools), so it is clear context without 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?

With no annotations, the description carries the full burden and does substantial work: it discloses multi-agent tab scoping, the TAB_NOT_OWNED cross-agent rejection, and a configurable tab cap (default 8, range 1-64). What it omits is what happens when the selector matches nothing or multiple elements, which is a relevant failure mode for a read-by-selector 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?

Purpose and return value are front-loaded in two short sentences, and the guidance blocks are compact. The 'cap configurable (default 8, 1-64)' fragment is terse to the point of ambiguity about what is capped, costing it a point.

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

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

For a two-parameter read tool with no output schema, the description covers purpose, return type, alternatives, and the tab-ownership constraint, which is most of what an agent needs. It stops short of describing empty/no-match behavior or whether the read waits for the element to appear.

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, making 3 the baseline. The description restates the tab_id rule ('Pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise') without adding format or edge-case detail beyond the 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 description gives a specific verb+resource ('Get the text content of a specific element') and explicitly states the return ('Returns the element's text'). It also names the sibling tools it must be distinguished from (read_page, get_attribute) and the scope difference, so an agent can select it 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 has an explicit 'When to use' clause ('to read a specific element's text without reading the whole page') plus a 'Related' block that routes the agent to read_page for full-page reads and get_attribute for attribute reads. When-to-use, alternatives, and the selecting condition are all present.

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

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

No annotations are provided, so the description carries the full burden. 'Read' and 'persisted status'/'storage-of-truth' clearly signal a non-mutating authoritative read, and the return-field enumeration adds useful context, but it says nothing about permissions, side effects, or freshness/rate limits.

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

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

Two sentences, front-loaded with the core purpose and followed by the returned fields. Efficient with no filler, though the second sentence is a somewhat long enumeration.

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 enumerates what the response contains (status, watch mode, condition, target tab, owner, value, timing, attention), which is the main thing an agent needs. Given a simple read tool, it is largely complete.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the 'by id' selector but adds no syntax, format, or scoping detail beyond what the schema states, so the baseline of 3 applies.

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

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

States a specific verb and resource (read the persisted status) scoped to a single trigger by id, which naturally distinguishes it from the plural list_triggers and the mutating trigger/stop_trigger siblings. It does not explicitly name those siblings, but the 'one trigger by id' scope makes the boundary clear.

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

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

Usage is only implied: you call it when you already hold a trigger id and want its state. There is no explicit when-to-use guidance and no exclusion or comparison against alternatives like list_triggers or get_task_status.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses multi-agent scoping, the TAB_NOT_OWNED rejection, tab cap behavior, tab_id auto-resolution, and the change_report return format including truncation behavior and fallback to read_page.

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 long but front-loaded and organized: purpose, return, when-to-use, related tools, multi-agent behavior, and the change_report contract. Every section adds information the agent needs, especially since no output schema exists to explain the return value.

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 lack of output schema and annotations, the description provides the missing operational context: routing guidance, multi-agent constraints, error behavior, and return shape. An agent can call this tool correctly and interpret its outcome without needing additional documentation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description restates tab_id ownership guidance that is also present in the schema and adds no material meaning beyond it, 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 specific verb and resource: 'Navigate back one page in browser history.' It explicitly distinguishes this from go_forward and navigate, so an agent can select it without opening schemas. It does not mention the sibling 'back', but the core purpose and primary sibling separation are unambiguous.

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

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

It gives explicit when-to-use guidance: 'to return to the previous page after following a link or navigating away.' It also names alternatives and their purposes: go_forward undoes a go_back, and navigate goes to a specific URL instead. This is actionable routing guidance.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses agent-scoped tab ownership, cross-agent rejection with TAB_NOT_OWNED, the configurable cap default and range, and the mutation-diff change_report behavior including truncation. These are meaningful behavioral traits beyond the schema.

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

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

The description is front-loaded with purpose and usage, then organizes related tools, multi-agent behavior, and return details clearly. It is lengthy for a simple navigation action, but most sentences add actionable context, especially since no output schema exists.

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

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

Given no annotations and no output schema, the description covers the essential call context: purpose, alternatives, multi-agent ownership rules, tab_id resolution, and the shape of the returned change_report. An agent has enough information to invoke it correctly without additional schema explanation.

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 input schema, and the description's tab_id note largely overlaps the schema's own guidance. It adds minor context about auto-resolution, but the schema remains the primary source of 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?

The description states a specific verb and resource: navigate forward one page in browser history, and returns the new URL. It explicitly distinguishes the tool from siblings go_back and navigate, so an agent can identify its role 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 an explicit when-to-use condition ('after using go_back, to move forward again') and names alternative tools (go_back, navigate) with their differing purposes. The tab_id guidance also clarifies when to supply that parameter versus relying on auto-resolution.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return confirmation, multi-agent tab ownership rules, the TAB_NOT_OWNED rejection, a configurable cap (default 8, 1-64), and tab_id auto-resolution. It omits failure/timeout behavior, but covers substantially more than the minimum.

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

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

Front-loads the action, then layers usage, related tools, and multi-agent rules in a compact block. The dense multi-agent sentence is information-rich but slightly crams several distinct behaviors together.

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

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

A hover tool with no output schema and no annotations needs to explain return value and session semantics, and it does ('Returns hover confirmation', tab ownership, cap). Minor gaps around error/timeout handling keep it short of full completeness.

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

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

Schema coverage is 100%, so the schema already documents all five parameters thoroughly. The description restates the tab_id ownership/auto-resolve rule, which is largely redundant with the schema, but adds the concurrency-cap context; 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 ('Move the mouse over an element') and immediately names the siblings it relates to (click, get_dom_snapshot), so an agent can disambiguate without opening schemas.

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

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

Explicit 'When to use' clause gives the exact scenario (reveal dropdown menus, tooltips, hover-activated content before clicking) plus the follow-up pattern via the related click tool, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden and does so well: it discloses multi-agent tab scoping, the cross-agent rejection error (TAB_NOT_OWNED), a configurable cap (default 8, range 1-64), and a detailed change_report return contract including truncation behavior. This is unusually rich behavioral context.

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

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

Front-loaded with the core action, then usage variants, then related tools, then multi-agent and return-value detail. Dense but every sentence is relevant; the change_report block is verbose but serves a real purpose since no output schema exists.

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, so the description must explain what comes back, and it does via the change_report field list and truncation fallback. Combined with usage, prerequisites, and multi-agent constraints, 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 description coverage is 100%, so the parameters are already documented. The description adds some meaning to position values (caret default, end appends, replace_all replaces) and the selector's role, but most parameter detail is redundant with the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Insert text through CDP') and clarifies the default target (caret). It hints at the difference from siblings by listing related tools (type_text, double_click_at, click_at), but does not sharply draw the boundary between itself and type_text.

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

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

Gives clear usage context: default caret insertion, position=end to append, replace_all to replace a field, and the prerequisite that canvas editors require focus first. It names related tools but never explicitly says when to prefer insert_text over type_text, leaving that distinction implicit.

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

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

With no annotations, the description carries the full load and does so well: it discloses that verified T1/T1b capabilities hit the service's real web API inside the authenticated session, that guarded/catalog-tail hits return typed pending/fallback responses, and that mutating capabilities produce real side effects. It omits reversibility/idempotency and rate-limit behavior, so not a 5.

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

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

Three tightly packed sentences, front-loaded with the core action and followed by behavior and error handling; every sentence earns its place. The density of T1/T1b and RECIPE_* jargon slightly taxes readability but does not waste space.

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

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

There is no output schema, and the description compensates by explaining the kinds of results returned (structured result vs typed pending/fallback) and the exact recovery action for each fallback code. For a dispatch tool with zero annotations, 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 schema already documents slug, params, and tab_id. The description only restates that the slug comes from a search_capabilities hit and params must match the hit's JSON-Schema, adding no syntax or format detail beyond structured data. 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 ('invoke a capability by slug') and ties the input source to a named sibling ('from a search_capabilities hit'). An agent can immediately distinguish this from the DOM/action siblings because it names both the operation and the feeder tool.

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

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

Routing is explicit: get the slug from search_capabilities, check the side-effect class before mutating calls, and switch to DOM tools when RECIPE_DOM_FALLBACK_PENDING / RECIPE_LEARN_PENDING / RECIPE_EXPIRED are returned. It lacks a crisp when-not-to-use statement (e.g., prefer direct click/type for one-off actions), so it falls short of the top band.

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

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

With no annotations, the description carries the burden and does useful work: it discloses that passwords are never returned, which is the key behavioral/security expectation for this tool. It stops short of noting auth requirements or whether any filtering/pagination applies.

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

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

Three short sentences with zero waste; the capability and the return-content caveat are front-loaded before the cross-reference to fill_credential.

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

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

No output schema exists, and the description compensates by describing the return shape (domain/username pairs, no passwords). For a zero-parameter read tool in a large browser-automation toolset, nothing needed to invoke 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?

The tool takes zero parameters, so the baseline is 4. The description adds the meaningful detail that output is limited to domain/username pairs, though there are no parameters whose semantics need explaining.

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 (List) and resource (saved credentials) and immediately bounds the result set to domain/username pairs. It is clearly distinguishable from fill_credential, which it names as the action sibling.

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

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

Explicitly routes the agent to fill_credential when the goal is autofilling a login form, which is a clear when-to-use-other signal. It does not, however, state the reverse condition or any prerequisites for calling list_credentials itself.

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

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

With no annotations, the description carries the full behavioral burden and does disclose a meaningful trait: only masked fields (brand, last 4, cardholder name) are returned and full numbers/CVV are never included. It does not mention auth requirements, session scoping, or behavior when no methods are saved, so it falls short of a 5.

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

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

Three short sentences, each earning its place: purpose, return contract, and next-step routing. The most important information (what is listed and what is masked) 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?

No output schema exists, so the description must and does describe the return fields. For a zero-parameter read tool with no annotations, this covers everything an agent needs 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?

The tool takes zero parameters, so there is no parameter semantics to convey; the baseline for a no-parameter tool is 4.

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 saved payment methods') and immediately specifies what the result contains, which distinguishes it from the adjacent use_payment_method tool. An agent can tell exactly what this tool returns 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?

Explicitly routes the agent to the sibling tool for the downstream action: 'Use use_payment_method to fill a checkout form.' This gives clear context for where this tool fits, though it does not state exclusions (e.g., when not to call it) or prerequisites such as an active session or authenticated context.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the shape of the returned summary (task, status, duration, action count, cost), which is genuinely useful, but says nothing about read-only safety, result ordering, or scope (all users? all time?). Adequate but leaves notable gaps.

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

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

Two sentences, zero filler: purpose and return fields first, then routing guidance. Nothing 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 or annotation coverage, but the description compensates by naming the summary fields returned, and the lone parameter is documented in the schema. What remains missing is scope and ordering behavior, which is a minor gap for a simple list 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% and the single `limit` parameter is fully documented there (default all, max 50). The description adds no parameter-level meaning 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?

States a specific verb and resource ('List all past FSB automation sessions') and enumerates the summary fields returned (task, status, duration, action count, cost). It explicitly differentiates itself from get_session_detail and get_logs, so an agent can place it among the ~60 siblings without opening a schema.

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

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

Gives a concrete use case ('find session IDs for deeper inspection with get_session_detail') and names two related tools with their distinct roles. There is no explicit 'when not to use', but the alternative routing is clear enough that selection is unambiguous.

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

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

No annotations exist, so the description carries the burden and does real work: it discloses agent-scoped visibility, the TAB_NOT_OWNED rejection for cross-agent access, and a configurable cap of 8 (range 1-64). It does not say whether exceeding the cap truncates results or errors, which is the one behavioral gap for a listing 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-loaded with purpose and return shape, then usage, then related tools, then multi-agent constraints — a good information ordering. The telegraphic semicolon-dense final sentence ('agent-scoped tabs; cross-agent reject...') is efficient but slightly terse.

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 parameters and no output schema, the description supplies the return fields, the usage trigger, sibling routing, and multi-agent constraints. Nearly complete; the only omission is what happens at the tab cap boundary (error vs. truncation).

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 there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and consistent with the description's no-argument framing.

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 ('List all open browser tabs') plus the exact fields returned (title, URL, active status) and the return shape (array of tab objects). Clearly separable from open_tab/switch_tab/close_tab 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?

Explicit 'When to use: to see all open tabs before switching' plus a Related list naming switch_tab and open_tab with their roles. The agent gets both the trigger condition and the alternatives in one place.

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

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

With no annotations, the description carries the full burden. It usefully discloses the default filtering behavior (only active/attention-state watchers unless include_terminal is set), which is genuine behavioral context. However, it omits permissions, ordering/pagination, and any explicit statement that this is a read-only operation.

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 written sentences with no filler. The default behavior is front-loaded, followed immediately by the flag that modifies it and its purpose.

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

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

For a simple list tool with no output schema, the description conveys the return content (trigger snapshots) and the default scope. It lacks detail on ordering, pagination, or the shape of each snapshot, but nothing essential to invoking 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%, so the baseline is 3. The description adds meaning beyond the schema by documenting the default result set that the optional status filter and include_terminal flag operate against, and it gives a use case for include_terminal that the schema's terse description lacks.

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 ('List persisted trigger snapshots'), which clearly separates it from get_trigger_status (single status) and trigger/stop_trigger (mutations). It does not explicitly name sibling alternatives, so it stops short of a 5, but an agent can identify the tool's role 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 explains the default scope (active and attention-state watchers) and the condition that changes it (include_terminal for 'audit or cleanup workflows'). That gives clear context for when the flag is appropriate, though it never explicitly contrasts with sibling list/status tools or states exclusions.

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

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

With no annotations the description carries the full burden and does so richly: redirect-following return value, agent-scoped tabs, TAB_NOT_OWNED cross-agent rejection, a configurable tab cap (default 8, range 1-64), tab_id auto-resolution, and a full change_report contract including fields and truncation/hint fallback. This is far beyond what structured fields 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?

Front-loads the one-line purpose, then organizes the rest under labeled sections (When to use, Related, Multi-agent, RETURNS change_report). It is dense and somewhat long, but nearly every clause carries actionable information rather than filler.

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

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

With no output schema and no annotations, the description compensates fully: it explains the return value (final URL), the change_report contents, truncation behavior, and the multi-agent tab constraints. 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 description coverage is 100%, so the schema already documents all five parameters in detail. The description largely restates the tab_id ownership/auto-resolve rule rather than adding new per-parameter meaning, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ("Open a URL in the active browser tab") and immediately notes it returns the final post-redirect URL. It also names the adjacent siblings it should be sequenced with (read_page, list_tabs), letting an agent place it without opening any schema.

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

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

Gives explicit sequencing guidance ("as the first step to reach a target website") and routes to follow-on tools via the Related section. It lacks an explicit when-NOT clause (e.g. versus open_tab or refresh), so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden and does so thoroughly: agent-scoped tabs with TAB_NOT_OWNED rejection, configurable cap (default 8, 1-64), default background vs active:true focus-stealing, and the change_report return semantics including truncation handling. This is exactly the operational context an agent needs for a state-mutating UI action.

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

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

Front-loaded with the core purpose and return, then organized into labeled subsections (When to use, Related, Multi-agent, Active behavior, RETURNS). Dense but every section is functional; the change_report paragraph is slightly verbose but earns its place given no output 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?

No output schema exists, so the description properly documents the return (change_report fields, truncation, read_page fallback), plus multi-agent constraints and focus semantics. 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 description coverage is 100%, so the schema already documents url, active, client, is_final, and visual_reason. The description reiterates active's default and adds the change_report return behavior, but adds little parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Open a new browser tab with the given URL') and immediately differentiates from siblings by name (switch_tab, list_tabs, navigate). An agent can tell exactly what this does and how it differs from adjacent tab/navigation 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?

Explicit 'When to use' condition ('work on a different site without losing the current page') plus a Related list that names the alternatives and their distinguishing behavior (navigate changes URL in current tab instead). No inference required to choose between them.

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

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

With no annotations, the description carries the full burden and does so: it forbids embedding secrets, defines the exact retry ordering relative to credential attempts, discloses multi-agent scoping and the TAB_NOT_OWNED rejection, and states a configurable cap (default 8, 1-64). That is substantial behavioral context beyond the schema.

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

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

Front-loaded with purpose and the alternative tool, and nearly every sentence adds a rule. Slight redundancy in listing the five auth/manual blocker examples already present as a schema enum, and the paragraph is dense, 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 6-parameter, annotation-free mutation of task state, the description covers blockers, secret hygiene, retry ordering, tab/session scoping, and caps. It stops short of stating what happens to the task/session after the call (terminated vs. resumable), which is the one remaining behavior an agent would want.

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 conditional usage rules the schema lacks: when tab_id is warranted (multiple tabs/sessions) and when session_token applies (only finalizing a client-owned visual session). It also specifies the three content elements to preserve in the payload.

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 outcome: signaling partial completion when useful work is done but an external blocker stops the final step. It explicitly contrasts itself with fail_task, so an agent can distinguish the two without opening either schema.

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

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

Gives an explicit when-to-use rule ('use this instead of fail_task when the user can still benefit from the completed work'), enumerates the blocker classes that qualify, and adds a sequencing rule to let a single saved-credential/operator-prompt attempt happen first. Both the selection condition and the exclusion are stated.

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

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

No annotations are provided, so the description carries the full burden and does so: it discloses the automatic fallback to clicking the submit button, the cross-agent TAB_NOT_OWNED rejection, the tab cap (default 8, 1-64), and the return payload including change_report fields and truncation signaling.

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

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

Front-loaded with purpose then when-to-use, followed by behavior, related tools, multi-agent rules, and returns. The change_report paragraph is long but justified since there is no output schema; a small amount of overlap with the schema's tab_id text keeps it from a 5.

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

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

With no output schema and no annotations, the description covers the return shape (change_report and its diff fields, truncated flag, change_report_hint), error behavior, tab-ownership rules, and the fallback path. 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 baseline is 3. The description's tab_id guidance ('pass only when this agent owns multiple tabs; auto-resolves otherwise') largely restates the schema text, and the 'cap configurable' note refers to no actual parameter, so it adds little 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 the Enter key') plus the intent (submit a form / confirm input), which immediately separates it from press_key, type_text, and click. The 'Related' line explicitly routes to the nearest 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?

Gives an explicit trigger ('after typing into a search box or form field') and names the alternatives with their selecting conditions (type_text first, click to press the submit button directly). Nothing about when to prefer this over siblings is left to inference.

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

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

With no annotations, the description carries the full behavioral burden and does so: multi-agent tab ownership rules, rejection code TAB_NOT_OWNED, a configurable session cap (default 8, range 1-64), tab_id auto-resolution, and the change_report payload inclurating truncation hints. This is unusually rich disclosure for a zero-annotation tool.

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

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

Purpose is front-loaded in the first sentence, followed by terse labeled sections (When to use, Related, Multi-agent, RETURNS). It is longer than average, but every block carries distinct operational information and no sentence is pure filler.

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

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

For a tool with no output schema and no annotations, the description supplies the missing pieces: return shape (change_report fields), truncation behavior with a follow-up pointer to read_page, cross-agent error semantics, and tab ownership rules. An agent has what it needs to call it correctly and interpret the response.

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 modifiers and key format, giving a baseline of 3. The description edges above baseline by adding usage context for tab_id (pass only when the agent owns multiple tabs; auto-resolves otherwise) and the session cap, which the schema wording does not convey.

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

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

States a specific verb and resource (press a keyboard key) plus scope (optional ctrl/shift/alt modifiers) and explicitly routes to siblings press_enter, type_text, and focus. An agent can distinguish this from all nearby keyboard/input tools without opening schemas.

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

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

Includes an explicit 'When to use' section covering shortcuts, special keys, and key combinations, and names the related alternatives with their differing intent (press_enter for Enter, type_text for full strings, focus to pre-focus). Both the use case and the routing are stated, not inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool waits for DOM stability on JS-heavy sites, prioritizes main content over sidebars/nav/footer, caps output at ~8K chars, enforces agent-scoped tab ownership with a TAB_NOT_OWNED rejection, and supports a configurable cap (default 8, range 1-64).

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 front-loaded with purpose and usage, then proceeds through behavior, related tools, and multi-agent details. Every clause adds information an agent needs; there is 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?

With no annotations and no output schema, the description compensates well by explaining the return content (main content prioritized, capped at ~8K chars), DOM-stability waiting, tab scoping, and error behavior. It gives an agent enough context to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description's tab_id guidance ('Pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise') largely restates what the schema says, adding no new syntax or format detail beyond the structured 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?

The first sentence states a specific verb and resource: 'Read the text content of the current page.' The Related section explicitly differentiates this tool from get_dom_snapshot (structured element data), navigate (navigation), and scroll (loading more content), so an agent can distinguish it from key siblings without opening schemas.

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

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

It gives an explicit usage rule: 'When to use: as the FIRST step after navigating to understand what is on the page.' It also names alternatives with their conditions (get_dom_snapshot for interaction, navigate to go to a page, scroll to load more before reading), leaving little inference for an agent.

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

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

No annotations exist, so the description carries the full burden and does substantial work: it discloses return shape ('array'), multi-agent scoping ('agent-scoped tabs'), a concrete failure mode ('cross-agent reject with TAB_NOT_OWNED'), and a configurable cap ('default 8, 1-64'). It omits auth requirements and other error behaviors, but the multi-agent failure semantics are unusually well surfaced.

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

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

Front-loaded with the core action, then usage, then multi-agent behavior. Dense but every clause is informative; the 'Returns cell values as array' line is marginally redundant with the purpose sentence but still useful given no output schema.

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

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

For a 2-parameter read tool with no output schema and no annotations, the definition covers purpose, return shape, alternatives, prerequisites, and multi-agent constraints. The main gap is error/edge behavior beyond TAB_NOT_OWNED, which is minor for a read operation.

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 documents range format and the full tab_id resolution rule, so the baseline is 3. The description's 'Pass tab_id only when this agent owns multiple tabs; auto-resolves otherwise' largely restates the schema rather than adding new syntax or format detail.

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