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

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

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

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

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

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

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

Given 8 parameters and no output schema, the description covers main conditions, patterns, and replay context. It lacks explicit return behavior but is otherwise sufficient.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beyond the annotations, the description discloses important behavioral details: real pointer actions can trigger navigation, dialogs, or form submission, and native confirm() dialogs can block the bridge. It explicitly states non-idempotence and directs users to handle dialogs, providing valuable context not present in the annotations.

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

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

The description is concise, using three focused sentences that front-load the core purpose and then add necessary caveats. Every sentence contributes meaningful information—no fluff, redundancy, or excessive detail. The structure is efficient and easy to scan.

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

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

Given the tool's complexity (8 parameters, no output schema), the description covers purpose, selector/ref resolution, side effects, and interaction with wait_after and handle_dialogs. It does not describe return values, but for an action-oriented click tool this is a minor omission given the rich schema and behavioral notes.

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

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

The input schema already provides full descriptions for all 8 parameters, so the baseline is high. The description adds useful semantic context by explaining the relationship between ref and selector (selector ignored when ref given) and that wait_after controls settling behavior. This goes slightly beyond schema descriptions without duplicating 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?

The description clearly states the tool's primary function: clicking an element by CSS selector or ref. It distinguishes usage from related tools like hover and press_key by specifying the click action and referencing get_interactives/navigate for obtaining refs. The purpose is immediately understandable.

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 guidance on when to use the tool and how to handle side effects: it notes that a real pointer sequence can submit, open dialogs, or navigate, and recommends wait_after. It also warns about non-idempotence and advises using handle_dialogs first for native confirm() blocks, making usage conditions 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?

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

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

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

The description is exceptionally concise, consisting of two short sentences that pack essential information without anyone. The structure is logical, starting with the core function and then adding the warning.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The schema already provides full descriptions for all three parameters (coverage 100%). The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

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

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

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

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

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

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

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

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

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

Two sentences, front-loaded with the primary action and followed by a practical usage tip. Every sentence contributes value with no redundancy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Two sentences pack the essential information: what it does, which overlays it targets, and idempotency. No wasted words.

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

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

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

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

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

Schema coverage is 100% with a clear description for tab_id. The tool description adds the non-obvious default behavior: omitted means last tab navigated or active tab, which is helpful beyond the schema.

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

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

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

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

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

Explicitly mentions idempotency, signaling safe repeated use. Implicitly suggests use when overlays block interaction. No explicit when-not-to-use or alternatives, but context is clear given sibling tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is front-loaded with the main purpose and keeps additional explanation compact and purposeful. The cost and scale guidance is phrased efficiently, and no sentence is redundant or filler.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already indicate idempotent and non-destructive behavior; the description adds valuable behavioral details such as the temporary nature of emulation, the reset parameter, and the fact that user_agent does not affect the HTTP header. No contradictions with annotations were found.

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

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

The description is concise, well-structured, and avoids unnecessary detail. It packs essential information into a few sentences and clearly separates the tool's purpose, scope, and parameter behavior.

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 complete for the tool's apparent simple use case: it explains scope, reset behavior, and parameter semantics, and notes how it fits with viewport_resize. Since there is no output schema and the tool likely returns no meaningful data, the absence of return-value details is 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?

The schema covers all six parameters with descriptions and enums, and the description reinforces important nuances such as user_agent not being the HTTP header and reset removing all emulations. This adds meaningful context beyond the structured schema.

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

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

The description clearly states the tool's purpose: making the page believe it is in a different environment for media queries and user agent. It also distinguishes it from related tools by explicitly noting that user_agent changes only what page JS reads, not the HTTP header, and by recommending pairing with viewport_resize.

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 usage guidance, including the reset option, the scope until reset/reload, and the relationship to viewport_resize for device emulation. It does not explicitly say 'use this when...' but the context and parameter details make the intended use clear.

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

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

Annotations already indicate destructive and non-readonly behavior. The description adds important context about MAIN world execution and the permission toggle, complementing annotations 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?

Extremely concise two sentences: first sentence states core purpose, second sentence adds essential setup requirement. No wasted words, every sentence earns its place.

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

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

