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

Adds real behavioral context beyond the annotations: it discloses that recording runs an optional action (hover/click/scroll/key), that composited_estimate is only a guess rather than the compositor's answer, what fade_only means for prefers-reduced-motion, and that it refuses on a hidden page. No contradiction with the declared 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?

Front-loads the resource and its categories, then the mode switch. It is a dense single paragraph with heavy punctuation, but nearly every clause carries load and nothing is repeated from structured fields.

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

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

With no output schema, the description compensates by naming the returned fields (selector, ref, animated properties, duration, delay, easing, iterations, play state, timeline, composited_estimate, fade_only). Combined with mode behavior and the hidden-page constraint, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the temporal rationale for duration_ms ('a 150 ms transition is over before a second call') and the action trigger set (hover, click, scroll, key). It does not explain tab_id/frame_id resolution beyond the schema.

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

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

States a specific verb ('List') and resource ('page animations') and enumerates the exact categories covered: CSS animations, transitions, Web Animations, and View Transitions. An agent can distinguish this from siblings like get_css_styles or track_events 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?

Clearly routes between modes ('Without duration_ms: what runs now. With duration_ms: records every animation that starts in the window') and names alternatives with conditions: pair with emulate_media reducedMotion for the reduced version, and note that frames handles smoothness. It also states the hidden-page refusal up front.

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, so the bar is lower, and the description adds valuable behavioral detail: it polls until timeout, failure raises an error naming the mismatch, and success returns passed and waited_ms. This is useful since no output schema exists, though polling cadence and partial-match failure specifics are not covered.

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

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

Three tight sentences, front-loaded with the core verb and polling behavior, followed by pattern syntax and the sibling contrast. No filler; every clause carries information an agent needs.

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

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

For an 8-param, output-schema-less tool, the description covers the essential behaviors: polling, failure semantics, and the shape of success/failure responses, with annotations covering safety. It is close to complete, missing only finer details like default timeout behavior and multi-condition interactions.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by explaining the pattern syntax (substring vs "/…/" regex) and clarifying that count/containing-text are optional modifiers. These are not stated in the schema field descriptions and improve correct invocation.

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 ('Assert') and resource ('a page condition'), then enumerates the condition types (element exists/visible, text, url/title) so the agent knows exactly what can be tested. It also names and contrasts the sibling wait_for, making differentiation possible without opening either schema.

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

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

Explicitly frames the when: recorded flows replay it as a test, and contrasts behavior with wait_for (which returns found:false vs this erroring). This gives a clear selection rule against the closest alternative, though it stops short of stating exclusions for each condition type.

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, so the bar is lower, and the description still adds real value: it explains the output shape (a summary line per kind, or a full Markdown report when save_to is set). It does not mention the cost/slowness caveat for keyboard and css checks, which lives only in the schema.

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

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

Front-loaded with the core purpose and the kind list, then routing alternatives. Dense but every clause carries information; the kind parentheticals are the only mildly verbose portion.

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-value burden by describing both the summary-per-kind mode and the full-report mode. Combined with 100% schema coverage and explicit sibling routing, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the enum by explaining what each kind actually checks (tab order/focus, plugin/theme/host cost, CDN freshness) and clarifies that save_to swaps content for a returned path.

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 (audit) plus the resource (page) and enumerates the exact check kinds, with parenthetical explanations of ambiguous ones like keyboard and resources. It is immediately distinguishable from sibling tools such as perf_trace, lighthouse, and 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?

Explicitly routes the agent: 'For one deep look at load speed use perf_trace, for Lighthouse scores lighthouse.' It also instructs how to choose kinds and notes the default behavior, so the selection decision is fully specified rather than inferred.

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

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

Goes well beyond the annotations: it discloses the interception trick (downloads cancelled at once, bytes re-fetched with browser cookies), filename sanitization, the never-overwrite guarantee, and the max_mb cap with skip behavior. Annotations only cover the generic safety profile (readOnly=false, idempotent=false, destructive=false), so this richer detail is real added value, and it is consistent with 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?

