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

Adds behavior well beyond the annotations: it refuses on a hidden page, warns that composited_estimate is a guess rather than the compositor's answer, defines fade_only, and explains the 150 ms-transition timing rationale for recording. Annotations declare readOnlyHint=false and idempotentHint=false, which is consistent with the fact that it can trigger click/hover/scroll/press_key actions.

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 capability and output shape, then the two operating modes, then caveats. Dense semicolon-clause sentences pack substantial information with little waste, though the length pushes toward run-on territory.

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

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

With no output schema, the description carries the burden of explaining return values and does so (selector/ref, animated properties, duration, delay, easing, iterations, play state, timeline, composited_estimate, fade_only). It also covers the hidden-page refusal and the reduced-motion workflow. Minor gap: it does not describe the limit/summary interaction that the schema implies.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining the semantic split between snapshot mode and duration_ms recording mode, and by clarifying that optionally an action runs after recording starts. This adds meaning about how parameters interact rather than restating field 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?

States a specific verb and resource ("List the page animations") and enumerates the four animation technologies it covers (CSS animations, transitions, Web Animations, View Transitions), plus the per-item fields it returns. An agent can distinguish this from get_css_styles or watch_dom 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?

Clearly partitions two modes: without duration_ms it is a snapshot of what runs now; with duration_ms it records every animation that starts in the window, optionally after an action. It also routes for a related task ("Pair with emulate_media reducedMotion"). It does not explicitly contrast with sibling listing tools like get_css_styles, so it stops short of a full when/when-not statement.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context about polling timeout and pattern syntax, which is valuable beyond annotations.

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

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

Two sentences with no wasted words. The core functionality and pattern syntax are conveyed efficiently.

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 8 parameters and no output schema, the description covers main conditions, patterns, and replay context. It lacks explicit return behavior but is otherwise sufficient.

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

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

Schema coverage is 100%, so parameters are already well-described. The description adds minimal extra meaning, only summarizing condition types and pattern styles. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: to assert page conditions (element existence/visibility, text, URL/title) with polling until timeout. It distinguishes from siblings by focusing on assertion rather than observation or waiting.

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

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

The description implies use for assertions but does not provide explicit guidance on when to use this tool versus alternatives like wait_for or query_dom. No exclusions or comparison with siblings.

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

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

Annotations already declare read-only, idempotent, and non-destructive, and the description repeats 'Read-only'. It adds useful behavioral details beyond annotations: the output format ('summary line per kind', 'full Markdown report') and the save_to behavior. No contradictions.

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

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

The description is two sentences, compact and well-structured. It front-loads the core purpose ('One-call page audit'), lists all options efficiently, and includes output details without verbosity.

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

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

Given the tool's complexity (5 optional parameters) and the annotations covering safety, the description provides sufficient context: it explains each parameter via schema descriptions and details output behavior. It does not mention edge cases or prerequisites, but the tab_id and scope parameters are self-explanatory from schema descriptions, so nothing critical is missing.

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

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

Schema description coverage is 100% and each parameter has a helpful description. The main description further enriches parameter semantics by explaining what each kind refers to (e.g., 'resources' means which plugin/theme/module/host slows the page) and clarifying default behavior for kinds like keyboard and css. This goes beyond the schema's enum list.

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 explicitly states 'One-call page audit' and enumerates the exact audit kinds (accessibility, keyboard, SEO, security headers, broken links, Core Web Vitals, unused CSS, resources, cache). This clearly identifies the verb (audit), the resource (page), and distinguishes it from specialized siblings like cookie_audit.

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

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

The description says to 'pick the kinds' and lists them, so it's clear when to use this tool for any of those audit categories. It does not explicitly name alternatives or state when not to use it, but the coverage is evident from the kind list, making usage largely implied.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so 'Not idempotent' is largely redundant, but the description adds genuinely non-schema behavior: a native confirm() blocks the bridge and requires handle_dialogs first, and the real pointer sequence can submit/open/navigate. It also describes the return payload (page_changed with DOM deltas) with no output schema present, which is real added value.

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 addressing modes, then behavior, then return shape — no filler sentences. It is dense and slightly long for a single tool, but nearly every clause carries actionable information an agent needs.

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

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

With 9 parameters, no output schema, and only annotations for safety, the description compensates for the missing return documentation by describing page_changed's contents (url, title, DOM deltas, dialogs, focus) and the follow-on refs. An agent has everything needed to call and interpret 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 baseline is 3, but the description adds cross-cutting semantics the schema does not: refs come from get_interactives/navigate, and wait_after is framed as a settle-before-return control. It does not re-derive per-parameter meanings like count or trusted, which the schema already covers well.

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 ('Click an element') and the two addressing modes (CSS selector or ref from get_interactives/navigate), immediately distinguishing it from sibling tools like hover and drag_and_drop. An agent knows exactly what this does without opening the schema.

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

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

Explicitly routes to alternatives ('ref from get_interactives or navigate') and states preconditions ('a native confirm() blocks the bridge: handle_dialogs first') plus the follow-up knob ('use wait_after'). It even tells the agent when it does NOT need a sibling ('when the click opens or reveals something, the refs ... follow, no get_interactives needed').

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

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

The description discloses that write overwrites the clipboard and that this is not recoverable, which is critical behavioral information beyond the annotations. It also notes that the tab is activated first, adding transparency about side effects.

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 exceptionally concise, consisting of two short sentences that pack essential information without anyone. The structure is logical, starting with the core function and then adding the warning.

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?

The description covers the primary function and the critical warning, but lacks guidance on alternative tools or edge cases (e.g., what happens when reading an empty clipboard). Given the absence of an output schema, a bit more context about expected behavior would improve 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?

The schema descriptions already fully explain all parameters (action, text, tab_id) with 100% coverage. The tool description does not add extra semantic meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool reads or writes the system clipboard (text), which is a specific verb and resource. It also clarifies the scope to text, leaving no ambiguity about the tool's function.

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

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

The description does not mention when to use this tool versus alternatives like type_text or read_page. It only mentions 'Activates the tab first' as an operational note, but provides no guidance on appropriate use cases or conditions where another tool would be more suitable.

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?

Beyond the annotations (idempotent, non-destructive), the description explicitly discloses the side effects: clearing cookies, accepting the banner, and logging out. This transparency about state changes exceeds what the annotations alone convey.

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

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

The description is a single run-on sentence but is rich with relevant detail. It front-loads the purpose and follows a logical sequence. Slightly dense, but not verbose—allocating a 4 for clarity and efficiency.

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?

The description covers the full workflow, expected output (findings naming trackers), and side effects (logout). With no output schema, this textual explanation sufficiently equips an agent to understand the tool's behavior and results.

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

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

The schema already provides full descriptions for all three parameters (coverage 100%). The tool description adds no additional parameter meaning, so the baseline score of 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?

Description clearly states the tool's specific function: a cookie and consent-banner audit. It lists the sequence of actions (clear cookies, reload, record before consent, accept banner, record again) and explicitly notes the logout side effect, making the intended purpose unambiguous.

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

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

The description implies the tool is used when auditing tracker behavior before and after consent, and it warns about the logout effect. It does not explicitly compare against alternatives like the generic 'audit' tool, but the specific scenario is clear enough for an agent to select it appropriately.

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

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

The description discloses that the new tab becomes 'the implicit target of later commands in this session' and that each call creates another tab, behaviors not captured by the annotations. This provides critical context about statefulness and side effects beyond the structured hints.

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 primary action and followed by a practical usage tip. Every sentence contributes value with no redundancy.

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

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