Covers core purpose and setup requirement well. Schema already documents that the return value is the last expression result. Could mention async behavior, but overall sufficiently complete 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?

All parameters are fully documented in the schema with 100% coverage. The description adds no additional semantics beyond what the schema provides, meeting the baseline expectation.

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 runs JavaScript in the MAIN world of the page, using specific verb 'run' and resource 'JavaScript in the page', distinguishing it from similar sibling tools that may operate in other contexts.

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 a clear precondition (requires 'Allow user scripts' toggle) and a helpful note about error messages explaining setup if disabled. However, it does not explicitly compare with alternative tools like query_dom or modify_dom.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; description reinforces with 'Read-only' and adds details on filtering behavior and row counts, providing extra context beyond annotations.

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

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

Three concise sentences front-load the core purpose, add efficiency context, and describe key filtering behavior with zero wasted words.

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

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

With no output schema, the description compensates by mentioning output fields. It covers main usage patterns and performance considerations, though interaction between offset and row limits could be clearer.

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 covers all parameters with descriptions, but the description adds value by explaining the filtering logic of `where` (case-insensitive contains, 'any' key) and hints at output fields like `row_count` and `match_count` not in 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 it reads a table as JSON with specific structure, and the scope 'Only for tabular markup' distinguishes it from generic DOM queries or page reading.

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 'Only for tabular markup' and highlights efficiency benefits of server-side filtering, but does not explicitly state when not to use or name alternative tools for non-tabular data.

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?

Explicitly discloses non-idempotent behavior when submit_selector is used, warning that repeated calls submit twice. Also mentions React-compatible events, adding meaningful behavioral detail beyond the annotations.

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

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

Two concise sentences front-load the core purpose and then add the most important caveat. No fluff or redundant 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?

The description covers the tool's main behavior, supported control types, and the critical submission side effect. Remaining parameter details are provided by the schema, so 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 descriptions already cover all parameters, but the description adds extra meaning for submit_selector (triggers submission, not safe to retry) and clarifies supported field types relevant to the fields parameter.

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

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

States a specific action ('batch fill form fields'), lists supported element types (input, select, checkbox, radio, textarea), and notes optional submission via submit_selector. Clearly distinguishable from sibling tools like type_text or click.

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 clear context for when to use it (batch filling forms across multiple control types) and warns that using submit_selector causes submission and is not safe to retry. Does not explicitly contrast with type_text, but the use case is apparent.

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

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

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

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

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

The description is concise, two sentences, with no redundant content. It front-loads the purpose and then explains the behavior and constraints. Every phrase adds value, and the structure is easy to parse.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema coverage is 100%, so parameters are well-described in the schema. The description does not add additional meaning or usage hints for parameters beyond what the schema provides. The mention of 'parent selector, context, visibility, position' refers to output, not parameters.

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

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

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

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

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

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

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

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

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 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by detailing what elements are considered actionable (buttons, links, inputs, roles, onclick) and that it returns selectors, labels, positions, and flags. 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?

Only two sentences, both front-loaded with the tool's purpose and key benefit. No wasted words.

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

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

With full schema coverage, no output schema, and annotations, the description provides sufficient context about what the tool returns and when to use it. It could mention return format (lines/json) but the schema already covers that.

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 all parameters described. The description does not add parameter-specific meaning beyond the schema, but the overall usage context helps. 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?

Description clearly states it lists actionable elements (buttons, links, etc.) with ready-to-use CSS selectors, labels, positions, and flags. It distinguishes itself from sibling tools by recommending preference over dumping HTML.

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 to prefer this tool over dumping HTML to discover selectors, providing clear usage guidance. Could be strengthened by mentioning conditions where alternatives are better, but it's still helpful.

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 safety and idempotency are clear. Description adds specific metadata types, but no additional behavioral context (e.g., network requests, performance impact).

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?

Single sentence with no wasted words, clearly front-loading the purpose. Highly concise.

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

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

Description lists the output components (meta tags, scripts, etc.), providing sufficient context for an agent to understand what will be returned, even without an output schema. Could mention return format but not critical.

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 both parameters. The description does not add extra parameter information beyond the schema, so baseline 3 is appropriate.

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

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