Front-loads the key distinction (no browser download, no Save-as dialog) and packs the workflow into one dense paragraph where almost every clause carries information. It is somewhat run-on across three distinct ideas, but there is little dead 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 stateful three-action tool with no output schema, the description covers the lifecycle, side effects, return value ('returns the saved paths'), and the cross-tool escape hatch. 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 per-parameter semantics are already documented; the description's contribution is tying parameters to the stateful workflow ('arm with save_dir', cap via max_mb, wait returns paths). This adds a little context on how params combine across the arm/wait/disarm cycle, but largely reinforces what the schema says.

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

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

Names a specific verb+resource ('Save files the page builds itself') and enumerates exactly the mechanisms covered: blob/data URL a[download], showSaveFilePicker writes, and page-initiated downloads. This cleanly separates it from siblings like save_page, manage_downloads, and http_request, which the description explicitly routes away.

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 operational sequence ('arm with save_dir, then click Export/Download, then wait') and names the alternative for the out-of-scope case ('A file with a URL: http_request save_to instead'). Both when-to-use and when-not-to-use are stated.

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

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

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 states write 'overwrites whatever the user had copied, which is not recoverable' — a non-additive, irreversible replacement of existing data — while the annotations declare destructiveHint=false. Despite the otherwise valuable side-effect disclosure (tab/window activation, empty-clipboard behavior), the description directly contradicts the destructive 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?

Dense, front-loaded, and free of filler: purpose first, then side effects, then the routing advice. Tight overall, though the 'its window' antecedent is slightly loose and it packs several directives into one sentence.

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

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

With no output schema, the description usefully covers read's return edge case (empty clipboard -> ''), tab/window activation, and overwrite risk. It still says nothing about write's return value, but for a 3-param tool this is largely complete.

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

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

Schema description coverage is 100% (action enum, text 'For write', tab_id fallback are all documented in the schema), so the baseline is 3. The description adds only one behavioral detail relevant to parameters (empty clipboard returns text ''), not additional semantics for text or tab_id beyond what the schema already says.

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

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

The opening sentence gives a precise verb+resource ('Read or write the system clipboard') and scopes it to text, immediately distinguishing it from text-input siblings like type_text. An agent knows exactly what this operates on.

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

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

It explicitly routes the agent: 'To fill a field use type_text instead of write and paste,' and explains the read use case ('checks what a Copy button copied'). This is an explicit when-to-use / when-to-use-something-else statement, not just implied 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?

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?

Goes well beyond the annotations by disclosing that it scrolls the source into view, that it returns as soon as events are sent without knowing if the app accepted the drop, that a missing element raises an error, and what each event family emits. This optimistic/fire-and-forget behavior is exactly the kind of trait an agent needs and annotations do not convey.

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

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

Front-loads the core action and packs mode semantics, side effects, and error behavior into three dense sentences with little waste. The semicolon-heavy style is slightly run-on 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?

For a tricky interaction with no output schema, the description covers what an agent needs: purpose, mode choice, side effect (scrolling), optimistic return semantics, verification guidance, and the missing-element error. 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 coverage is 100% so the baseline is 3, but the description adds real meaning for mode ('html5 = DragEvent+DataTransfer; pointer = pointer/mouse events') beyond the schema enum text. It does not elaborate on tab_id/frame_id semantics, which the schema already covers.

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

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

States a specific verb and resource ('Drag an element onto another') plus the two event modes, so an agent immediately knows the operation. It stops short of explicitly contrasting itself with sibling interaction tools like click or hover, so it is clear but not fully sibling-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?

Gives clear context for mode selection ('libraries listen to different ones', pointer for sortable libraries) and names follow-up verification paths (assert, query_dom). It does not state explicit exclusions or when this tool is preferred over sibling interactions, so no full when/when-not framing.

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?

Annotations only declare the risk profile (destructive, open-world, non-idempotent); the description supplies the operational context they cannot: the toggle prerequisite, awaiting promises up to timeout, the fact that a truncated result remains valid JSON and is marked as truncated, and that save_to returns a path instead of content. No contradiction 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?

Five dense sentences with no filler; the capability and its key constraint (toggle) come first, the sibling-routing guidance second, and return-shape behavior last. Every sentence carries information an agent needs.

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

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