The description is fully self-contained for a state-changing tool: it explains the action, the session-wide implication, and the fallback to navigate(). It does not explicitly state the return value, but the mention of 'reuse a tab_id' implies a tab identifier is returned, which is sufficient given the tool's simplicity and the comprehensive schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, merely mentioning the optional URL, which is already documented. It does not introduce new information about parameters.

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

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

The description uses a specific verb ('Open') and resource ('new tab'), clearly distinguishing this from navigation tools. It explicitly contrasts with navigate(), stating 'reuse a tab_id or navigate() to move an existing one instead of piling up tabs.'

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

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

The description provides explicit usage guidance: it tells the agent that each call creates a new tab and recommends reusing a tab_id or using navigate() to move an existing tab, preventing tab accumulation. This addresses when to use the tool versus 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?

Description complements annotations by detailing the specific overlay dismissal approach (vendor-specific plus heuristic). Annotations already mark destructiveHint false and idempotentHint true, and description reinforces idempotency, adding valuable context without contradiction.

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 pack the essential information: what it does, which overlays it targets, and idempotency. No wasted words.

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

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

Given the simple input schema, annotations covering safety and idempotency, and the focused purpose, the description is fully adequate. No output schema needed for this straightforward action.

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% with a clear description for tab_id. The tool description adds the non-obvious default behavior: omitted means last tab navigated or active tab, which is helpful 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?

Description clearly states the tool dismisses cookie banners/modal overlays, listing specific vendor patterns (OneTrust, Cookiebot, Usercentrics) and a generic heuristic. This sets it apart from sibling tools that interact with page elements in other ways.

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 mentions idempotency, signaling safe repeated use. Implicitly suggests use when overlays block interaction. No explicit when-not-to-use or alternatives, but context is clear given sibling tools.

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

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

Annotations already indicate non-destructive behavior. The description adds the event family implementation detail but does not disclose other behavioral traits like timing, side effects (e.g., element reordering), or error scenarios.

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

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

The description is a single, well-structured sentence with no filler. Every word adds meaning, and the semicolon effectively separates the general action from mode specifics.

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 complexity of drag-and-drop (source, target, modes, frames, tabs) and no output schema, the description is adequate but thin. It does not explain return values, waiting behavior, or what constitutes a successful drop.

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?

All 5 parameters have schema descriptions (100% coverage), so the tool description's role is diminished. However, it adds valuable context for the 'mode' parameter by explaining the difference between html5 and pointer events, which goes beyond the schema's 'which event family to emit'.

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?

Description clearly states the action ('Drag an element onto another') and distinguishes by specifying two event families (html5 vs pointer). This verb+resource structure is specific and distinct from sibling tools like click or hover.

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?

While the description explains when to use each mode ('html5 = DragEvent+DataTransfer; pointer = pointer/mouse events'), it lacks explicit guidance on when not to use this tool or alternative approaches. No prerequisites or exclusions are mentioned.

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

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

The description explicitly says 'Read-only,' matching the readOnlyHint and destructiveHint annotations. It also discloses behavior beyond the annotations, such as optional enlargement, output being capped at 1568px, and the selector parameter noting that 'The element is scrolled into view first.'

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 main purpose and keeps additional explanation compact and purposeful. The cost and scale guidance is phrased efficiently, and no sentence is redundant or 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?

The description, combined with the parameter details, gives an agent enough context to call the tool correctly: what it returns (PNG), how to target an element or region, how scaling behaves, and which tab is used. No output schema is present, but the textual description sufficiently covers the output format and key invocation details.

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?

All four parameters have meaningful descriptions that go beyond the schema types. The scale parameter documents its default and bounds, region explains it is a viewport box in CSS pixels rather than a selector, tab_id explains fallback behavior, and selector explains shadow DOM piercing and pre-scroll behavior.

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

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

The description clearly states the tool's function: 'Screenshot cropped to one element or to a viewport region (PNG), optionally enlarged.' It also highlights the differentiating cost benefit, 'The cheapest image in the set, because it carries only the box you asked for,' which helps distinguish it from broader screenshot 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?

The description gives practical usage context by noting it is the 'cheapest image in the set' and that 'with scale the way to read fine print: crop the box, zoom it, verify.' It does not explicitly name sibling alternatives like screenshot or full_page_screenshot, but the cropping and viewport-region framing make the intended use case reasonably clear.

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

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

Adds substantial behavior beyond the annotations (idempotent, non-destructive): the emulation persists only 'until reset or reload', page mode patches matchMedia but leaves @media rules unapplied and zeroes every animation for 'reduce', and debugger mode leaves Chrome's 'started debugging this browser' bar visible until reset:true (avoided in launch mode). These side effects and limitations are exactly what an agent needs and cannot get from the schema or annotations.

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

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

Front-loaded with the core purpose, then organized by mode, and it is informationally dense with no filler sentences. It is long for a single paragraph and repeats 'via debugger' several times, which slightly hurts scanning, but each clause carries distinct technical weight.

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

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

For a complex 12-parameter tool with no output schema, the description covers mode selection, persistence, and caveats thoroughly. It does not state what a successful call returns or confirms, but for an emulation toggle where the observable effect is the page state, this is a minor omission.

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 title/description semantics are already documented (baseline 3). The description goes further by explaining the interaction rules the schema cannot express: which options imply via=debugger, that user_agent does not affect the HTTP header, and that page mode's shim only covers matchMedia. This materially clarifies parameter behavior beyond the field-level descriptions.

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

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

States a specific verb and resource ('Make the page believe it runs elsewhere') and enumerates the exact media features it controls (prefers-color-scheme, reduced motion, print mode, userAgent/platform). It explicitly separates itself from network_rules ('user_agent changes only what page JS reads — the request header is network_rules modify_header') and names viewport_resize as a companion, so an agent can place it among siblings without opening any schema.

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

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

Gives explicit when-to-use guidance for the two modes: 'via page (default for these)' for matchMedia-only patching, and 'via debugger' when the site's own @media rules must really apply, adding contrast, CPU throttling, network profiles, viewport DPR and touch (which imply via debugger). It also states when reset is needed ('until reset: true') and routes header-only overrides to a sibling.

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 annotations declaring destructiveHint=true and openWorldHint=true, the safety profile is already covered, and the description adds real operational context: the required toggle with a self-explaining error path, promise awaiting up to timeout, and truncation that preserves valid JSON. It does not discuss what page state the arbitrary JS can mutate, but the value added beyond annotations is substantial.

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

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

Four tight sentences, front-loaded with the core action, then prerequisites, then async and truncation behavior. No sentence is filler; every clause carries operational information.

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

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

For a six-parameter tool with no output schema, the description covers the setup gate, the timeout contract, and the truncation/save_to relationship. It omits how returns are shaped for non-serializable values and says nothing about targeting tabs/frames, but is otherwise sufficient to call correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains the truncation contract and that save_to writes the untruncated result to disk, clarifying how max_length and save_to interact. tab_id and frame_id defaults are left to the schema.

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

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