Clearly states verb and resource: 'Get page metadata' and lists specific items (meta tags, scripts, stylesheets, links, forms). Distinguishes from siblings like query_dom (broader) and get_interactives (interactive elements).

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?

No explicit guidance on when to use this tool versus alternatives. Among many sibling tools, no context is provided for selection.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds minimal extra context beyond listing 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?

Single sentence, no waste, front-loaded with purpose.

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

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

For a zero-parameter status check, the description adequately lists key fields. Could elaborate on field meanings or possible values.

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?

No parameters in schema (100% coverage). Description lists output fields, adding value beyond empty schema.

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

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

The description clearly states 'Check bridge status' and lists specific fields (extension connection, server mode, port, version). This distinguishes it from sibling browser automation 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?

Implies usage for checking bridge status, but no explicit when-to-use or when-not-to-use compared to sibling tools.

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

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

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

The description states 'Read-only' and explains the 'mine' filter (tabs created by this session), which adds behavioral nuance beyond the annotations. It does not mention side effects, but the read-only nature is unambiguous and reinforced by annotations.

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

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

The description is a single, efficient sentence that packs all essential information—purpose, fields, read-only nature, and parameter rationale—without any redundant wording.

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 there is no output schema, the description adequately enumerates the returned fields for both tabs and windows. It also explains the 'mine' filter and the parameter's purpose. Minor omissions like sorting or pagination are not critical for this simple listing 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?

The single parameter include_windows is explained in the description: it adds window details (position, size, state, type) and is needed before moving or tiling. This adds practical context beyond the schema's dry listing of fields.

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

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

The description clearly states the tool lists all open tabs with specific fields (id, url, title, active, mine) and optionally windows. It also explains a key use case—finding a tab_id when the implicit target is ambiguous—which distinguishes it from similar 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?

It explicitly notes the tool is read-only and guides when to use it (to find a tab_id for other operations). While it doesn't name sibling tools like tab_action or create_tab, the context is clear enough for an agent to select this tool for listing tabs.

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?

The description discloses the blocking/waiting behavior, the banner UI, and that the call returns on click or timeout, including redirects. It does not fully describe the Cancel path or side effects if the user navigates away, but the core interactive behavior is transparent.

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

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

The description is compact and front-loads the main behavior while adding necessary usage guidance. It is slightly dense with punctuation and clauses, but every sentence contributes useful 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?

The description explains when to use the tool and what happens for pick_element, but it does not fully specify the return value for the normal handoff case. It says the call returns on click or timeout, but not what data or status the agent should expect, and Cancel behavior is ambiguous.

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

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

Schema descriptions already cover all parameters, and the tool description adds helpful context for message, timeout, and pick_element. It does not add additional meaning for tab_id beyond the schema, but overall the parameters are well understood.

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—handing the browser to the user—and scopes it to tasks only a person can perform, such as 2FA, CAPTCHA, login, or a choice. It also distinguishes the optional pick_element mode, making the tool's purpose unmistakable.

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

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

It explicitly says when to use the tool ('for what only a person can do') and includes a strong directive ('Never type credentials yourself') that guides an agent away from attempting those tasks with other tools. The pick_element sub-behavior is also clearly explained.

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 value beyond annotations by stating that hover triggers CSS and JS hover handlers. Annotations already provide idempotentHint=true and destructiveHint=false, so this context is useful.

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?

Single sentence, front-loaded with the verb and resource, no wasted words. Highly concise.

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

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

For a simple hover action with no output schema, the description adequately covers the tool's behavior. It mentions the triggered events, which is sufficient. No major gaps.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description adds minor context ('by CSS selector or ref' and events triggered), but not significant beyond the schema.

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

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

The description clearly states the action (hover) and the resource (element by CSS selector or ref), and it distinguishes from sibling tools like click and type_text.

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

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

No explicit guidance on when to use this tool over alternatives, such as click or type_text. The description does not mention conditions or prerequisites.

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

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

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

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

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

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

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

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

Given no output schema, the description adequately covers purpose, scope, and parameter dependencies. It could mention that credentials apply to all requests (global) or note potential security considerations, but for a simple set/clear tool, it is largely complete.

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

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