For a six-param arbitrary-code tool with no output schema, the description covers prerequisites, async/timeout behavior, truncation shape, and disk output. It does not address how non-JSON-serializable return values are handled or how the result behaves when the code throws, which is the only remaining 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%, so baseline is 3, but the description adds real meaning for two params: max_length truncation still yields valid JSON flagged as truncated, and save_to writes the whole (untruncated) result to disk. tab_id and frame_id resolution rules remain schema-only.

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

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

States a specific verb+resource with scope: "Run JavaScript in the page (MAIN world)". It immediately contrasts itself against named siblings (extract, extract_table, query_dom, inject_css), so an agent can distinguish it without opening any schema.

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

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

Explicit fallback semantics: "Use it when no dedicated tool fits," then names four alternatives and what each does. It also states the enabling prerequisite ("Allow user scripts" toggle) and that disabled-state errors explain setup, covering what to do when the call fails.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds meaningful traits: deterministic execution, server-side parsing restricted to the main-document HTML, and the default output shape with null semantics for unmatched fields. That parsing-scope limitation is genuinely useful given siblings like get_frames.

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

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

One tightly packed paragraph that is front-loaded with purpose, then mechanics, then output semantics. Every clause carries information; there is no filler or redundancy.

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

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

With no output schema, the description carries the return-value burden and does so (total/shown header, tab-separated rows, empty field → null in json). All 7 params are schema-documented and the two core ones are explained, so nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a conceptual model beyond the schema: item_selector marks the repeating block and fields are resolved relative to it, with item_selector/fields being the required pair. It clarifies how the two key params compose rather than merely restating 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?

States a specific verb (read/extract) and resource (repeated non-tabular structures) with concrete examples (product cards, list items, search results). The qualifier 'non-tabular' implicitly and usefully separates it from the sibling extract_table, so an agent can route between them without opening a schema.

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

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

Gives clear positive context via examples of what this tool is for, and 'non-tabular' implies tables belong to extract_table. However, no explicit alternative is named and no when-not-to-use condition (e.g., single elements, iframes/shadow DOM) is stated, so it stops short of full routing guidance.

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

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

Annotations already declare a safe read (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantive behavior: `where` filters server-side with an explicit cost example (one row out of 1500 costs a few hundred bytes), the meaning of `row_count` vs `match_count` in the response, and the error behavior when no table matches the index. This is rich context beyond the 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?

Four dense sentences, front-loaded with the purpose and output shape, then usage, then return semantics, then error behavior. Every sentence carries information an agent needs; nothing is padding.

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

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

There is no output schema, so the description correctly carries the return-value burden (thead→keys, row objects, row_count/match_count) plus the error contract. With 8 parameters (all optional, 100% schema coverage) and annotations covering safety, the description is complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description earns extra credit by framing `where` as server-side filtering with a cost rationale and by explaining that a missing table at `index` yields an error reporting the selector's match count. It adds meaning beyond the schema's terse 'rows must match' wording.

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

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

The description states a precise verb and resource ('Read a real <table> as JSON') and immediately explains the output shape (thead cells become keys, each row an object). It explicitly distinguishes itself from the sibling 'extract' ('for cards and lists use extract'), so an agent can route correctly without opening either schema.

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

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

It states the scope condition ('Only for tabular markup') and names the alternative for the excluded case ('for cards and lists use extract'), which is exactly the when-to-use/when-not guidance needed. The server-side filtering note further clarifies the intended use for large tables.

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?

Annotations declare readOnlyHint=false yet destructiveHint=false, and the description supplies exactly the missing context for that split: it navigates the tab and leaves it on the last page visited, which explains why it is not read-only. It also adds the same-origin constraint on crawled links, the max_pages cap, and the return payload. It stops short of covering auth requirements or rate limits, but the key side effect is 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?

Three tight sentences, front-loaded with the purpose before the return values and side effects. Every clause carries information (mechanism, returns, navigation side effect, cap) with no filler, though the density borders on packed.

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

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

With no output schema, the description carries the return contract and does so well: URL, menu path, matching text, and a pages-tried count on failure. Combined with the disclosed tab-navigation side effect and the schema's parameter docs, an agent has what it needs; only keyword-matching semantics and permission prerequisites are left implicit.

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

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

Schema description coverage is 100%, so the schema already defines tab_id, keyword, max_pages, and menu_selector. The description only echoes max_pages ('at most max_pages') and alludes to menu links; it adds no syntax or format detail beyond the structured fields. Baseline 3 applies.

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

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

States a specific verb (find) and resource (a setting), plus the exact mechanism: following the panel's menu links until a page contains the keyword. It is clearly distinguishable from siblings like click, navigate, or find_text, though it never names an alternative to disambiguate. The 'unknown admin panel' framing makes the intent 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 phrase 'in an unknown admin panel' implies the scenario in which to reach for this tool (you don't know where a setting lives), but there is no explicit when-not guidance and no sibling is named as an alternative to compare against. Usage is inferred 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower. The description goes beyond them by disclosing that interactive elements are attached with refs usable by click/type_text/hover and only for the first visible match, plus the count-0 failure signal. It stops short of describing ordering limits or result sizes.

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

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