States a specific verb and resource ('Run JavaScript in the page') and pins the execution context as MAIN world, which distinguishes it from DOM-querying siblings like query_dom and inject_css. It stops short of naming an explicit alternative, so it is clear but not maximally differentiating.

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 prerequisites ('Requires the extension's Allow user scripts toggle') and async behavior, but never says when to reach for this over extract, query_dom, or inject_css, nor when it is inappropriate. The agent must infer the use case from the verb alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful context: deterministic, parsed server-side from main-document HTML. This adds value beyond annotations.

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

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

The description is a single, well-structured sentence that front-loads the purpose. Every part adds value with no wasted words.

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

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

Given the tool's complexity (7 params, nested object, no output schema), the description covers the core usage and behavioral context. It lacks explicit mention of defaults or output format, but schema descriptions fill that gap.

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

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

Schema coverage is 100% with descriptions for all 7 parameters. The description adds a general pattern explanation but does not provide details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool reads repeated non-tabular structures as records per item, with specific examples (product cards, list items, search results). It distinguishes from siblings like extract_table by specifying 'non-tabular'.

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

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

The description implies when to use (non-tabular structures) and hints at alternatives (extract_table for tables), but does not explicitly state when not to use or list alternatives. The context is clear enough.

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

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

Annotations already declare readOnly/idempotent/destructive=false, so the bar is lower, and the description still adds real context: server-side filtering and its byte-cost behavior, plus how row_count relates to match_count (post-filter). It omits error/empty-match behavior, but the added behavioral detail is well above annotation coverage.

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

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

Three tight sentences, front-loaded with what is returned, then the eligibility constraint, then the filter/count semantics. 'Read-only' is mild redundancy against the readOnlyHint annotation but the rest earns its 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?

With no output schema, the description correctly carries the return-shape burden (thead→keys, rows→objects) and distinguishes total vs filtered row counts. Given 8 optional params and nested `where` objects, it is largely complete, though it says nothing about empty matches or error cases.

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

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

Schema description coverage is 100%, so the schema already documents all 8 params including `where`, `index`, `offset` and `max_rows`. The description's mention of `where` filtering is useful framing but largely restates what the schema says, and its `row_count`/`match_count` detail describes output fields rather than parameters.

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

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

States a specific verb+resource ('Read a real <table> as JSON') plus the exact output shape (thead cells become keys, each row an object). The clause 'Only for tabular markup' separates it from broader siblings like read_page, query_dom and extract, so an agent can route 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 scope restriction ('only for tabular markup') and explains the payoff of the server-side `where` filter (one row out of 1500 costs a few hundred bytes). It never names a concrete alternative tool to use instead for non-tabular content, so the 'when not / use instead' side is implied rather than stated.

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

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

The description adds substantial behavior beyond the annotations: it warns that a repeated call with submit_selector submits twice and is not safe to retry blindly (consistent with idempotentHint=false), and it details post-submit/lateral reporting (after_submit url/title/gained text, per-field value_after and mismatch, page_changed DOM delta). This is exactly the operational detail annotations cannot convey.

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

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

It is front-loaded with the core action and control-type coverage, then layers the selector/ref mechanic, the submit caveat, and reporting. It is dense but every sentence carries load; the return-value detail in the final clauses makes it slightly heavy for two sentences.

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

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

There is no output schema, so the description correctly compensates by explaining what comes back (after_submit, value_after, mismatch, page_changed refs). For a 6-parameter, non-idempotent mutation tool, the agent has enough to call it safely.

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

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

With 100% schema description coverage the baseline is 3, but the description adds cross-parameter meaning: it clarifies that fields and submit accept either a CSS selector or a ref from navigate/get_interactives, and ties the submit parameters to the double-submit consequence. This goes modestly beyond the per-parameter schema text.

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

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

The description gives a specific verb and resource ("Batch fill form fields with React-compatible events") and enumerates exactly which control types it covers (input, select, checkbox, radio, textarea). This clearly separates it from siblings like read_form (reading) and type_text (single-field typing) without opening any schema.

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

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

Usage context is implied rather than explicit: it explains that refs come from navigate/get_interactives and that submit_selector triggers a submit, but never states when to prefer this tool over alternatives such as type_text, click, or read_form. The reader can infer the workflow but is not routed.

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

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

The description discloses that the tool navigates the tab and leaves it on the found page, which is a side effect not captured by the annotations. It also explains the iterative behavior of following menu links and stopping at max_pages. This goes beyond the annotation hints and provides useful behavioral transparency.

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 concise, two sentences, with no redundant content. It front-loads the purpose and then explains the behavior and constraints. Every phrase adds value, and the structure is easy to parse.

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

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

The description explains the core mechanism but lacks explicit details about the return format ('reports the menu path' is vague), what happens if the keyword is not found, or how it handles pages that fail to load. Since there is no output schema, these details would be useful for an agent to fully anticipate results.

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?

All four parameters have schema descriptions with 100% coverage, so the baseline is 3. The tool description does not add significant extra semantic detail about the parameters beyond what the schema already provides (e.g., keyword is described as 'What you are looking for' in both places).

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 clearly states the tool's purpose: to locate a setting in an unknown admin panel by clicking through menu links until the keyword is found, then reporting the menu path. This distinguishes it from other search-related tools like find_text or query_dom, which operate on the current page only.

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

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

The phrase 'in an unknown admin panel' and the mechanism of following menu links give clear context for when this tool is appropriate. It also mentions the max_pages limit and the fact that it navigates the tab, which helps agents decide if this tool fits their need. However, it does not explicitly contrast it with alternatives.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details about attaching nearby interactive elements with refs for interaction. This is valuable context beyond annotations, though it does not cover edge cases like no match found.

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

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

The description is two concise sentences, front-loaded with the core purpose, followed by an important behavioral detail. No wasted words.

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

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

Given no output schema, the description adequately explains the return values (parent selector, context, visibility, position, interactive elements). It covers the main aspects but could be more explicit about the list of matches and behavior when no match is found.

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 parameters are well-described in the schema. The description does not add additional meaning or usage hints for parameters beyond what the schema provides. The mention of 'parent selector, context, visibility, position' refers to output, not parameters.

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

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

The description clearly states the tool finds text on a page and specifies what it returns: parent selector, context, visibility, position per match, and attached interactive elements for the first visible match. This is specific and distinguishes it from sibling tools like query_dom or get_interactives.

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

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

The description implies usage for finding text and obtaining interactive elements, but it lacks explicit guidance on when to use this versus alternatives like query_dom. No when-not-to-use conditions or prerequisites are mentioned.

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

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

Annotations only carry the generic safety profile, and the description adds substantial behavioral context: it refuses on hidden pages because rAF/observers stop, synthetic events yield no interaction id, compositor-only animations can stay smooth while the main thread drops frames, and an action can run right after recording starts. These are genuine operational traits not visible in structured fields.

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

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

Front-loaded with the core purpose and tightly information-dense, with no filler sentences. It is long and parenthetical-heavy (render/style layout start, CLS/INP window caveats), which slightly taxes readability, but nearly every clause carries real meaning.

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 tool with a nested action object and no output schema, the description fully explains the returned metrics (frame rate, dropped frames, LoAF details, shifts with moved elements, INP split into input delay/processing/presentation) plus the hidden-page and trusted-input constraints. Nothing essential is missing.

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

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

Schema description coverage is 100%, so all six parameters (limit, action, tab_id, frame_id, duration_ms, threshold_ms) are already documented. The description adds the action types (click, hover, scroll, key) and the trusted-input requirement, but this only marginally extends what the schema already 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 (record) and resource (the page/frame performance window) and enumerates exactly what it reports: frame rate, dropped frames, LoAF, layout shifts, INP. An agent can distinguish this from perf_trace, lighthouse, and animations 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?

Implied usage is clear from the metric set (use it to measure smoothness/interaction responsiveness over a window), and it notes constraints like needing trusted input for INP. But it never names an alternative (perf_trace, lighthouse, animations) or states when this is preferred over 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?

Describes scroll behavior, segment stitching, token costs, and limits (max_scrolls, max_segments, offset). Consistent with readOnlyHint and idempotentHint; no contradiction, and the cost information adds transparency.

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 well-structured, front-loading the core purpose, then cost, then usage guidance. It is concise and contains no filler or redundancy, with all sentences contributing to clarity.

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?

The description covers the capture process, cost, when to use, and limits. It does not specify the exact return format (e.g., image URLs), but given the absence of an output schema, the provided information is reasonably complete for an agent to invoke 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 descriptions are already thorough (100% coverage) and meaningfully explain each parameter. The description adds context about cost per segment, which enhances the understanding of max_segments, though not all parameters are further elaborated in the description itself.

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 clearly states the tool's function: full-page capture by scrolling, with stitching or separate viewport images. It distinguishes from other screenshot tools by mentioning the stitching behavior and segment limits.

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 advises when to prefer text-based tools (read_page, extract, find_text) over this screenshot tool, and provides cost trade-offs. This gives clear guidance on when to use it versus alternatives.

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

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive). The description goes well beyond: it discloses that output is scoped to the first selector match, that opaque cross-origin stylesheets are listed by href only, and which CSS features (user-agent styles, @container, @scope) are not evaluated — real behavioral caveats an agent needs.

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

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