Schema coverage is 100% with clear descriptions for all three parameters. The description reinforces the action enum and indicates username/password are required for action=set. This adds marginal clarity, but the schema already does the heavy lifting.

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

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

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

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

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

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

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

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

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

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

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

The description is compact at two sentences and conveys the core purpose, key parameters, and a specific fallback use case. The phrasing 'fetches what a server-side request gets a login page for' is slightly awkward, but it does not add unnecessary length or repetition.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Three concise, front-loaded sentences with no redundancy. Each sentence adds essential information: purpose, behavioral details, and scope. Excellent efficiency.

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

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

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

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

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

Schema coverage is 100% with adequate descriptions for both parameters. The description does not add new parameter-level information beyond what's in the schema. The mention of 'same id' in the description implies an identifier not present in the parameters, which could cause confusion but does not directly affect parameter semantics.

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

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

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

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

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

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

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

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

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

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

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

The description is concise and front-loaded, leading with the three primary operations. It avoids unnecessary detail and each sentence contributes meaningful information about behavior or side effects.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is slightly longer than strictly necessary, containing about 40 words, but every sentence contributes valuable information: metrics, units, read‑only nature, layout dependence, and normalization advice. The structure is clear and front‑loaded with the core purpose.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Two concise sentences plus a one-sentence alternative recommendation. No redundant information; every sentence adds value.

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

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

Given the 7 parameters fully described in the schema, no output schema, and annotations providing safety profile, the description adequately covers core functionality and persistence behavior. Could enhance by contrasting with query_dom for read-only access.

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

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

Schema coverage is 100% with descriptive parameter names and descriptions. The description does not add additional context beyond the schema, so baseline score of 3 is appropriate.

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

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

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

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

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

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

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

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

Annotations already declare readOnly, openWorld, idempotent, and not destructive. The description adds transparency by noting that the page source installs a hook on first call, which is a subtle side effect not fully covered by the annotations. This extra detail improves behavioral understanding.

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

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

The description is compact yet informative, using semicolons to separate key points. It avoids unnecessary fluff and conveys all essential details in a structured manner, making it easy to parse and understand.

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

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

The description covers the tool's core behavior, source options, and output format. It lacks a detailed explanation of the return structure (no output schema), but the limit parameter mentions a buffer, giving some context. Overall, it is sufficiently complete for typical usage.

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

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

The schema descriptions already cover all parameters, but the description adds semantic clarity for the enum values (e.g., 'page: XHR/fetch only' and 'har exports HAR 1.2') and explains buffer limits. This enriches the parameter meaning beyond the schema alone.

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

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

The description clearly states the tool's purpose as 'Monitor network requests' and specifies the different sources (page, browser, websocket) and output format (har). This gives a precise understanding of what the tool does and distinguishes it from potential sibling tools like network_rules.

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

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

The description provides guidance on selecting source types and explains the format export, but it does not explicitly mention when to use this tool over alternatives (e.g., network_rules or track_events). The guidance is implicit through parameter descriptions rather than direct usage scenarios.

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

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

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

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

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

The description is concise yet information-dense, packing all necessary constraints and nuances into two sentences without redundancy or filler. It is well-structured and easy to parse.

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

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

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

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

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

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

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

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

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

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

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

The description gives concrete usage guidance: it explains where to get the tab_id (from get_tabs) and notes special cases like chrome-untrusted:// and ChromeOS Terminal tabs. However, it does not explicitly contrast with alternative tools (e.g., tab_action) or state when not to use this tool.

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

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

Annotations already provide idempotentHint, readOnlyHint, and destructiveHint. The description adds the behavior of returning interactive element previews, which is useful beyond annotations. However, it does not mention waiting for page load or error handling.

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

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

Two concise sentences: first states the core action, second describes the return value. No redundant or irrelevant information.

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

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

Given no output schema, the description adequately explains the return value. It covers the primary behavior and return format. However, it lacks details on error scenarios or prerequisites (e.g., tab existence).

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

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

Schema coverage is 100%, so both 'url' and 'tab_id' are fully documented in the schema. The description repeats 'URL' but adds no new semantic detail beyond the schema.

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

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

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

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

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

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

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

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

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

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

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

The description is compact and dense, packing many capabilities into a single readable paragraph. It avoids fluff, though the long colon-separated list requires careful parsing.

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

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