Three sentences, all load-bearing, with the behavior front-loaded ahead of the when-to-use routing. The first sentence is telegraphic to the point of being terse ('root selector, parent selector, context, visibility, position per match'), which compresses rather than clarifies, but nothing is wasted.

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

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

There is no output schema, so the description must carry the return-value burden, and it does list the salient fields plus the ref-bearing interactives and the zero-match case. Minor gaps remain around result ordering/pagination and how many nearby elements are attached.

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 text, tab_id, max_results, and case_sensitive. The description only hints at matching semantics ('the words on screen') and adds no syntax or default 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?

Specific verb+resource ('Find text on the page') plus an enumerated result shape (parent selector, context, visibility, position) and the side effect of attaching nearby interactives. It is clearly distinguishable from query_dom, which it explicitly contrasts.

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 both the selecting condition ('when you know the words on screen but not the selector') and names the alternative with its constraint ('query_dom needs one'). It also states the no-match outcome, so the agent knows what a zero-result call looks like.

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

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

Annotations only declare readOnlyHint=false/idempotentHint=false without saying why; the description explains the cause (an optional click/hover/scroll/key action runs right after recording starts). It further discloses the hidden-page refusal, the trusted-input requirement for INP, and the compositor-vs-main-thread nuance that 'compositor-only animations can stay smooth while the main thread drops frames.'

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 before caveats and alternatives, and every sentence carries information (metrics, action behavior, refusal, sibling routing). It is a dense block rather than skimmable bullets, which costs it a point but nothing reads as filler.

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

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

With no output schema, the description carries the full burden of describing returns and does so thoroughly: the metric list, the INP breakdown (input delay/processing/presentation), CLS scope, and the LoAF sub-fields. An agent knows what it will get back and under what conditions the tool fails.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it frames the action as optional and run 'right after recording starts', and its trusted-input note maps directly onto the `trusted` parameter's purpose (why hover defaults to real input). The metric-to-parameter mapping (duration_ms window, limit, threshold_ms) is still 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?

Opens with a specific verb+resource ('Record the page for duration_ms and report how smooth it ran') and enumerates the concrete metrics produced: main-thread frame rate, dropped frames, Long Animation Frames, layout shifts/CLS, and INP. It explicitly distinguishes itself from siblings by naming perf_trace and animations and the conditions that select them.

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

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

Gives explicit routing: 'For load speed use perf_trace; for the settings of each animation, animations.' It also states a hard exclusion ('Refuses on a hidden page: rAF and observers stop there') and the INP caveat ('needs trusted input, synthetic events have no interaction id'). When/when-not/alternatives are all covered.

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

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

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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail beyond that: results are in document order, and 'count equal to limit' signals possible truncation so the agent can raise the limit.

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

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

Two dense sentences, front-loaded with what the tool returns before the routing advice and ref usage. Every clause carries information, though the parenthetical on limit is slightly terse.

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

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