Information-dense and front-loaded: the purpose sentence comes first, followed by the distinctive comparison, then caveats, then the parameter note. Slightly long with heavy parenthetical enumeration, but nearly every clause carries signal.

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 the return shape (per-property winning declaration with selector, stylesheet, rule position, importance, layer, media, plus overridden declarations). Combined with the disclosed evaluation limits, an agent has what it needs to call and interpret the tool.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema (shadow-DOM piercing, frame/tab defaults, inherited handling). The description only restates that 'properties narrows the output', adding no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource — resolving which CSS declaration wins for an element — and immediately contrasts it with query_dom ('query_dom gives the computed value, this gives who set it'). An agent can route between the two 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 names the sibling alternative and the deciding criterion (computed value vs. originating declaration), and enumerates when the tool will not deliver useful results: cross-origin sheets without CORS, user-agent styles, @container and @scope.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that the tool lists frames with specific fields, which is consistent with annotations and not contradictory.

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

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

The description is a single 16-word sentence that is front-loaded with the verb 'List' and resource. Every word adds value; no fluff.

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 listing tool with one optional parameter and no output schema, the description covers the purpose, output structure, and usage context. It is complete enough for an agent to understand and use 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 coverage is 100% for the single parameter tab_id, and the description does not add any additional semantics or details about the parameter beyond what the schema already provides. Baseline score of 3 is appropriate.

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

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

The description clearly states 'List frames (main + iframes) with frameId, parent, URL', specifying the verb (List), resource (frames), and output fields. It distinguishes from siblings like get_tabs by targeting frame IDs for DOM 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?

The description explicitly says 'for the frame_id parameter of DOM tools', indicating when to use this tool (to get frame IDs for DOM operations). It does not mention when not to use or list alternatives, but the usage context is clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful context about what each result contains and implies incremental delta listing via the since cursor, but says nothing about ordering, truncation behavior against limit, or performance on dense pages. It adds some value but is not rich behavioral disclosure.

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

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

Two tight sentences: the capability and output fields come first, the routing preference second. No filler, nothing that could be dropped without losing meaning.

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

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

For a 7-parameter, no-output-schema tool whose schema is fully documented, the description covers purpose, output shape, and a usage preference. It omits result ordering/pagination semantics, but the completeness bar is largely met given how much the schema and annotations carry.

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

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

Schema description coverage is 100%, so the schema already documents limit, scope, since, format, tab_id, frame_id, and visible_only with concrete defaults. The description adds no parameter-level detail beyond what the schema provides, 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 (List) and resource (actionable elements: buttons, links, inputs, role/onclick matches), and enumerates the payload (CSS selector, label, position, flags). It is clearly distinguishable from siblings like query_dom, read_page, or extract, which cover raw HTML or other extraction goals.

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?

"Prefer this over dumping HTML to discover selectors" gives clear guidance on when to reach for this tool rather than reading the page source. It stops short of naming the closest alternative siblings (query_dom, find_text, read_page) by name or stating exclusions.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds substantial cross-tool behavior: visibility=hidden means the page does not render and screenshots fail, timers slow down, and dev.overlay carries compiler messages when an error overlay is open. These are non-obvious operating conditions an agent must know before calling other tools.

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 returned metadata list, then explains the two most consequential semantics (visibility, dev server/overlay). Dense and mostly waste-free, though the second half is a single run-on sentence mixing three distinct concepts.

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 on return values, the description correctly takes on the burden of explaining the payload fields and their interpretation. It is nearly complete; the only gap is how this metadata tool relates to DOM-reading siblings like query_dom or read_page.

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

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

Schema description coverage is 100% and both parameters (tab_id, frame_id) are fully documented in the schema, including omission semantics. The description adds nothing about the parameters, 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 resource ("Page metadata") and enumerates exactly what it returns: title, url, visibility, doctype, charset, meta tags, scripts, stylesheets, links and forms. That is concrete, but it draws no boundary against siblings such as get_status, query_dom or read_page, so the agent gets no differentiation signal.

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

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

There is actionable usage guidance embedded in the details: read dev.overlay "before treating the page as valid", and treat visibility=hidden as a red flag because rendering and timers are affected. However there is no explicit when-to-use/when-not or named alternative (e.g., query_dom for DOM inspection), so usage is only implied.

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

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

The description is unusually transparent about behavior, disclosing that the optional 'enable' parameter mutates session state ('switches caps on for this session, no restart'), which is a real side effect. However, this conflicts with the annotations declaring readOnlyHint=true and idempotentHint=true, which advertise a pure read with no state change. The description is honest, but the definition as a whole misleads a client that trusts the hints.

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, but the body is a dense run-on enumeration that mixes the returned-field list with the optional-cap catalog in one long sentence with no paragraph breaks. Nearly all content is useful, yet the undifferentiated field dump makes it harder to scan than it needs to be.

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

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

There is no output schema, so the description must carry the return-value burden itself, and it does exhaustively: connection state, mode, host/port, versions, js_evaluation semantics, roots, caps_active vs caps_available with an interpretation rule, session_tab_id, owned_tabs, and uptime. Nothing an agent needs to interpret the response or the enable parameter is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description goes beyond the schema by explaining the effect of enabling (caps active for this session, no restart) and by mapping each cap to the concrete tools it unlocks (audits/cookie_audit, visual/inject_css, perf/lighthouse, etc.). That cap-to-tool mapping is genuinely actionable information an agent cannot get from the enum alone.

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

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

The description opens with a specific verb+resource ('Bridge status') and enumerates exactly what is reported (connection, server mode, host/port, versions, roots, caps, tabs, uptime). It implicitly distinguishes itself from page-oriented siblings like get_page_info or get_tabs by scoping everything to the bridge/session itself. It stops short of naming a sibling it is not, so it is clear but not maximally differentiated.

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

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