It covers core behavior and constraints, but does not explain return values, rule precedence, how to clear a single rule versus all rules, or how overlapping rules are resolved. For a tool with this many actions and optional parameters, that is a notable gap.

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

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

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

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

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

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

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

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

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

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

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

Annotations indicate non-idempotent (idempotentHint=false) and non-destructive. Description adds that it simulates a real key sequence and focuses the element if a selector is provided. Does not contradict annotations.

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

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

Two sentences, each serving a clear purpose: first explains the action and effect, second provides usage guidance and idempotency warning. No redundant 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?

Covers key aspects: what the tool does, key sequence, focusing behavior, example keys, and idempotency. No output schema, so return values are not needed. Sufficient for an 8-parameter 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 covers all 8 parameters with descriptions (100% coverage). Description only adds context about focusing when a selector is used, which is already implied. Little additional value beyond schema.

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

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

The description clearly states the action ('Send a key to the focused element') and specifies the key sequence (keydown/keypress/keyup). It distinguishes from type_text for typing values and gives examples like Enter, Tab, Escape, arrows, and 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 tells when to use (Enter, Tab, Escape, arrows, shortcuts) and when not ('For typing a value use type_text'). Also warns about non-idempotency: 'Not idempotent: two calls send the key twice'.

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

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

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

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

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

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

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

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

Given no output schema, the description adequately hints at the return format (structure, attributes, bounding rect, computed styles). It could mention that results are an array or ordered by DOM order, but it is sufficient for an agent.

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

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

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

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

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

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

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

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

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

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

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

The description does not disclose potential side effects such as clearing the buffer if the 'clear' parameter is set, but the annotation destructiveHint=true already signals possible destructive behavior. The description does not contradict the annotation, and the parameter schema covers the clearing detail, so transparency is adequate without being explicit.

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, concise sentence that conveys the core functionality without unnecessary detail. 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?

The description mentions what is included (uncaught errors, unhandled rejections) giving some context. Since there is no output schema, it doesn't need to describe return values. However, it could have clarified the scope (e.g., browser console only) slightly more, but overall it is complete for typical use.

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

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

Schema coverage is 100% with each parameter having a description. The description does not add further meaning beyond the schema; it only restates the tool's purpose. The baseline of 3 applies because the schema already fully documents parameters.

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

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

The description clearly states the tool reads console messages captured since page load, including uncaught errors and unhandled rejections. It specifies the resource (console messages) and the action (read), and is distinct from sibling tools that read page content or DOM.

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

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

The description implies when to use (when needing console output) but does not explicitly mention alternatives or when not to use. It does not reference sibling tools like read_page or get_page_info, leaving the choice to the agent's 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?

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

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

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

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

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

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

The description fully covers what the tool does, when to use it, and important constraints. Given the tool's simplicity and lack of output schema, it provides complete context for an agent to use it correctly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is well-structured and front-loaded with the purpose, but includes some redundancy around HTML cost and repeated mentions of the same idea, so it is slightly less concise than ideal.

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

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

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

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

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

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

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

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

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

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

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

Provides explicit usage guidance: warns about high token costs on big pages and recommends alternative tools for repeated content or click targets, making the when-to-use decision clear.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that the tool writes an MHTML archive to the server filesystem, which elaborates on the destructive nature but does not detail side effects or required permissions.

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

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

The description is a single sentence that conveys all essential information without redundancy or unnecessary details. It is efficiently front-loaded.

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

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

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

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

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

Input schema coverage is 100%, so the schema already describes both parameters. The description adds no extra semantics beyond the schema, such as the meaning of 'last tab navigated' for tab_id. Therefore, it provides minimal added value.

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

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

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

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

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

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

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

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

Beyond the read-only, idempotent, and non-destructive annotations, the description discloses a side effect (background tab activation and restoration) and a limitation (downscaling to ≤1568px). These details are not present in the annotations and materially affect how an agent should reason about the call.

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 core purpose is front-loaded, followed by behavioral notes and an alternative. Every sentence earns its place.

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

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