For a read-only listing tool with full schema coverage and no output schema, the description supplies the missing return-shape context (selector, label, position, flags, refs) and the truncation caveat. It is complete enough to call correctly, missing only explicit return formatting per 'format' value.

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 limit, scope, since, format, tab_id, frame_id and visible_only are all already documented with defaults. The description only reinforces the limit truncation semantics and does not add format or selector syntax beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource (list actionable elements) and enumerates what counts as actionable (buttons, links, inputs, [role], [onclick]). It also routes the agent away from the sibling behavior of dumping HTML to find selectors, making it distinguishable without opening schemas.

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

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

Explicitly says 'Prefer this over dumping HTML to discover selectors' and explains the ref (n1, n2…) feeds click, type_text and hover, giving clear context for use. It stops short of naming exclusions like when query_dom or read_form would be the better choice.

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

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

Annotations already cover read-only/idempotent safety, and the description goes further by explaining the operational consequence of visibility=hidden (no rendering, screenshots fail, timers slow) and decoding dev.server/dev.overlay fields. This is behavioral context an agent 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?

Dense but front-loaded: the field inventory comes first, then semantics, then sibling routing. The long field enumeration is justified because there is no output schema, though the sentence is heavier than strictly necessary.

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

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

With no output schema, the description compensates by enumerating return fields and explaining ambiguous states (hidden visibility, dev overlays). Combined with the sibling routing, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and both parameters (tab_id, frame_id) already document their defaults and cross-references (get_frames). The description adds no parameter-level detail, 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 resource (page metadata) and enumerates the exact fields returned (title, url, visibility, doctype, charset, meta tags, scripts, stylesheets, links, forms), which is far more precise than the tool name alone. It also explicitly distinguishes itself from read_page, query_dom, and get_status.

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

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

Explicitly routes the agent to siblings: 'For the text use read_page, for specific elements query_dom, for the bridge itself get_status.' It also gives a conditional instruction for dev.overlay ('read it before treating the page as valid').

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 readOnlyHint=false, the description carries the burden of explaining the mutation, and it does: 'enable is the only change it makes: it switches caps on for this session, no restart, and lists the tools added.' This confirms idempotency semantics and scopes the write precisely, adding context the annotations alone do not provide.

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

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

The purpose is front-loaded, which is good, but the body is a dense run-on paragraph with heavy parenthetical nesting, and the trailing list of every cap-to-tool mapping is bulky. Most content earns its place given the missing output schema, but the structure is poor.

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 enumerates the returned fields (mode, host, port, versions, js_evaluation, write_root, read_root, session_tab_id, owned_tabs, uptime_sec, caps_active, caps_available) and explains the enable side effect. An agent has everything needed to call and interpret this diagnostic tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by mapping each cap value (audits, visual, perf, network, storage, dom, files) to the concrete tools it unlocks. That is meaningful added context for choosing enable values beyond the enum listing in the schema.

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

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

The opening clause states a specific resource and scope: 'Status of the bridge itself, not of a page.' This immediately distinguishes it from page-oriented siblings like get_page_info, and the enumeration of reported fields (mode, host, port, versions, session_tab_id, caps) makes the resource concrete.

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

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

It gives an explicit trigger ('call it when a tool you expect is missing or browser commands fail') and a diagnostic reading (connected=false means the extension is unreachable), plus the enable use case. It does not name a sibling alternative to reach for instead in other situations, so it falls short of a full 5.

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

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

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 readOnly, idempotent and non-destructive, so the safety profile is covered. Beyond that the description adds genuinely useful behavioral detail: closed tabs resurface once in closed_session_tabs with a reason enum (closed, window_closed, replaced, closed_by_bridge). That is return-behavior context the annotations do not carry.

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

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

Three tightly packed sentences with the primary listing behavior front-loaded and no filler. The final sentence is dense with enumerated reasons but each clause is informative rather than redundant.

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

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

For a read-only, single-optional-param tool with no output schema, the description covers the returned fields, the parameter's effect and trigger, and the closed-tab edge case. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents include_windows. The description adds value by reframing the returned window fields as 'position, size, state and type' and attaching the actionable rationale ('needed before moving or tiling'), which is more than the schema's terse 'bounds, state, type and tab count'.

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 ('every open tab'), then enumerates the exact fields returned (id, url, title, active flag, mine). It also distinguishes its role from generic page tools by naming the tab_id lookup use case, so an agent can tell what it does without opening the schema.

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

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