Usage is only implied: an agent can infer it should call this to verify the extension is connected, check server mode, or diagnose why an optional tool is not in the tool list ('a tool missing from the list lives in an inactive cap'). The 'enable ... no restart' sentence hints at activation, but there is no explicit when-to-use vs alternatives statement or precondition guidance.

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

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

Annotations already declare readOnlyHint, destructiveHint, etc. Description adds specifics about cookie details (domain, path, expiry, flags) and confirms read-only nature. Consistent and adds value.

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 verb and resource. No wasted words; each sentence contributes purpose and detail.

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, but description mentions cookie structure. For a simple read tool, it sufficiently covers behavior and output shape. Adequate given the tool's simplicity.

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 has 100% description coverage. Description adds context for 'type' (all returns three together) and 'tab_id' default behavior, complementing the schema well.

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?

Description clearly states the tool reads localStorage, sessionStorage, or cookies of the current origin. It differentiates from siblings set_storage and session_fixture by mentioning write and snapshot operations.

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 context on when to use, e.g., checking for session cookies, and hints at alternatives. Lacks explicit when-not-to-use but offers good guidance overall.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so "Read-only" is redundant. However the description adds genuine non-obvious behavior: tabs closed since the last call are surfaced once in closed_session_tabs with enumerated reasons (closed, window_closed, replaced, closed_by_bridge), which is stateful/edge-case detail the annotations cannot express.

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

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

Front-loaded with what is returned, then read-only, then when to use it, then the option, then the closed-tab edge case — no filler sentences. It is dense and packed into one paragraph, but every clause carries information.

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

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

With no output schema, the description appropriately enumerates returned fields and documents the exceptional return channel (closed_session_tabs) and its reason vocabulary. Nothing critical is missing for correct invocation; only minor gaps remain around pagination/scale of large tab sets.

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 parameter's own description already covers bounds/state/type/tab count. The description adds a usage-level nuance ("needed before moving or tiling") rather than new syntax, which is a modest increment over the schema baseline.

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

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

States a specific verb+resource ("List every open tab") and enumerates the returned fields (id, url, title, active flag, mine), which lets an agent distinguish it from get_page_info, get_interactives or create_tab. The clarifying gloss "mine (created by this session)" removes ambiguity about the field name.

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

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

Gives a concrete triggering condition — "Find a tab_id when the implicit target is not the one you mean" — and a prerequisite for the option that must be set before other operations ("needed before moving or tiling"). It does not name alternative siblings (e.g. get_page_info, move_tab) or say when not to call it, so it stops short of a 5.

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

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

Annotations provide idempotentHint=true, and the description adds logging behavior and the reset functionality. It discloses that dialogs are auto-handled and logged, but does not detail the log format or potential side effects like interference with user interaction.

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

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

The description is two sentences, concise, and front-loaded with the primary action. Every sentence adds 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?

For a simple tool with clear schema and annotations, the description and schema together fully explain the tool's capabilities. The log return is mentioned, and optional parameters are covered.

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

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

All three parameters have descriptions in the schema (100% coverage), so the description adds minimal extra value beyond what the schema already provides. The description mentions logging and reset but not parameter-specific details.

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 clearly specifies the tool auto-accepts or dismisses future JS dialogs (alert/confirm/prompt) and logging them, with a reset option. It uniquely identifies the resource and action among sibling 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?

The description implies usage for dialog handling but does not explicitly state when to use this tool vs alternatives or when not to use it. No context on prerequisites or 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?

Goes well past the annotations by describing the interaction contract: a banner with the message and Done/Cancel, return triggered by click or timeout, redirects included, default 5-minute wait. It also discloses the answer-passing behavior of ask and the selector/text/box return of pick_element, which the annotations do not cover.

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

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

Front-loaded with the core purpose and the safety rule before the mode details, and every clause carries information. Slightly dense/long as a single run-on paragraph listing four modes, which costs a point versus a crisply structured alternative.

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

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

For a 7-param, no-output-schema tool, the description supplies the missing return semantics (selector, answer, Done signal) and the safety constraint. It could say more about what happens on timeout expiry or Cancel, but 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 coverage is 100%, so the baseline is 3, but the description adds genuine semantic context beyond the schema — it explains what the mode flags actually produce ('you get its selector', 'the reply comes back as answer', 'user presses Done when finished') and clarifies tab_id fallback and timeout behavior.

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

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

States a precise verb+resource+scope: handing the browser over to the human for actions only a person can perform, with named conditions (2FA, CAPTCHA, login, a choice). An agent can immediately separate this from automated siblings like click, type_text, and fill_form.

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 enumerates when to use it (2FA, CAPTCHA, login, a choice) and adds a clear negative rule: 'Never type credentials yourself,' which routes the agent away from type_text/fill_form. The three mode flags (pick_element, ask, pick_max) are each paired with the situation that selects 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?

Adds substantial context beyond the annotations: a forced garbage collection, the launch-mode requirement and its rationale, the side artifact (.heapsnapshot opens in DevTools > Memory), and the file-vs-content behavior when saving. It does not explain why the tool is flagged destructiveHint=true (e.g. page pause / GC-induced disruption), so one behavioral thread is left dangling.

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 its outputs, then layers on the diff workflow and the launch-mode constraint in a logical order. It is dense and slightly run-on with chained colons, but no sentence is filler.

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

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

No output schema exists, yet the description tells the agent exactly what a call yields (the summarized metrics or a saved file path) and what happens in compare mode. Combined with the capability constraint, an agent has everything needed to invoke 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 already 100% (baseline 3), but the description adds real meaning: compare_to is framed as an earlier snapshot file used to identify grown classes, and save_to's path-vs-content tradeoff is implied by the return-format discussion. top and tab_id semantics are left entirely to the schema.

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

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

States a specific verb and resource (take a JS heap snapshot of the tab) and enumerates what the summary contains: object count, total size, detached DOM nodes, top memory classes. It is clearly distinguishable from sibling diagnostics like perf_trace or lighthouse.

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

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

Gives the concrete leak-hunting workflow (snapshot, repeat the suspect action a few times, snapshot again, then diff with compare_to) and an explicit when-not/precondition: it only works in launch mode with chrome-bridge --launch, because Chrome refuses the HeapProfiler domain to extensions.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the non-obvious behavioral distinction: synthetic events fire JS handlers but not CSS :hover, while trusted drives the real pointer via chrome.debugger so CSS transitions apply. It does not cover failure modes or return behavior, but it discloses the trait that actually matters 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?

Two sentences, front-loaded with the action and addressing modes, then the mode semantics. Every clause earns its place 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 single-action interaction tool with full schema coverage and no output schema, the description is nearly complete: it covers addressing, modes, and the main-frame limitation (though that also appears in the schema). Return/error behavior is not described, a minor gap for a hover action.

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 each param carries a description, so the baseline is 3. The description adds real meaning for the trusted flag, explaining the mechanism (chrome.debugger) and the consequence (CSS :hover applies), which is more than the schema's terse wording conveys.

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

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

States a specific verb (hover) and resource (an element), plus the two addressing mechanisms (CSS selector or ref). An agent can distinguish this from siblings like click or move it easily without opening the schema. It is a clean verb+resource statement.

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 guidance on when to choose the trusted mode (when CSS :hover rules and their transitions matter), which is the primary usage decision for this tool. It does not name alternative tools or explicit when-not conditions, but the mode-selection guidance is concrete and actionable.

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

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

Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds valuable context: credentials are stored in-memory only, browser-wide. This is consistent with annotations and improves understanding beyond them.

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

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