The description covers the main behavior, presets, save_to implication, side effects, and the key downscaling limitation with a concrete alternative. It relies on the schema for tab_id and save_to details, which is acceptable given the schema coverage. Minor gap: it doesn't mention what happens when no tab_id is provided, but that is already in the schema.

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

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

The schema already documents all three parameters with 100% coverage. The description adds minimal new parameter-level meaning, only echoing the preset behavior. Given the high schema coverage, a baseline 3 is appropriate.

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

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

The description clearly states the tool captures a PNG of the visible viewport only, at the current scroll position or per preset. It explicitly contrasts with element_screenshot and full_page_screenshot, making its scope unambiguous.

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

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

It specifies when to use an alternative (for fine print, use element_screenshot with scale) and implies not for full-page captures by saying 'visible viewport only'. However, it does not enumerate all sibling alternatives or explicitly state when to prefer full_page_screenshot.

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 notes that baselines are in-memory and lost on service worker restart, which is important stateful behavior. It also mentions that 'clear drops baselines' in the action parameter. It does not fully detail navigation side effects for compare_urls, but the provided context exceeds the annotations alone.

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

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

The description is dense but efficient, packing the core workflow into two sentences. The em-dash list and semicolon structure keep related ideas together, though there is slight redundancy between 'changed-pixel %' and 'pixels plus text diff'.

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 multiple actions and parameters, the description covers the essential workflow, output characteristics (changed-pixel percentage and diff highlight), and the in-memory limitation. It does not specify the exact return format, but the parameter-level descriptions and action enum cover most operational 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 9 parameters have descriptions in the schema, and the main description adds meaningful context such as using from_file for design mockups and threshold as per-channel tolerance. The descriptions clarify the distinction between compare and compare_urls, so an agent can infer parameter usage without external documentation.

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

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

The description opens with 'Visual regression:' and clearly defines the tool's purpose: saving named baselines and comparing later, with support for viewport, element, or PNG baselines. It also distinguishes compare_urls for production-vs-staging diffs, making the intended use obvious.

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

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

The description explains when to use the tool for visual regression and specifically calls out compare_urls for production-vs-staging comparisons. It does not explicitly contrast it with sibling screenshot tools, but the regression-focused wording is enough to imply the alternative 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?

The description adds behavioral context beyond annotations by differentiating the two scroll modes and mentioning conditions like 'network idle' and 'infinite scroll.' However, it does not disclose potential side effects such as triggering lazy loading or the impact of parameters like settle_ms and step_px. Annotations are minimal, so the description carries some burden but is not fully transparent.

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 with two sentences, front-loading the key information about the two actions. The redundant 'Scroll.' at the start is minor. It is well-structured for quick reading, though it could be slightly more informative without sacrificing conciseness.

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 (12 parameters, no output schema), the description provides a minimal overview of the two main modes but lacks details on how to use parameters like 'selector', 'offset_y', 'step_px', etc. It is enough for basic understanding but incomplete for advanced usage. The schema descriptions help, but the tool description could be more comprehensive.

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 parameters are already documented. The description provides a high-level overview of the 'action' and 'until' parameters, but does not add significant meaning to other parameters like 'x', 'y', 'selector', or 'offset_y'. It clarifies the purpose of the two modes, which is useful, but overall adds limited value beyond the schema.

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

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

The description clearly states the tool scrolls the page and defines the two distinct actions ('to' and 'until') with specific behaviors. However, it could be more explicit about the overall function (e.g., 'Scroll the current page') rather than just 'Scroll.' Distinguishes between modes but not from sibling tools, which are mostly unrelated.

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

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

The description explains when to use each action: 'to' for one-time scroll to element/coordinates, 'until' for repeated scrolling until a condition. This provides clear context but does not include explicit when-not or alternatives, though none are obviously needed for a scroll 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?

The description is highly transparent about side effects: 'save overwrites silently' and 'restore writes on top without clearing' explicitly warn about destructive behavior, and the origin restriction is explained. This aligns with the destructiveHint annotation and adds specific detail beyond it.

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

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

The description is concise, using two well-structured sentences. It packs all necessary information without redundancy or filler, making it easy to parse quickly.

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 core functionality and safety caveats, but does not mention any return values or error cases beyond the origin refusal. Since there is no output schema, the agent might not know what 'list' returns. Still, for a simple tool, the given context is mostly 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?