Gives a clear when-to-use rule ('Find a tab_id when the implicit target is not the one you mean') and a conditional trigger for the parameter ('include_windows ... needed before moving or tiling'). It stops short of naming the alternative siblings (move_tab, tile_windows) explicitly, so it is strong context rather than full when/when-not routing.

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

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

Annotations 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?

Beyond the annotations it discloses non-obvious behavior: cookies are sent for the URL's origin, text bodies are inline but capped by max_length, and save_to redirects the bytes to disk. Its main gap is that it frames the tool purely as a fetch/read even though the schema permits POST/PUT/DELETE and the annotations flag destructiveHint=true — it does not contradict the annotations, but it undersells the mutation capability.

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 concept and every clause carries information (cookie auth, capping, PDF workaround, no download dialog). It is dense and slightly run-on across em-dashes, but wastes little.

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 headers object and no output schema, the description covers the behavior an agent needs to call it correctly, including the key safeguards (cookie scope, inline cap, save_to). It stops short of mentioning write-method implications or failure modes, 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 already 100%, so 3 is the floor, but the prose adds real meaning for max_length (the inline body cap) and save_to (writes bytes instead of returning them, for PDFs/images/archives) rather than merely restating 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?

It pairs a specific verb and mechanism ('HTTP request sent from the browser, with the logged-in user's cookies') with the exact contrast that matters: it reaches content a server-side request only sees a login page for. It also names the sibling it is not (read_page) and the download flows it replaces, so an agent can place it without opening any schema.

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

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

It gives explicit when-to-use cases (authenticated invoices, JSON, exports) and explicit when-not/when-else: use save_to for a PDF because read_page returns nothing on a PDF tab, and use this instead of clicking Download or 'Save as'. The routing to alternatives is concrete rather than 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 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?

Annotations only cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds substantial context beyond them: files land in the browser Downloads folder not on the server, and 'download' reports the real state, returning waiting_for_user with bytes fetched but nothing moved when Chrome asks where to save.

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 three actions, then the storage location, then the state semantics, then the sibling routing. Dense but every sentence carries distinct, load-bearing information with no filler.

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

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

No output schema exists, yet the description explains the meaningful return state (waiting_for_user) for the download action. Annotations carry the safety profile. Minor gap: it doesn't characterize what 'list' returns or key entries, but the essential call-correctness information is present.

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

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

Schema coverage is 100%, so the schema already documents all five parameters (baseline 3). The description adds meaning beyond it by explaining what each action does behaviorally, particularly 'download' fetching with browser cookies and reporting the true state with the waiting_for_user nuance.

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 three specific verbs (list, start/download, wait) against the resource 'downloads', and immediately names the sibling tools it is not (http_request with save_to, capture_downloads). An agent can distinguish this from those 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 routing rules: use http_request with save_to for a file that has a URL, and capture_downloads for a file the page builds. Both the alternative and the condition selecting it are spelled out, leaving nothing to inference.

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

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

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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds value beyond them by disclosing the side effect that the page hook is 'installed on first call' and reinforcing the observe-only contract ('It only observes'). It stops short of describing buffering/pagination behavior beyond what the schema notes.

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 clauses, front-loaded with the verb and resource, then modes, then alternatives. Zero filler; every phrase conveys routing or behavior 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 read-only observation tool with full annotation coverage and a complete schema, the description covers modes, output format, and sibling routing. It omits any hint about return shape (e.g. what lines/json/har contain), but with no output schema and safety fully declared, 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%, so every parameter is already documented in the schema; the description's source and format explanations largely restate the enum descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific verb+resource ('Monitor network requests') and immediately decomposes the three source modes (page/browser/websocket), which distinguishes it from the many sibling read tools. An agent can tell exactly what this captures 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 the agent to alternatives by condition: 'to block, stub or rewrite requests use network_rules, to send one yourself http_request.' This is textbook when-to-use and when-to-use-something-else guidance, including the source 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?

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?

Goes well beyond annotations: discloses the wait-for-load semantics, the failure condition, the tab-reuse fallback, and the return payload (interactive-element preview with refs usable by click/type_text/hover, plus first console errors and failed requests). The annotations only cover safety/idempotency, so this added operational detail is genuinely valuable.

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

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

Three sentences, front-loaded with the core action, followed by tab behavior and return shape; almost every clause carries information. Slightly dense in the final sentence but no real filler.

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

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

With no output schema, the description correctly steps in to describe the return value (interactive-element preview plus console/network errors), and it covers the key failure behavior. For a two-parameter navigation tool this is complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds tab-selection behavior for tab_id, but its fallback ('opens a new one rather than taking over the active tab') is in tension with the schema's 'else the active one', which can leave an agent unsure which tab actually gets targeted.

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

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

States a specific verb and resource ('Navigate a Chrome tab to a URL and wait for the load') and is instantly distinguishable from siblings like create_tab, get_tabs, and move_tab. The failure mode (DNS/connection errors fail the call) further pins down what the operation is.

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 tab-selection policy when tab_id is omitted (reuse session's last navigated/created tab, else open a new one) which is real when-to-use guidance. It stops short of naming an explicit alternative (e.g., create_tab) for the start-a-fresh-tab case, so it is clear context without explicit exclusions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, and the description adds substantial context beyond them: persistence semantics ('survives reloads until cleared'), a prerequisite ('from HTTPS pages the stub host must be trusted'), and return behavior ('each rule comes back as added, list shows them, clear removes them all'). This is exactly the kind of extra behavioral detail that structured fields 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?

Front-loaded with the core purpose and capability list, then constraints and sibling differentiation. Two long, dense sentences pack a lot in with little waste, though the parenthetical constraints interrupt the flow slightly.

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

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

For a 12-parameter tool with no output schema, the description covers capabilities, persistence, a trust prerequisite, and return-behavior ('added'/'list'/'clear'). It stops short of explaining per-action prerequisites, but the schema's 100% coverage fills that gap, leaving the definition largely complete.

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

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

Schema description coverage is 100%, so each of the 12 parameters is already documented. The description loosely maps actions to capabilities but adds no parameter-level detail (formats, defaults, required pairings) beyond what the schema already states, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Network interception, browser-wide') and enumerates the concrete capabilities (block, redirect, set/remove headers, stub, record/replay). It explicitly distinguishes itself from siblings monitor_network and http_request, so an agent can identify it without opening the schema.

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

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

Names two alternatives and the condition that separates them: monitor_network 'only observes' traffic while http_request 'sends one request', positioning this tool as the one that changes traffic. Clear context, but it does not spell out when to pick each individual action or when-not to intercept at all.

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 real side-effect context beyond the annotations: chrome.debugger usage, the visible Chrome debugging bar (and that launch mode hides it), the default page reload, and refusal on a hidden page — which partly accounts for the non-idempotent/destructive hints. It never states why destructiveHint=true or what, if anything, is mutated/discarded, so it falls just short of full 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?

Front-loaded with purpose and return payload, then side effects, then alternatives — no filler sentences and each block earns its place. It is dense (one long run-on inventory of metrics) but not padded.

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

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

For a complex, nested-parameter tool with no output schema, the description carries the return-value burden itself (conclusions, never the trace; JSON file path/size) and covers the debugger requirement, refusal case, and action semantics. An agent has everything needed to call it correctly.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds relational meaning the schema does not: "record (default) = start, reload unless reload: false, optional action, wait duration_ms, stop" and the differing reload default between record and start. The interaction and save_to parameters are not elaborated beyond the schema, keeping it from a 5.

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

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

States a specific verb and resource ("Record a DevTools performance trace") plus exactly what it returns (LCP with phases, FCP, CLS, INP, long tasks, LoAF, etc.). It also distinguishes itself from siblings by naming frames and lighthouse as alternatives, 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?

Explicit routing guidance: "For smoothness during an interaction use frames, for scores lighthouse." It also explains when to use each action mode (record = start+reload+wait+stop; start/stop bracket other work) and gives a refusal condition (hidden page), which is exactly the when/when-not/alternative structure.

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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds that a non-matching selector yields count 0 and that computed styles are opt-in via properties. It stops short of describing result shape beyond the field list or pagination/truncation behavior relative to limit.

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

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

Two sentences, zero filler; the capability statement comes first and the disambiguation clause follows. Every clause carries information an agent needs to choose or call the 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?

With no output schema, the description carries the return-value burden and does so (structure, attributes, bounding rect, computed styles). Combined with 100% parameter coverage and read-only annotations, nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so limit, tab_id, frame_id, selector and properties are all documented in the schema, including the '>>>' shadow-DOM syntax and the default tab fallback. The description only echoes the properties/computed-styles relationship, adding little beyond 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 (query) and resource (DOM elements) plus the return payload (structure, attributes, bounding rect, optional computed styles). It explicitly distinguishes itself from get_interactives, find_text and get_css_styles, so an agent can route correctly without opening any schema.

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

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

Gives an explicit precondition ('when you already have a selector'), names the alternatives for the adjacent tasks (get_interactives, find_text for discovery; get_css_styles for style provenance), and notes the empty-result case. Both when-to-use and when-to-use-something-else are covered.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the crucial detail of WHAT is destroyed (the messages it returns) and offers the non-destructive since=cursor path. That is meaningful context beyond the annotations, though it says nothing about buffer limits or rate behavior (partly covered by the schema).

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

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

Three tightly packed sentences with zero filler. The core purpose is front-loaded, and the destructive caveat and alternative are stated immediately after without redundancy.

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

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

For a 7-parameter tool with no output schema, the description covers purpose, destructive semantics, the non-destructive alternative, and sibling routing. It leaves return-value shape implicit, but the format parameter and lack of an output schema make that acceptable.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, including the clear and since semantics the description restates. The description adds only marginal cross-parameter meaning, so the baseline of 3 for fully-covered schemas 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 (Read) and resource (console messages captured since page load), and scopes it further by naming uncaught errors and unhandled rejections. It also distinguishes itself from the sibling monitor_network for failed requests, so an agent can route correctly without opening another schema.

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

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

Explicitly contrasts the two read modes: clear deletes what it returns (destructive), while since=cursor reads only newer entries without deleting. It also routes a specific need (failed requests) to monitor_network, giving a clear 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 declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: sensitive fields come back [redacted] and the tool is 'on request' (invoked deliberately rather than passively). The redaction rule is material information an agent cannot get from the annotations or schema.

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

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

Front-loads the core action, then the returned fields, then the guardrail and alternative. The em-dash field list is dense but every clause carries distinct information; no filler 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?

No output schema exists, so the description carries the burden of describing return values — and it does so field by field, plus redaction behavior. With both optional params fully covered by the schema, nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both optional parameters (tab_id, selector) are already fully documented in the schema, including the omission defaults. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Read a form as the user filled it') and enumerates exactly what is returned — label, type, value, checked/selected, required-but-empty, validity. It explicitly distinguishes itself from the sibling fill_form, so an agent can separate read vs. write without opening either schema.

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

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

Gives the use case ('to check it against the project's documents before an irreversible Submit') and names the alternative for the opposite intent ('to change values use fill_form'). Both when-to-use and which-other-tool are stated explicitly.

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

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

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 declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds useful specifics: it overwrites output_path and returns path and size, which tells the agent what existing file data is destroyed and what comes back.

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 definition is two tight sentences, front-loaded with the core action and followed by purpose, alternatives, and side effects. Every clause earns its place.

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

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

With no output schema, the description still reports the return values (path and size). Combined with annotation safety hints and full schema coverage for parameters, it gives an agent everything needed to invoke the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds behavioral meaning for output_path by stating it is overwritten. It does not add syntax or defaults for tab_id, leaving that 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?

The description states a specific verb and resource ('Save the full page ... as an MHTML archive file on the server filesystem') and names sibling alternatives ('for an image use screenshot, for the text read_page'). An agent can distinguish it from other capture tools without opening the schema.

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

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

It gives explicit use cases ('for evidence or a later comparison') and redirects to alternatives for image and text needs. This is clear when-to-use and when-to-use-another-tool guidance.

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