A single sentence that captures verb, resource, scope, and key constraints. No wasted words, front-loaded with the core action.

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 output schema, the description adequately covers purpose, scope, and parameter dependencies. It could mention that credentials apply to all requests (global) or note potential security considerations, but for a simple set/clear 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 coverage is 100% with clear descriptions for all three parameters. The description reinforces the action enum and indicates username/password are required for action=set. This adds marginal clarity, but the schema already 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?

The description clearly states the action (set/clear), the resource (credentials for HTTP Basic/Digest auth dialogs), and the scope (browser-wide, in-memory only). It is specific and distinct from sibling tools, which are unrelated to auth.

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

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

The description implies usage context ('for HTTP Basic/Digest auth dialogs'), providing clear context. It does not explicitly mention when not to use or alternatives, but the context is sufficiently narrow given the diverse sibling list.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description does not need to fully disclose side effects. The description does mention sending cookies and writing bytes to a file, which are important behaviors. However, it does not warn that POST/PUT/DELETE methods can modify or destroy remote resources, which is relevant given the destructiveHint annotation.

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 compact at two sentences and conveys the core purpose, key parameters, and a specific fallback use case. The phrasing 'fetches what a server-side request gets a login page for' is slightly awkward, but it does not add unnecessary length 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?

The description explains the return behavior (inline text up to max_length, or bytes written via save_to) but lacks details about response status codes, headers, or error conditions. Since there is no output schema, a bit more information about the response format would improve completeness, though the description is sufficient for basic usage.

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%, with each parameter having a description. The description adds useful context for save_to and max_length (e.g., writing bytes for PDFs and capping inline text). It does not go beyond the schema to clarify headers or method semantics, but the schema already covers these adequately, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as an HTTP request from the browser with the user's cookies, meant to fetch authenticated content such as invoices, JSON, or exports. It also distinguishes the PDF-reading use case from read_page, giving a specific purpose. It could be more direct in naming the action 'perform an HTTP request', but the intent is clear.

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

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

The description explains when to use the tool: when a server-side request would get a login page, for authenticated data, and for PDFs where read_page fails. It also hints at not using read_page for PDFs. It does not explicitly enumerate all alternative tools, but the guidance is concrete and actionable.

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

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

The description adds significant behavioral context beyond annotations: lifetime (until navigation/reload), idempotency (re-inject replaces), and non-destructive nature (stylesheets untouched). Annotations already indicate idempotent=true and destructive=false, but description enriches with concrete details.

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 concise, front-loaded sentences with no redundancy. Each sentence adds essential information: purpose, behavioral details, and scope. Excellent efficiency.

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

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

Given the tool's simplicity and the presence of detailed parameter schema, the description covers all necessary aspects: what it does, how it behaves (lifetime, idempotency), and its non-destructive nature. No missing essentials.

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% with adequate descriptions for both parameters. The description does not add new parameter-level information beyond what's in the schema. The mention of 'same id' in the description implies an identifier not present in the parameters, which could cause confusion but does not directly affect parameter semantics.

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

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

The description clearly states the verb 'inject' and the resource 'CSS rule into the page'. It distinguishes this tool from siblings like modify_dom or execute_js by focusing specifically on CSS injection.

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

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

The description explains persistence ('stays until next navigation') and idempotency ('re-injecting the same id replaces it'). It also clarifies it only affects rendered content, not the site's stylesheet. However, it does not explicitly state when not to use it or mention 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?

Adds rich context beyond annotations: launch-mode requirement, new-tab loading, first-call npx download, 20-60s duration, file output paths. Annotations say destructiveHint=true (odd for a read-only audit), but the description doesn't contradict this; it explains the operational profile clearly. Could note why destructive is true (file writes?) but the file output mentions that.

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

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

Dense but front-loaded: purpose first, then use constraints, then timing. Three sentences cover a lot of ground efficiently. Slightly overpacked but every sentence earns its place for a complex tool.

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

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