The parameter descriptions add meaningful context: 'name' is explained as required for save/restore (though optional in schema), 'action' describes save and restore semantics, and 'tab_id' is clear. However, the 'list' action is not explicitly described, and the conditional requirement for 'name' could be clearer. Since schema coverage is 100%, this is above baseline.

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

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

The description clearly states the tool's three actions (snapshot, restore, list) and specifies it targets localStorage, sessionStorage, and cookies for the current origin into a named fixture. However, it doesn't explicitly differentiate itself from similar sibling tools like get_storage or set_storage, which might cause some ambiguity.

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

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

It provides useful behavioral context (e.g., 'restore refuses on a different origin') but does not explicitly state when to use this tool over alternatives like session_record or get_storage/set_storage. The condition 'logged-in state' gives some guidance, but a clearer comparison to siblings would improve the score.

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 key behaviors: it records to a jsonl format, never records sensitive values, and replays target the tab navigated. These are valuable behavioral details beyond the annotations, which are all false. However, it doesn't mention side effects like file creation (beyond the replay command), whether stop is required, or how the export writes files. Given the false annotations, the description carries the burden and does a solid job, though not exhaustive.

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

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

The description is a single run-on sentence with semicolons, but it's dense with information and front-loads the core purpose. It avoids redundant wording and each clause adds distinct value. While not perfectly structured, it is efficient and does not waste words, earning a 4.

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

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

For a tool with five parameters and six actions, the description covers the high-level workflow well: recording, observing, exporting, and the replay target. The schema details the actions, so the description doesn't need to repeat them. It misses some nuance like what 'list' or 'status' do, but those are covered by the schema. The lack of an output schema is partially mitigated by the description's mention of 'return the path' in the save_to parameter, so overall it's fairly complete.

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

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

The input schema already describes all parameters with 100% coverage, including the action enum and their purposes. The description adds minimal parameter-specific meaning—it mentions the replay file path and observe mode, but these are already implied in the schema. Since the schema is comprehensive, a baseline of 3 is appropriate; the description doesn't significantly enhance parameter understanding.

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

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

The description clearly identifies the tool as a session recorder with three distinct capabilities: recording commands, observing user actions, and exporting to Playwright tests. It uses specific verbs and resources, and the three modes are explicitly differentiated, which distinguishes it from generic tools. Though it doesn't name a sibling, the description makes the tool's unique 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 provides contextual hints like 'for CI' and the replay command, but it doesn't explicitly state when to use this tool over alternatives or when to avoid it. There's no mention of prerequisites (e.g., needing an active session) or exclusions. The guidance is implicit rather than explicit, leaving some inference to the agent.

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

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

Annotations indicate idempotentHint=true and readOnlyHint=false, which the description does not contradict. The description adds that it is a page-level patch and that reset restores native behavior, but does not elaborate on persistence or scope beyond the page.

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

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

The description is very concise (two sentences) and front-loaded with the main action. It is efficient but could be slightly more structured with separation of setting and resetting.

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 5 parameters and no output schema, the description is adequate but does not explain the interaction between reset and coordinates, or the temporary/durable nature of the override. It lacks guidance for typical testing scenarios.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema (e.g., 'reset restores native' is implicit in the reset parameter description).

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: override navigator.geolocation with fixed coordinates. It also mentions the reset capability. This distinguishes it from sibling tools, as no other tool handles geolocation.

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 (setting coordinates for testing), but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites.

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

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

Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that clearing cookies logs the user out and cannot be undone, giving critical behavioral context for agent decision-making.

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 with front-loaded core functionality and a critical warning. No wasted words; 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 11 parameters with full schema coverage and no output schema, the description covers the main behavior, destructive consequences, and prerequisite (read first). Could mention error conditions or parameter interactions, but sufficient for selection.

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 coverage, baseline is 3. The description adds meaning by explaining action=clear wipes all entries of that type and that reading first is advisable, which goes beyond schema 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?