Complete for a complex audit tool: covers what it returns (scores, lab metrics, failing audits), file outputs, prerequisites (launch mode, DevTools port), timing, and first-call overhead. No output schema, but the description explains return content. Missing only explicit alternative comparison beyond chrome-devtools-mcp.

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 3. The description adds value by explaining the 'url' default (target tab's URL), 'categories' default (all four), 'form_factor' default (mobile emulation of mid-range phone on slow 4G like PageSpeed), and 'save_to' behavior (.report.json/.report.html). More than the schema alone in some cases.

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 (Run) and resource (full Lighthouse audit) with the exact scope (performance, accessibility, best practices, SEO) and output form (scores, five lab metrics, failing audits). Explicitly contrasts itself with chrome-devtools-mcp, differentiating from siblings like 'audit' and 'perf_trace'.

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 strong context: works only in launch mode (chrome-bridge --launch), loads in a new tab, takes 20-60s, first call downloads via npx. These are critical usage constraints. Doesn't explicitly name alternatives like 'perf_trace' or 'audit' but the chrome-devtools-mcp contrast implies positioning.

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

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

The description discloses important side effects and real-world behavior: downloads are saved to the browser's Downloads folder, the tool reports the actual state, and a download may return waiting_for_user if Chrome asks for a destination. This goes beyond the minimal annotations and gives the agent useful runtime expectations.

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 concise and front-loaded, leading with the three primary operations. It avoids unnecessary detail and each sentence contributes meaningful information about behavior or side effects.

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?

The description covers the tool's core actions, storage location, and state-reporting behavior, which is enough for basic use. It does not explicitly describe the return values for list or wait_for_complete, but given the simple schema and annotations, this is a minor gap rather than a critical omission.

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 JSON schema already provides 100% coverage of all parameters with descriptions. The tool description mostly restates the action enum behavior and adds little new meaning about the parameters themselves, so it provides only marginal additional value beyond the schema.

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

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

The description clearly identifies the tool's purpose: list downloads, start one, or wait for completion. It distinguishes this from server-side file operations by explicitly stating files land in the browser Downloads folder, and it conveys the download-state reporting behavior.

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

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

The description explains the practical context of use, including where files are stored and what happens when the browser is configured to ask for a save location. It does not explicitly name alternative sibling tools, but the 'not on the server' note helps an agent choose this over server-side file operations.

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

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

The description states 'Read-only' and explains that values depend on the current layout, zoom, and viewport size, which is important behavioral context. The annotations (readOnlyHint, destructiveHint false) align perfectly. It does not mention potential errors or edge cases, but the most critical behavioral traits are disclosed.

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 slightly longer than strictly necessary, containing about 40 words, but every sentence contributes valuable information: metrics, units, read‑only nature, layout dependence, and normalization advice. The structure is clear and front‑loaded with the core 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?

Without an output schema, the description implies that the tool returns numeric values for gap, overlap, and distance, but it does not explicitly describe the return format or whether additional data (e.g., margins) is included. Given the tool's simplicity, the essential context is present, though a brief note about the exact return shape would make it fully complete.

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

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

Every parameter has a meaningful description: `tab_id` explains its fallback behavior, `selector1` and `selector2` both clarify how distances are measured from their boxes and that `>>>` pierces shadow DOM. This adds semantic depth beyond simple name/type information and covers 100% of the parameters.

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

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

The description clearly states a specific action (measure), a specific resource (two elements), and the exact metrics (gap, overlap, distance) along with units (CSS pixels). It also includes the relevant scope (margins and paddings) and notes about layout dependence. This leaves no ambiguity about what the tool does.

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

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

The description provides practical guidance for obtaining consistent results by recommending `viewport_resize({zoom:1})` for comparability across runs. While it does not explicitly contrast with alternatives (none of the siblings perform measurements), it effectively communicates how to use the tool correctly in a layout‑dependent 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?

Annotations indicate idempotent and non-destructive. Description adds transparency that changes are not persisted across reloads and that only the first match is modified. No contradictions with annotations.

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

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

Two concise sentences plus a one-sentence alternative recommendation. No redundant information; every sentence adds 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 7 parameters fully described in the schema, no output schema, and annotations providing safety profile, the description adequately covers core functionality and persistence behavior. Could enhance by contrasting with query_dom for read-only access.

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% with descriptive parameter names and descriptions. The description does not add additional context beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool changes an element in the live DOM, enumerates specific actions (setAttribute, removeAttribute, etc.), and contrasts with inject_css for bulk styling. It differentiates itself from sibling tools like inject_css.

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

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

Explicitly states when to use inject_css instead for many elements, providing clear guidance. Does not explicitly exclude other scenarios, but the contrast is sufficient for most use cases.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld. The description adds a genuinely behavioral detail beyond them: that the page hook is 'installed on first call,' disclosing a first-invocation side effect. It doesn't cover buffer exhaustion or pagination semantics, but it earns credit for the hook disclosure.

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

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

Two tight sentences, front-loaded with the purpose and then the scope/format semantics. No filler, though the 'format=har' clause is nearly redundant with the schema's own enum description.

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

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

For a 6-param, all-optional read tool with full schema coverage and rich annotations, the description covers the essential scoping dimensions. It stops short of routing guidance against siblings, 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 description coverage is 100%, so the baseline is 3. The source and format explanations restate what the enum descriptions already say ('page: XHR/fetch only; format har exports HAR 1.2'), so the description adds little beyond the structured 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 ('Monitor network requests') and enumerates the three source scopes, which clarifies the tool's domain. However, it offers no differentiation from closely related siblings like network_rules, http_request, or session_record, so an agent cannot tell from the description alone which network tool to pick.

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

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

The source values imply when each mode applies (page vs browser vs websocket), which is useful usage context. But there is no explicit when-to-use-vs-alternative guidance and the sibling network_rules/http_request are never mentioned, leaving the agent to infer routing.

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

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

The description goes beyond the annotations by detailing side effects and edge cases: it preserves id/history/state, works on chrome-untrusted:// tabs, only allows moving into normal windows, and clarifies that ChromeOS Terminal tabs can be pulled out but not merged back. This is extensive behavioral disclosure.

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 concise yet information-dense, packing all necessary constraints and nuances into two sentences without redundancy or filler. It is well-structured and easy to parse.

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

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

Given the complexity of the tool (edge cases, constraints, parameter interactions), the description covers the essential usage rules comprehensively. It does not describe the return value or error behavior, but since there is no output schema and the primary usage context is clear, this is a minor gap.

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

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

Schema coverage is 100% and each parameter already has descriptive text in the schema. The main description does not add meaning beyond what the schema provides; it merely references get_tabs for tab_id and window_id, which is already in the schema descriptions. Thus baseline 3 is appropriate.

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

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

The description clearly states the action (move an existing tab) and the target resource (into another window), while also providing key constraints (destination must be normal, etc.). It distinguishes itself from sibling tools like get_tabs or create_tab by focusing specifically on moving tabs.

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

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

The description gives concrete usage guidance: it explains where to get the tab_id (from get_tabs) and notes special cases like chrome-untrusted:// and ChromeOS Terminal tabs. However, it does not explicitly contrast with alternative tools (e.g., tab_action) or 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?

Annotations already provide idempotentHint, readOnlyHint, and destructiveHint. The description adds the behavior of returning interactive element previews, which is useful beyond annotations. However, it does not mention waiting for page load or error 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?

Two concise sentences: first states the core action, second describes the return value. No redundant or irrelevant 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 output schema, the description adequately explains the return value. It covers the primary behavior and return format. However, it lacks details on error scenarios or prerequisites (e.g., tab existence).

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 both 'url' and 'tab_id' are fully documented in the schema. The description repeats 'URL' but adds no new semantic detail beyond the schema.

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

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

The description clearly states the action ('Navigate a Chrome tab to a URL') and the return value (preview of interactive elements). It distinguishes 'navigate' from sibling interaction tools like 'click' and 'type_text' by focusing on URL navigation.

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

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

The description implies use after navigation for element interaction, but does not explicitly state when to use 'navigate' vs alternatives like 'create_tab' or 'get_tabs'. No exclusion criteria or alternative tools mentioned.

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

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

The description discloses that rules persist across reloads until cleared and that it is a local helper, with an HTTPS-specific limitation. Combined with annotations indicating non-read-only, idempotent behavior, this gives a solid picture of side effects.

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 compact and dense, packing many capabilities into a single readable paragraph. It avoids fluff, though the long colon-separated list requires careful parsing.

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?

It covers core behavior and constraints, but does not explain return values, rule precedence, how to clear a single rule versus all rules, or how overlapping rules are resolved. For a tool with this many actions and optional parameters, that is a notable 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?

The JSON schema already documents all parameters with descriptions, and the narrative description adds useful semantics such as header_target behavior for stripping CSP and injecting CORS, and overrides being useful for error states a real backend will not produce.

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 clearly identifies the tool as browser-wide network interception that can block, redirect, set/remove headers, stub, record, and replay. It is distinct from monitoring tools like monitor_network, though it does not use an explicit verb phrase like 'Manage network rules'.

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

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

The description explains what the tool can do but gives no guidance on when to use it versus alternatives such as monitor_network or http_request. The HTTPS host trust caveat is useful but does not provide selection criteria.

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

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

Adds substantive behavior beyond the annotations: the raw trace is written to a JSON file whose path/size come back in the result, tracing uses chrome.debugger so 'Chrome shows its debugging bar while tracing' (invisible in launch mode), and the tool refuses on a hidden page. This side-effect disclosure is genuinely useful and consistent with destructiveHint=true (the reload). It could go further on the reload's page-state impact, but the annotation bar is already met.

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 payoff ('return its conclusions, never the trace') before the details. It is dense and the metric enumeration is a long run-on sentence, but every clause carries needed information given there is no output schema, 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 output schema and a nested interaction object, the description does the heavy lifting: it lists what is returned, explains the recording lifecycle modes, the raw-trace file artifact, the debugger side effect, and the hidden-page refusal. An agent has everything needed to invoke 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 every parameter including the nested interaction object, reload defaults, duration cap, and save_to already carry descriptions. The prose restates the action/reload/duration behavior but adds no syntax or format detail the schema lacks, 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 ('Record a DevTools performance trace and return its conclusions') and immediately clarifies the crucial scope point: it returns conclusions, never the raw trace. It enumerates the exact metrics produced (LCP with phases, FCP, CLS, INP, long tasks, long animation frames), so an agent can distinguish this from generic siblings like lighthouse, audit, or track_events.

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

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

Explains the action semantics well: 'record' is the default one-shot (start, reload, wait, stop) while 'start'/'stop' 'bracket anything else done meanwhile', and notes it 'Refuses on a hidden page'. It gives clear conditions for each mode but never names or contrasts against sibling tools such as lighthouse or audit, so the when-to-prefer-this-tool question 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds value beyond this by stating it is NOT idempotent ('two calls send the key twice') and that it returns page_changed like click, plus mentions that refs of visible interactives follow when something opens. This is useful context beyond annotations, though return format details are lightly covered.

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

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

Two sentences, front-loaded with the core behavior and usage guidance. Every part earns its place, including the non-idempotency note and return behavior. No wasted words.

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

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

Given annotations covering safety profile and a 100%-covered schema, the description is nearly complete. It covers purpose, usage, non-idempotency, and return behavior. Minor gap: does not explain 'trusted' parameter behavior, but the schema covers that. Overall, an agent has what it needs to invoke correctly.

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

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

Schema coverage is 100%, so parameters like alt, ctrl, meta, shift, tab_id, trusted, frame_id are documented in the schema. The description clarifies that the key targets the focused element by default or a selector, which maps to the selector parameter, but adds no new syntax or format beyond schema. Baseline 3 is appropriate when 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 ('Send a key to the focused element') and explains the mechanism (real keydown/keypress/keyup sequence). It differentiates from the sibling type_text by explicitly stating that typing a value should use type_text, and this is for Enter/Tab/Escape/arrows/shortcuts.

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: 'For typing a value use type_text; this is for Enter, Tab, Escape, arrows and shortcuts.' Names the alternative and the condition that selects it. Also notes it targets the focused element by default or a selector.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by stating what is returned (structure, attributes, bounding rect, computed styles), and the schema covers the limit and selector details. No contradictions.

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

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

The description is a single sentence that is front-loaded with the action and key details. No unnecessary words; highly concise.

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 output schema, the description adequately hints at the return format (structure, attributes, bounding rect, computed styles). It could mention that results are an array or ordered by DOM order, but it is sufficient for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only mentions the selector in the tool description but not the other parameters.

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

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

The description clearly states the action (Query DOM elements by CSS selector) and the return data (structure, attributes, bounding rect, computed styles). It is specific and distinguishes from siblings like get_interactives or modify_dom.

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

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

The description does not provide explicit guidance on when to use this tool versus others. It implies usage for general DOM querying but does not mention alternatives or exclusions. Given many sibling tools, more context would help.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety bar is lower. The description usefully discloses the buffer scope and that uncaught errors/rejections are included, but it never warns that the destructive behavior comes from the buffer-clearing read (the 'clear' flag), which is the one behavioral trait an agent most needs 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?

A single tight sentence that front-loads the verb and resource, then appends the scoping detail. No filler, no redundancy.

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

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

With seven well-described params, no output schema requested, and annotations covering the safety profile, the description is nearly complete for a diagnostic read tool. The one gap is the destructive buffer-clearing consequence, which is left entirely to the annotations and the 'clear' param description.

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 each of the seven parameters carries a description (clear, level, limit, since, format, tab_id, sourcemap). The description adds no parameter-level meaning beyond the schema, 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 console messages) plus a scope qualifier (captured since page load) and what content is guaranteed (uncaught errors, unhandled rejections). An agent can distinguish it from siblings like monitor_network or get_page_info, though it never names an alternative explicitly.

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

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

Usage is implied by the tool name and the 'since page load' scope, which tells the agent this is a post-load diagnostic read. There is no explicit when-to-use, when-not-to-use, or guidance on pairing it with tools like evaluate_js or monitor_network.

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?

Beyond the readOnlyHint annotation, the description explicitly states 'Read-only' and discloses that password and card values are redacted, which is valuable behavioral information not covered by annotations.

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

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

The description is succinct and well-structured, conveying all necessary information in two sentences without redundancy or fluff.

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?

The description fully covers what the tool does, when to use it, and important constraints. Given the tool's simplicity and lack of output schema, it provides complete context for an agent to use 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?

The input schema already provides clear descriptions for both parameters (tab_id, selector). The tool description does not add extra meaning to these parameters, so it meets but does not exceed the baseline for parameter semantics.

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

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

The description clearly states the tool's purpose: reading a form as filled by the user, listing specific attributes (label, type, value, etc.) and its intended use case (checking against project documents before submit). It distinguishes itself from generic read tools by focusing on forms.

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 provides usage context ('before an irreversible Submit') and essential caveats (sensitive values redacted, read-only). While it doesn't explicitly name alternative tools, the guidance is sufficient for an agent to decide when to invoke it.

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

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

Beyond the readOnlyHint annotation, the description discloses that the operation is read-only and that HTML mode can be token-expensive, adding useful behavioral context about resource usage.

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 well-structured and front-loaded with the purpose, but includes some redundancy around HTML cost and repeated mentions of the same idea, so it is slightly less concise than ideal.

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?

Provides sufficient context for selecting and using the tool, including cost implications and alternatives, though it does not cover potential output variations or errors beyond what the schema implies.

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

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

The schema already provides 100% parameter description coverage with clear details for each param, so the tool description adds no extra parameter semantics; baseline of 3 is appropriate.

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

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

The description clearly states the tool reads a page in multiple modes (text, markdown, HTML, accessibility tree) and distinguishes it from siblings by advising when to use extract_table or get_interactives instead.

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 usage guidance: warns about high token costs on big pages and recommends alternative tools for repeated content or click targets, making the when-to-use decision clear.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that the tool writes an MHTML archive to the server filesystem, which elaborates on the destructive nature but does not detail side effects or required 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?

The description is a single sentence that conveys all essential information without redundancy or unnecessary details. It is efficiently 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?

Given the tool's simplicity, the description adequately covers the operation. However, it omits potential edge cases, such as errors from invalid paths or overwrite behavior, which could be important for proper use.

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?

Input schema coverage is 100%, so the schema already describes both parameters. The description adds no extra semantics beyond the schema, such as the meaning of 'last tab navigated' for tab_id. Therefore, it provides minimal added 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?

The description clearly states the action (save), the resource (full page), and the output format (MHTML archive file). It distinguishes from sibling tools like screenshot (image capture) and read_page (content extraction) by specifying the archive format and filesystem destination.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as when to prefer save_page over screenshot or get_page_info. No context about prerequisites or exclusions is given.

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

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

Goes well beyond the annotations with operational detail: needs the tab active and the window visible, requires ffmpeg on the server (with a stated fallback of the JPEG folder plus ffmpeg command), the 120 s recording cap, Chrome's change-driven frame emission with real preserved timing, and the chrome.debugger debugging-bar side effect including launch-mode 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?

Information-dense and front-loaded, with the core purpose in the first clause. Every sentence carries distinct value (return shape, action model, timing semantics, prerequisites, side effects), though the volume of caveats packed into one paragraph is heavy.

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 nine-parameter tool with a nested interaction object and no output schema, the description covers what matters: the return value (file path and size), prerequisites, fallback behavior, timing semantics, and the debugger side effect. 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 on top: it defines the default 'record' action as start + optional interaction + wait + stop, explains that start/stop bracket intervening work, and restates the 120 s duration cap. This clarifies the interaction of parameters rather than merely repeating them.

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

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

Opens with a specific verb+resource+artifact: 'Record the tab as a video (.mp4 or .webm).' It states the motivating use case ('watch an animation or interaction frame by frame') and explicitly contrasts its output with sibling frame-returning tools ('never the frames'), so an agent can tell it apart from screenshot without opening the schema.

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

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

Gives clear context for when to reach for this tool (frame-by-frame animation/interaction review) and explains the action lifecycle (record = start → interaction → wait → stop; start/stop bracket other work). It does not name alternatives or state when NOT to use it versus siblings like animations/watch, so it falls short of full routing guidance.

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