The description clearly states the tool writes, deletes, or clears localStorage, sessionStorage, or cookies. It specifies the action, storage type, and parameters like path, domain, and expiry, making it distinct from siblings like get_storage.

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 advises reading current values first with get_storage, providing clear context for safe usage. It does not explicitly list when not to use, but the destructive hint and warning about logout imply caution.

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 significant side effects beyond the annotations, such as close dropping unsaved work, reload dropping injections, and discard replacing the tab id. This goes well beyond the destructiveHint and idempotentHint flags, giving the agent clear expectations of consequences.

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

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

The description is compact and information-dense, listing actions and consequences in a single readable paragraph. Every sentence contributes to understanding the tool's behavior and constraints, with no redundant or extraneous content.

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

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

The description covers the main actions, side effects, and parameter semantics. It does not mention return values or error cases, but given the absence of an output schema and the operational nature of the tool, the context is adequately complete for most usage scenarios.

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 descriptions for all parameters, including the enum meanings and the omission rule for tab_id. The tool description adds little extra semantic value beyond what is in the schema, so it meets the baseline for parameter coverage.

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

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

The description clearly identifies the tool as performing tab lifecycle actions, listing all supported operations explicitly. It distinguishes from similar tools by noting that duplicate works where create_tab is forbidden, helping disambiguate from sibling tools like create_tab or move_tab.

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

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

It gives specific guidance on when to use certain actions, such as duplicate being available in restricted contexts and close_session applying only to tabs created in this session. It does not explicitly compare all actions to sibling tools, but the provided constraints are useful for agent decision-making.

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

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

The description discloses important behavioral nuances beyond the annotations, such as 'Maximized windows are restored first, since maximized ignores bounds' and the prerequisite that at least one target must have a scriptable tab. These details inform the agent about side effects and conditions, complementing the annotations (readOnlyHint false, idempotentHint true) without contradicting 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?

The description is concise, using two sentences to convey purpose, scope, and behavioral details. It is front-loaded with the core action ('Tile Chrome windows over one monitor in equal parts with no gap') and then efficiently covers constraints and edge cases. Every sentence adds value without redundancy or fluff.

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

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

Given the complexity (6 parameters, nested object, enums) and the rich schema descriptions, the description is largely complete. It covers the main purpose, scope, prerequisites, and a key behavioral quirk. It does not mention return values or error handling, but those are not expected from the schema's lack of an output schema. The description fills the context gap well for an agent to decide and invoke 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?

The input schema already provides descriptions for all six parameters, and these descriptions are specific and informative (e.g., layout 'columns splits left to right', padding 'Px of empty margin kept inside the work area'). The tool description adds little beyond what the schema says; it reinforces the overall behavior but does not materially enhance parameter understanding. With 100% schema coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Tile Chrome windows over one monitor in equal parts with no gap.' It specifies the resource (Chrome windows), the action (tile), and the scope (one monitor, equal parts, no gap). The additional clarification 'Only Chrome windows' further narrows the scope, leaving 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 implicit constraints (e.g., 'at least one target needs a scriptable tab') but does not explicitly state when to use this tool over alternatives. There is no comparison with sibling tools like 'window_layout' or 'move_tab', and no conditions like 'use this when...'. It lacks direct usage guidance for an agent choosing among similar window management 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?

The description explicitly states 'Read-only' and 'POST-body params are flagged, not decoded', which adds behavioral detail beyond the annotations. It also indicates output format (one line per event). No contradiction with annotations (readOnlyHint=true, etc.) and the additional limitation on POST-body is 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?

The description is concise, two sentences, front-loaded with the main purpose and the tracker list, and includes the read-only note and POST-body limitation. Every sentence adds value with no waste.

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

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

For a specialized decoding tool, the description explains what it does, which sources it covers, output format (one line per event), and read-only nature. It lacks a detailed output schema description, but the given summary is sufficient for an agent to understand the expected result. Given the tool's complexity, this is nearly complete.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (clear, tab_id, wait_ms). The tool description does not add any parameter-specific semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: decoding tracking beacons (GA4, Meta Pixel, etc.) from the browser network log, with output as one line per event. It is specific about the resource and lists the major tracker types, and it distinguishes itself from generic network tools like monitor_network.

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 clear context: it is for tracking beacons specifically, not all network traffic. However, it does not explicitly mention when not to use it or name alternatives, so it lacks explicit exclusions but provides enough context for an agent to infer appropriate use.

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