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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that it specifically clears text in input/textarea elements, matching the destructive hint. However, it doesn't disclose behavioral details such as whether clearing triggers input events, requires focus, or what happens if the target isn't an input/textarea.

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, front-loaded sentence with no unnecessary words. It efficiently conveys the action and target element type, earning a full score for conciseness and structure.

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

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

For a simple one-parameter mutation tool with annotations and no output schema, the description covers the core behavior. However, it lacks any note about return values, behavior on invalid targets, or whether events are triggered, leaving a minor gap in 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 input schema provides full coverage for the single 'target' parameter, describing it as 'Input element reference (snapshot ID) or CSS selector.' The tool description adds no extra parameter semantics, but since schema coverage is 100%, 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 states the tool's function: 'Clears the text in an input or textarea element.' It uses a specific verb ('clears') and names the resource ('input or textarea element'), which distinguishes it from sibling tools like browser_type that enter text into 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for clearing input/textarea content but doesn't mention exclusions or direct the agent to alternative tools for related actions, such as selecting all or deleting text via keyboard.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, indicating the tool mutates state and can be destructive. The description adds no further behavioral disclosure, such as possible navigation or permission requirements. It does not contradict annotations, but provides no value 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?

The description is a single concise sentence with no filler. However, it is terse and omits useful context that could be added without bloat, such as the requirement for a snapshot target. It is appropriately sized but not front-loaded with any distinguishing 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 the tool's moderate complexity (5 parameters, no output schema), the description alone is minimally sufficient because the schema fully describes parameters. However, it lacks context about return values, when to use click vs other actions, and potential side effects. The schema covers parameter semantics, so a score of 3 is appropriate.

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%, with every parameter documented (e.g., target is 'Exact target element reference from the page snapshot, or a unique element selector'). The description itself adds no additional parameter meaning, 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 action ('Perform click') and the resource ('web page'), which is specific enough. However, it does not differentiate from sibling interaction tools like browser_hover or browser_drag; the agent must infer that 'click' is a distinct action without additional context. It is unambiguous about the core operation but lacks detail on the target element requirement.

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. It does not mention prerequisites such as needing a page snapshot to obtain a valid target, nor does it contrast with browser_hover or browser_drag. An agent receives no context for tool 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?

The annotation already indicates destructiveHint=true, so the agent knows the action is destructive. The description simply repeats that by saying 'close' without adding any extra context about side effects (e.g., whether it closes just the current tab, loses unsaved state, or affects other tabs). It does not contradict the annotation, but it adds no new behavioral information.

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 extremely concise, using only three words. It communicates the essential action and target without any fluff, making it easy to parse and understand 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?

Given the simplicity of the tool (no parameters, no output schema), the description is functional but lacks completeness. It leaves open the scope of 'close'—does it close the current page/tab, or the entire browser? In a context with sibling tools like browser_tabs, this ambiguity could be problematic. More detail would improve it.

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

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

There are no parameters, so the schema coverage is trivially complete at 100%. The description does not need to explain any parameter semantics, and the baseline score 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 'Close the page' clearly states the action (close) and the resource (page), making it unambiguous. It is distinct from sibling tools like browser_navigate or browser_snapshot, so an agent can easily identify it.

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. It does not mention potential alternatives (e.g., using browser_tabs to manage multiple pages) or any conditions that would make closing appropriate. The context is minimal and leaves the decision entirely 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 already indicate readOnlyHint true and destructiveHint false, so the description adds no conflicting side-effect information. It does not elaborate on behavior such as saving to a file, but that is covered by parameter descriptions.

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 clear sentence with no redundancy, front-loading the verb and object.

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

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

For a simple read-only tool with full schema coverage, the description is adequate, though it omits explicit use-case guidance and output format details beyond what the schema provides.

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 detailed parameter descriptions, so the tool description itself does not add meaning beyond the schema, but no parameter meaning is missing.

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 uses a specific verb 'Returns' and identifies the resource 'console messages' with scope 'all', making the tool's purpose clear and distinct from sibling tools such as network request retrieval.

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 guidance is provided on when to use this tool versus alternatives like browser_network_requests or browser_snapshot, nor does it mention filtering or filename-saving 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?

Annotations already flag the operation as not read-only and destructive (readOnlyHint=false, destructiveHint=true). The description adds only that it dispatches a 'custom event' with optional initialization, but does not warn about potential side effects or that dispatching arbitrary events may not trigger framework-specific handlers. It does not contradict 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 a single sentence, immediately verb-first, with no filler. Every word contributes to the core meaning.

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

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

The tool has no output schema and minimal annotations; the description leaves out crucial context such as what happens when the event is dispatched, whether the return value indicates success, and when to use this instead of browser_click or browser_type. The openWorldHint and destructiveHint suggest potential side effects, but the description does not elaborate, leaving gaps for an agent deciding if this is appropriate.

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 three parameters with 100% coverage. The description's phrase 'custom initialization parameters' adds negligible meaning over the schema's 'Optional event initialization options,' and 'target element' mirrors the schema's 'target' 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 uses the specific verb 'dispatches' and identifies the resource as a 'custom event' on a 'target element,' making its function clear. It distinguishes from sibling interaction tools like browser_click or browser_type by focusing on arbitrary custom events.

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

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

The description provides no guidance on when to use this tool versus using higher-level interaction tools like browser_click or browser_type. There is no mention of use cases, exclusions, or when to prefer 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 destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no extra behavioral context such as side effects on the DOM or event firing, but it does not contradict 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 a single concise sentence that front-loads the action and provides the core information without any irrelevant 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?

For a simple action with well-described parameters and no output schema, the description is mostly complete. It does not mention any return values or wait behavior, but the lack of output schema makes this acceptable. It could have added a note about the order of start and end parameters, but the parameter names and descriptions handle 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 description coverage is 100% with all four parameters described. The tool description adds no additional parameter semantics beyond what the schema already provides, so the 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 action (perform drag and drop) and the resource (between two elements), distinguishing it from sibling tools like browser_click, browser_hover, and browser_drop. It is specific and 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 does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions such as needing to move an element or triggering drag-and-drop events, nor does it reference sibling tools like browser_drop or browser_click.

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 convey destructive and non-read-only behavior, so the description does not need to repeat that. The description adds useful semantic context about simulating an external drag, but does not disclose any side effects beyond the basic drop action.

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

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

The description is a single, focused sentence that concisely explains both the action and the key parameter requirement. No filler or redundancy.

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

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

The description, combined with the detailed schema and annotations, provides enough information to invoke the tool correctly. There is no output schema, so return-value details are not required, and the parameter permission explanation is handled by the 'element' field description.

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

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

All parameters have clear schema descriptions. The tool description adds an important cross-parameter constraint that at least one of 'paths' or 'data' must be provided, which is not otherwise expressed in the schema.

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

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

The description clearly states the action: dropping files or MIME-typed data onto an element. It uses a specific verb and resource, and distinguishes itself from in-page drag operations by specifying 'as if dragged from outside the page'.

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 a useful usage constraint ('At least one of paths or data must be provided') and hints at external drag context, but it does not explicitly name sibling tools or state when to prefer this over browser_file_upload or browser_drag.

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

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

The description only says 'emulates' without clarifying whether the emulation is temporary, persistent, or how it interacts with existing browser state. Although annotations include destructiveHint=true, the description adds no additional behavioral context beyond what the annotations already indicate, so the agent receives minimal extra insight.

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 with no filler, clearly front-loading the main action. It covers both parameters without unnecessary detail, earning a perfect score for brevity and structure.

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

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

Given the tool's simplicity, the complete schema, and the presence of annotations, the description is largely sufficient. It could benefit from a note about resetting emulation (e.g., using 'null' or 'no-preference'), but the schema already exposes those enum values, so the description is adequately complete for a straightforward 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 schema provides 100% coverage with descriptions for both parameters, including enums. The description maps directly to these enums (light/dark, screen/print), but does not add significant new meaning beyond what the schema already documents, 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 states the tool emulates light/dark color schemes and media type queries (screen vs. print), using a specific verb and resource. This distinguishes it from other browser tools like resize or navigate, and matches the tool name and title.

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 testing responsive design or print styles, but does not provide explicit when-to-use or when-not-to-use guidance. There are no alternatives mentioned, so the context is only implicit from the action itself.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this can modify state. The description adds minimal context beyond that—it mentions 'on page or element' but doesn't warn about the power of arbitrary JS execution or potential side effects. Since the annotation covers the destructive nature, the description's lack of extra detail keeps it at a baseline 3.

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, clear sentence with no redundant words. The action is front-loaded and easy to parse. This is appropriately concise for a tool whose parameter details are already in the schema.

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

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

Given that this tool executes arbitrary JavaScript with destructive potential, the description is too sparse. It doesn't mention that the function can modify the page, that results can be saved to a file (though schema covers it), or that there is a separate unsafe variant (browser_run_code_unsafe) that might be more appropriate for certain tasks. The description lacks the context an agent needs to safely and correctly use this tool, especially when annotations already warn about destructiveness but the description provides no additional guidance.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema itself. The description does not add any meaning beyond what the schema provides—it doesn't elaborate on the function syntax, target usage, or filename behavior. With high schema coverage, the baseline is 3, and the description contributes nothing extra.

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 'Evaluate' and the resource 'JavaScript expression on page or element', making the core purpose obvious. However, it doesn't distinguish from the sibling browser_run_code_unsafe, which might also execute code, so it loses a point for not differentiating between 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?

There is no guidance on when to use this tool versus alternatives like browser_run_code_unsafe or when to avoid it. No context about prerequisites (e.g., page must be loaded) or scenarios that favor this tool over others. The description simply states the action without any usage direction.

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, covering safety. The description adds that the output is a structured JSON array, providing useful context about the return format. However, it does not disclose potential edge cases (e.g., behavior when no table is found, handling of multiple tables, or nested tables), leaving some transparency gaps.

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

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

The description is a single concise sentence that immediately conveys the action and output. It contains no redundant words or filler, and the most important information is front-loaded.

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

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

For a simple read-only tool with one parameter and good annotations, the description is adequate but minimal. It lacks details on which table is extracted (first table, all tables, table matching a selector) and the exact structure of the JSON array. Notably, there is no output schema, so the description could have provided more detail on the return format.

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 includes a fully descriptive entry for the single 'target' parameter ('Target table reference (snapshot ID) or CSS selector.'), so schema coverage is 100%. The tool description does not add any additional parameter semantics, so it stays at the baseline of 3.

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

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

The description clearly states what the tool does: 'Extracts tabular HTML table data into a structured JSON array.' It uses a specific verb ('Extracts'), names the resource ('tabular HTML table data'), and specifies the output format. This distinguishes it from sibling tools like browser_get_html or browser_snapshot, which provide raw HTML or page snapshots, not structured table extraction.

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 offers no guidance on when to use this tool versus alternatives. It does not mention that other browser tools like browser_evaluate or browser_get_html could serve similar purposes, nor does it state specific scenarios where extracting a table is preferred. This lacks explicit usage 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?

The annotations already indicate destructive behavior and non-read-only semantics, so the description does not need to restate those. However, the description does not mention side effects beyond uploading, such as navigating away, opening or cancelling a file chooser, or potential overwrite behavior, though the parameter description partially covers the cancellation case.

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 extremely concise and free of filler. Every word contributes meaning, and the parameter description adds necessary details without redundancy.

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

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

For a simple one-parameter tool with no output schema, the description and parameter comment cover the essential input and basic behavior. However, it does not describe what happens after the upload, what success or failure looks like, or how this fits into the broader browser automation workflow, leaving some practical context missing.

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

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

The schema only defines an array of strings, but the parameter description adds important meaning: paths must be absolute, multiple files are allowed, and omitting the parameter cancels the file chooser. This goes beyond the raw schema and helps an agent use the parameter correctly.

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 ('Upload') and the resource ('files'), and specifies 'one or multiple'. It does not explicitly state the destination or context, but the tool name and sibling set make the browser file-upload intent sufficiently 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 gives no guidance on when to use this tool versus alternatives such as browser_drop or other browser interaction tools. It also does not mention prerequisites like whether the file chooser must already be open or how paths should be formatted beyond 'absolute'.

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

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

The annotations already declare readOnlyHint=false and destructiveHint=true, so the write and potentially destructive nature is covered. The description adds the 'multiple form fields' detail but does not disclose additional behavior such as overwriting values or submitting the form.

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 clear sentence with no redundant words or boilerplate. It is appropriately short and easy to parse, though it sacrifices deeper context for brevity.

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 rich schema fully documents the nested field objects, including target references, type-specific value behavior, and permission-related element descriptions. Combined with the read-only and destructive annotations, the description is sufficient for correct invocation; only alternative-selection guidance is missing.

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

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

Schema coverage is 100%: the fields array and its nested target, name, type, value, and element properties all have descriptive text. The description itself does not add parameter-level meaning beyond what the schema already provides.

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 'Fill multiple form fields' clearly identifies the action and resource, and the word 'multiple' helps distinguish it from single-field tools like browser_type. It does not explicitly contrast with sibling tools, but the core purpose is unambiguous.

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

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

No guidance is provided for when to use this tool instead of alternatives such as browser_type, browser_select_option, or browser_click. The term 'multiple' implies batch usage, but there is no explicit when-to-use or exclusion 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 already cover read-only and non-destructive behavior. The description adds useful behavioral detail about return format, surrounding context, path-from-root presentation, and cost characteristics. It is consistent with the annotations, with 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?

One dense, well-structured sentence that front-loads the action and then provides the output shape and the key trade-off. There is no filler or redundancy; every clause earns its place.

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

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

The description explains return shape and the main use case, and annotations cover safety. However, since neither parameter is marked required in the schema, the description could more explicitly instruct the agent to provide exactly one of text or regex.

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%; both text and regex are already documented with mutual exclusivity and regex flag syntax. The description adds no parameter-level meaning beyond restating that either text or regex is used, 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?

The description states a specific verb ('Search'), a clear resource ('the accessibility snapshot of the current page'), and a well-defined result (matching snapshot nodes with surrounding context and refs). It also distinguishes itself from the whole-snapshot sibling by explaining its narrower focus.

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 a clear when-to-use condition: this is 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' It implicitly contrasts with browser_snapshot but does not explicitly name the sibling or state when NOT to use this tool, so it stops short of full guidance.

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

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

With annotations declaring destructiveHint=true, the description should disclose side effects or state changes, but it only says 'focuses' without elaboration. It adds no behavioral context beyond the minimal verb, leaving the agent unaware of potential impacts.

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, which is efficient and easy to parse. However, it is so brief that it sacrifices informational depth, though for a simple tool with one parameter this brevity is acceptable.

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

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

Given the tool has a single parameter and no output schema, the description is incomplete regarding side effects (focus can change page state), return behavior, or use cases. The destructiveHint annotation signals this is not a pure read operation, so more context is needed to use the tool safely.

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

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

The schema fully documents the 'target' parameter (100% coverage), so the description's 'target element' adds little new meaning. It doesn't explain selector syntax or snapshot ID usage beyond what the schema already provides, but it does reinforce the parameter's role.

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 ('focuses') and identifies the resource ('target element'), clearly stating the tool's function. It lacks explicit differentiation from sibling tools like browser_click or browser_hover, but the action is distinct enough to be understood.

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 guidance is provided about when to use focus versus alternatives such as browser_click or browser_hover, and there are no exclusions, prerequisites, or context hints. The user is left to infer appropriate 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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the return format ('key-value dictionary') and scope ('all attributes'), but it does not disclose behavior for missing elements or whether it waits for the element.

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, front-loaded sentence with no redundant wording. It conveys the essential information 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 the low complexity (one parameter, read-only, good annotations), the description is largely complete. It could mention empty-result behavior or error handling, but that is a minor gap. The lack of usage guidance is a slight omission.

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

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

Schema coverage is 100%: the single 'target' parameter is described as 'Target element reference (snapshot ID) or CSS selector.' The description adds no further parameter semantics beyond the schema, so the 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 action ('Returns'), the resource ('all attributes of an HTML element'), and the output format ('key-value dictionary'). This specificity distinguishes it from sibling tools like browser_get_html or browser_get_element_state.

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 when element attributes are needed, but it does not explicitly state when to prefer this over alternatives like browser_get_element_state, nor does it mention any exclusions or prerequisites. Guidance is only implicit.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by naming the specific states checked, but it does not disclose the return format, behavior for missing elements, or any other side effects beyond what annotations already 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 sentence that front-loads the action and lists the relevant states without any redundant words. Every token contributes to the meaning, making it an exemplary concise specification.

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 getter with one parameter and clear read-only annotations, the description covers the core purpose and the set of states. However, given there is no output schema, it would be helpful to mention what the tool returns (e.g., booleans for each state or a single state). The lack of return-value detail is a minor gap, but the simplicity of the tool keeps the description 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?

The schema provides a complete description for the only parameter 'target' as 'Selector or snapshot ID of the element to check.' The description does not add any additional meaning to the parameter, so it relies entirely on the schema's already high 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 uses a specific verb 'Checks' and clearly specifies the resource ('element') while enumerating the exact states it can report: visible, enabled, editable, checked, or focused. This makes the tool's function unambiguous and distinguishes it from sibling tools like browser_get_attributes or browser_get_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?

The description implies usage by listing the states one can verify, but it does not explicitly state when to use this tool instead of alternatives, nor does it provide any exclusions or prerequisites. The intended use case is inferable but not clearly articulated.

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, so the safety profile is known. The description adds that omitting the target returns the entire page, which is useful context. However, it does not disclose return format or edge-case behavior, so it earns a mid-range 3.

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 immediately states the action and object, with no unnecessary words. Every word earns its place by covering the core behavior and the default case.

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

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

For a simple read-only tool with one fully described parameter and annotations indicating safety, the description is complete. It states what is returned and the two modes (element or page), so no further details are necessary 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?

The schema has 100% coverage for the single parameter, and the property description is identical to the tool description. The description adds no additional meaning beyond what the schema already provides, so 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 uses a specific verb 'Returns' and identifies the resource as 'raw HTML', with clear scope: a target element or the entire page. This differentiates it from sibling tools like browser_get_attributes and browser_get_links, which fetch different data.

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

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

The description clearly indicates when to use the tool (to retrieve raw HTML of an element or page) and the optionality of the target. It does not explicitly mention when not to use it or name alternatives, so it misses the 'exclusions' criterion for a 5.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is clear. The description adds the scope 'all links from the current page,' but does not elaborate on return format or edge cases like absent links. This is acceptable given annotations, but minimal.

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 with no filler. Every word carries meaning, specifying both the operation and the scope.

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 tool is simple with no parameters and clear annotations. The description adequately states what the tool does, although it leaves the exact return format unspecified. Given the tool's low complexity, this is 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 input schema has zero parameters, and the description appropriately requires none. Since there are no parameters to describe, the baseline of 4 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 uses a specific verb 'extracts' and a clear resource 'all links from the current page.' This distinguishes it from sibling tools like browser_get_html or browser_get_attributes, which extract other types of content.

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 its use when the agent needs to collect hyperlinks from the currently loaded page, but it does not explicitly mention when to prefer this over alternatives like browser_get_html or browser_snapshot. No exclusions or comparisons are provided.

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, so the safety profile is known. The description adds a clear list of retrieved fields, which is useful, but it does not disclose any additional behavioral traits such as whether it waits for page load or returns null for missing fields. Since annotations cover the key safety aspects, a score of 3 is appropriate.

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, well-structured sentence that front-loads the action (Retrieves) and then lists specific items. No fluff, no repetition of the tool name or annotations. Every word 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?

Since there is no output schema, the description must convey what is returned. It successfully lists the key fields (URL, title, frames, tabs count, viewport, agent info). The phrase 'including' suggests the list is not exhaustive, and it does not explain the shape of frames data or other nuances, but for a simple read-only tool this is reasonably 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 tool has zero parameters, and the schema is empty (coverage 100%). Per the rubric, 0 params gives a baseline of 4. The description adds no parameter info because there are none to explain, but it does clarify the output contents, which is helpful for interpretation.

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 starts with the specific verb 'Retrieves' and names the resource 'detailed page metadata', then enumerates the exact data types (URL, title, frames, tabs count, viewport, agent information). This clearly distinguishes it from sibling tools like browser_get_html (which returns HTML) and browser_snapshot (which returns accessibility snapshot).

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

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

The description implies the use case: when the agent needs page-level metadata, this is the tool. However, it does not explicitly state when to use it versus alternatives or mention exclusions. With many sibling tools covering similar data (e.g., browser_get_links, browser_get_attributes), more explicit guidance would be better.

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

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

The annotations indicate readOnlyHint=false and destructiveHint=true, covering the main safety aspect. However, the description adds no detail about side effects, such as submitting a form or canceling a prompt, beyond what the parameter names imply. It does not clearly disclose the consequences of accepting or rejecting.

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 extremely short and lacks necessary detail, making it under-specified. It is terse but not informative enough to guide an agent effectively, similar to a placeholder like 'Process'.

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 or additional context is provided. The description does not explain what happens after handling the dialog, how the parameters interact, or any post-conditions. This is insufficient for an agent to fully understand the tool's behavior.

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 'accept' (boolean) and 'promptText' (string for prompt dialogs). The description does not add extra meaning, but the schema already provides adequate parameter semantics, so the 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 'Handle a dialog' identifies the action and resource but is vague. It does not specify the type of dialog (alert, confirm, prompt) or the precise effect, though the 'accept' parameter implies accept/dismiss. It is distinct from sibling tools, but the purpose is under-specified.

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 guidance is provided about when to use this tool, such as after a dialog appears or in contrast to other browser actions. The description gives no context for the appropriate situation.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds context about intercepting the download event and saving to workspace, which is useful. However, it does not disclose specifics like overwrite behavior, file naming conflicts, permissions, or what happens if the download fails, so it only partially 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 sentence, front-loaded with the main action ('Clicks'), and contains no filler. Every word adds meaning, making it highly concise and well-structured.

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

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

With only two parameters and no output schema, the description covers the core action but omits important details such as the return value (e.g., saved file path), potential destructive side effects (e.g., overwriting files), and where exactly in the workspace the file is saved. Given the tool's simplicity, it is minimally complete but has 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%, with clear descriptions for both 'target' (selector or snapshot ID) and 'filename' (optional custom name). The tool description does not add additional parameter meaning beyond what the schema already provides, aligning with the baseline of 3.

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

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

The description uses a specific verb ('Clicks') and identifies the resource (element triggering download) and the outcome (intercepts download event, saves file to workspace). It clearly distinguishes from sibling tools like browser_click (just clicks) and browser_file_upload (uploads), making its 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 intended for clicking elements that trigger downloads and saving the resulting file, but it does not explicitly state when to use it over alternatives (e.g., browser_click) or mention exclusions. The context is clear enough for an experienced agent, but no explicit guidance is provided.

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 doesn't need to re-state them. The description adds no extra behavioral detail about side effects (e.g., triggering JavaScript events, potential menu changes). With annotations present, the bar is lower, but there's still room for more transparency about outcomes.

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 extremely concise—six words, no redundancy, and perfectly focused on the action. It follows a clear verb-object structure with no extra fluff, 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?

For a simple interaction tool, the description, alongside the parameter schema and annotations, is adequate. It lacks details on return values (but no output schema exists) and does not mention any prerequisites or setup. Given the simplicity, it covers essential context without being overlong.

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?

Both parameters (target and element) have descriptions in the schema, achieving 100% coverage. The tool description does not add further meaning beyond the schema; it simply restates the action. Since schema coverage is complete, 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 states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like click, drag, and type by specifying the hover action. However, it lacks detail about what the hover does (e.g., showing tooltips or hover menus), but the core purpose 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 gives no explicit guidance on when to use hover versus other interactions. While it's intuitive that hover is for mouse-over actions, the description doesn't mention edge cases or alternative tools (e.g., use click for activating, hover for previews). It provides minimal implicit usage 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 already declare readOnlyHint=false and destructiveHint=true, but the description adds no further behavioral context. It does not explain why the action is destructive, whether events are trusted, or what side effects might occur, so it fails to build on the annotation baseline.

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, clear sentence that is front-loaded and free of filler. Every word contributes to the meaning, making it highly concise and well-structured.

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 2-parameter tool with complete schema and some annotation coverage, the description is adequate but has gaps: it does not explain return values, behavioral effects, or when to prefer this over sibling tools. It is minimally complete but could be improved with usage context.

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 provides 100% coverage with clear descriptions for both parameters (key and action). The tool description adds no additional meaning beyond what the schema already documents, so the 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 it fires a keydown or keyup event for custom key combinations or modifier actions, using a specific verb+resource. It differentiates from siblings like browser_press_key (full press) and browser_type (typing) by focusing on separate keydown/keyup events.

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

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

The description implies usage for custom key combinations or modifier actions but does not explicitly state when to use this tool versus alternatives like browser_press_key or browser_dispatch_event. No exclusions or preference guidance are provided.

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

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

The annotations already signal destructive behavior (destructiveHint=true), so the description needed to add context beyond that. It does not specify that 'clear' clears all storage (since key is not required for clear), nor does it mention that 'set' overwrites existing values. The description merely restates the action enum from the schema without adding new safety or semantic 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?

The description is a single, focused sentence that front-loads the core purpose. Every word contributes to meaning, with no filler or redundancy. It is appropriately minimal for the tool's complexity.

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 schema and annotations cover parameters and safety, but the description does not clarify edge behaviors such as clearing the entire storage when no key is provided, or what the 'get' action returns. It is adequate for a simple tool but leaves these contextual gaps for the agent to infer.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter (action, storageType, key, value). The description adds no additional meaning 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 function: 'Inspects, sets, or clears values in local/session storage.' The verb+resource structure is specific and unambiguous, and it distinguishes this tool from sibling browser tools that handle navigation, clicks, or DOM interaction.

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?

Although no explicit alternatives are mentioned, the description clearly implies usage: it is the only tool for interacting with local/session storage among the siblings. The scope is unambiguous, so an agent can infer when to call it. It lacks explicit 'use this tool when...', but the uniqueness of its resource provides clear 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 already declare destructiveHint=true, so the description does not need to restate that. It adds the notion of intercepting and mocking/blocking, which is essentially the core behavior, but it does not disclose details such as whether mocks persist across navigation, how to later remove a route, or side effects on page behavior. This is minimal 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?

The description is a single sentence that front-loads the main action and immediately gives concrete examples. There is no wasted or redundant wording; every phrase 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?

With 4 parameters, no output schema, and a destructive action, the description is reasonably helpful but incomplete. It does not explain the lifecycle of a mock route, whether the interception applies to all requests, or what the return value looks like. The schema covers parameter details, but broader behavioral context is missing.

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

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

Schema coverage is 100%, with all parameters described. The description adds example URL patterns (images/ads) but does not provide additional meaning beyond the schema's own descriptions, so it meets but does not exceed the baseline for well-covered schemas.

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 ('intercepts and mocks/blocks') and clearly identifies the resource (network requests matching a URL pattern). It distinguishes from sibling tools by focusing on modifying/blocking rather than observing network activity, and includes concrete examples.

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 clear context (intercepting network requests for blocking or mocking) and gives examples of typical use cases. However, it does not explicitly mention when not to use this tool or suggest alternatives like browser_network_requests, so it stops short of a 5.

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

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

The description adds little beyond the annotations. It states the tool moves and clicks but does not disclose that clicking is optional (despite the schema default), nor does it describe the coordinate system, potential side effects, or event behavior. The destructiveHint annotation is present, but the description does not elaborate on what destructive consequences might occur.

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 with no filler, making it highly concise and front-loaded. While it lacks depth, it is appropriately brief for a simple tool, though a bit more context could be added without hurting 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 existence of sibling tools like browser_click and browser_hover, the description does not provide enough context to distinguish when this tool is the right choice. It omits the optional nature of clicking, the coordinate reference frame, and return behavior, making it under-specified for reliable 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?

The input schema provides 100% coverage of parameter descriptions, including x, y, click, and button. The description merely adds 'target coordinates' without providing extra meaning or clarifying edge cases, so it meets the baseline but adds little 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 identifies the tool as controlling fine mouse movement to specific coordinates and potentially clicking there. It distinguishes itself from browser_hover and browser_click by emphasizing coordinate-based movement, though it doesn't explicitly state that the click is optional, which could cause minor 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?

No guidance is provided on when to use this tool versus alternatives like browser_click or browser_hover. The description does not include any context about suitable scenarios, 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 does not elaborate on side effects such as discarding the current page, waiting for load, or handling errors. While annotations indicate destructiveHint=true, the description adds no extra context about the navigation behavior beyond the literal action.

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

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

The description is a single, direct sentence with no unnecessary words. It is appropriately sized for the simple action, though it could benefit from some additional context without becoming verbose.

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

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

The description lacks important context such as whether navigation waits for page load, how errors are reported, or the impact on the current browsing session. Given the tool modifies state (as indicated by destructiveHint), more context about the navigation behavior would be expected.

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 fully describes the only parameter 'url' with the same text as the description. Since schema coverage is 100%, the description adds no additional meaning or constraints (e.g., format, absolute vs. relative) beyond what is already in the schema.

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

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

The description clearly states the action 'Navigate to a URL' with a specific resource. It distinguishes from sibling tools like browser_navigate_back by implying forward navigation to a new URL, though it could be more explicit about the effect on the current page.

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 guidance is provided on when to use this tool over alternatives. It does not mention scenarios where browser_navigate is preferred over browser_navigate_back or other navigation methods, nor any 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 and annotations are consistent; destructiveHint is true, matching the navigation action which changes the current page. The description adds minimal behavioral context beyond the annotations, but does not contradict them. It does not mention potential side effects like what happens if there is no history or whether it affects new tabs.

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

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

The description is a single, concise sentence with no redundant wording. It directly states the action and target without unnecessary detail, which is ideal for a tool with no parameters.

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, parameterless tool, the description is largely complete. It communicates the essential operation. It could be improved by noting the behavior when there is no previous history entry, but the given context is sufficient for most use cases.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. The empty input schema is fully covered by the lack of parameters, making this baseline 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: 'Go back to the previous page in the history.' It identifies the resource (browser history) and the direction (back), making the core purpose unambiguous. It does not explicitly differentiate from sibling tools like browser_navigate or browser_tabs, but the meaning is clear enough in context.

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 the tool: when the user wants to go back to the previous page in history. However, it provides no explicit guidance on when not to use it, such as when a direct URL navigation via browser_navigate would be more appropriate, or what to do if no prior history exists.

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, covering safety. The description adds that it returns headers and body and can filter to a part, but does not elaborate on output structure or edge cases. Given annotation coverage, a 3 is appropriate.

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 redundant wording. The main purpose is front-loaded, the part option is explained, and the source of the index is given. 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?

For a read-only retrieval tool with full schema coverage and annotations, the description is sufficient. It explains the return type (full details or part) and the index source. It lacks explicit output format details, but the enum values for 'part' are self-explanatory.

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 parameters, so the schema already documents them. The description adds critical value by explaining that 'index' comes from browser_network_requests, which is not in the schema, enhancing clarity.

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 returns full details of a single network request, with an optional 'part' parameter to narrow down. It distinguishes from the sibling tool browser_network_requests by referencing its index, making the purpose unambiguous.

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

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

The instruction 'Use the number from browser_network_requests' explicitly guides when to use this tool—after obtaining a listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide.

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, covering the safety profile. The description adds valuable context about the temporal scope ('since loading the page') and the numbered list format, which goes beyond annotations 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?

Two concise sentences with no redundancy. The primary action is front-loaded, and the companion tool reference is placed efficiently at the end. Every word 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 tells the agent what the tool returns (a numbered list) and how to proceed for details. Since there is no output schema, this is essential. It does not describe potential error cases or edge scenarios, but for a read-only list tool with strong schema coverage, it is sufficiently 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?

All three parameters have schema descriptions covering 100% of the input schema. The tool description does not add any additional meaning to the parameters themselves, so the baseline of 3 applies; it neither enhances nor detracts from what the schema already provides.

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 it returns a numbered list of network requests since page load, and explicitly differentiates from the sibling tool browser_network_request by instructing to use that tool for details. This is a specific verb+resource with a clear scope.

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 an explicit usage pattern: first call this tool to get a list, then use browser_network_request with the number for full details. This is clear guidance on when to use it versus its companion, though it does not mention any other alternatives 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 does not mention any side effects, such as triggering keyboard events or potential destructive behavior. The annotations indicate destructiveHint: true, but the description adds no additional behavioral context beyond that.

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

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

The description is extremely concise — a single sentence that directly conveys the action. No unnecessary information or repetition.

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

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

For a simple action with a single well-defined parameter, the description is adequate. It lacks mention of when to use this tool (e.g., for shortcuts or navigation keys) but is otherwise complete for basic invocation.

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

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

The parameter 'key' is fully described in the schema with examples, and schema coverage is 100%. The description adds minimal extra meaning ('on the keyboard') but doesn't clarify key formats or special keys, which is already covered by 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 (press) and the resource (key on the keyboard). It is distinct from broader actions like navigate or click, though it does not explicitly differentiate from browser_type (typing) or browser_click (clicking).

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 guidance is provided on when to use this tool versus its siblings (e.g., browser_type for text entry or browser_click for mouse actions). The description lacks any contextual cues for choosing 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?

The description does not disclose any behavioral traits beyond the bare action. Annotations already indicate it is not read-only and is destructive, but the description adds no extra context about side effects like layout reflows or potential viewport changes.

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, short declarative sentence with no unnecessary words. It is perfectly concise and well-structured for the simple action it describes.

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, the description is adequate, but it lacks any extra context such as units (e.g., pixels), constraints, or when resizing might be appropriate. Given the simplicity and schema coverage, it is minimally complete but not rich.

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 both parameters (width and height), achieving 100% coverage. The description adds no additional meaning about the parameters, so it stays at the baseline of 3.

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

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

The description clearly states the action (resize) and the resource (browser window), making it distinct from sibling tools like navigate or click. However, it lacks any nuance about whether it resizes the viewport or the entire window, but the core purpose 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?

No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios like adjusting viewport for responsive testing or any conditions that would make it preferable to other navigation 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 destructiveHint=true and openWorldHint=true, so the description's 'Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent' adds specific severity and mechanism beyond the generic flags. This enhances transparency without contradicting annotations, though it could also mention side effects or sandboxing if any.

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 packs purpose and a crucial warning. It front-loads the action and immediately follows with the risk, maximizing information density with zero filler. Excellent structure.

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

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

Given the tool's complexity (arbitrary code execution) and the lack of an output schema, the description does not mention the return value or error behavior. The example in the code parameter shows a return, but that's in the schema. For an advanced tool, this is a notable gap, but the core purpose and danger are clear. A 3 reflects the missing return semantics and 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?

The input schema covers 100% of parameters with detailed descriptions, including the precedence rule for code vs filename. The tool description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate. The schema does the heavy lifting.

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

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

The description clearly states the action: 'Run a Playwright code snippet.' It specifies the resource (Playwright code) and immediately flags the critical distinction from siblings with 'Unsafe: executes arbitrary JavaScript ... RCE-equivalent.' This unambiguous verb+resource plus the danger label leaves no ambiguity about what the tool does and separates it from all other browser 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 a strong warning about safety ('Unsafe', 'RCE-equivalent') but does not explicitly state when to use it versus alternatives. It implies it's for advanced custom logic, but there is no direct 'use this only if...' or mention of safer alternatives. The warning serves as a caution but not a full usage guide.

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 destructiveHint: true and openWorldHint: true, but the description adds no further behavioral context, such as coordinate system interpretation, effect of combining target with coordinates, or whether the action has side effects beyond scroll position. It simply restates the basic function without enriching the agent's 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?

A single, concise sentence front-loads the action and resource, with no redundant words or filler. It is perfectly sized for the given complexity.

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 tool has four optional parameters and no required ones, but the description leaves ambiguity about default behavior when no parameters are provided and how the target and coordinates interact. Given the destructiveHint annotation, more behavioral caveats would be beneficial, but the schema partially compensates.

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 detailed descriptions for each parameter. The description adds minimal value by summarizing the modes but does not clarify parameter relationships or default behavior. This aligns with the baseline of 3 for high schema 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 uses a specific verb 'Scrolls' and clearly identifies the resource ('the page or a specific element') and the two modes ('into view or to custom coordinates'). This distinguishes it from sibling tools like browser_navigate or browser_find, leaving no ambiguity about its 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 implies usage for scrolling but provides no explicit guidance on when to choose this tool over alternatives. It does not mention when not to use it, such as when a simple navigation would suffice, leaving room for assumption.

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=true, so the description does not contradict that. But the description adds no further behavioral detail (e.g., side effects on the page). With annotations present, the bar is lower, and the description is neutral.

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 with no redundant words. It is well-structured and to the point.

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

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

The tool is simple and the schema covers all parameters. The description is short but sufficient for a basic understanding. It does not specify whether values are labels or values, but that is a minor omission given the context.

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 parameter descriptions for target and values. The tool description itself does not explain parameters beyond what the schema already provides, so it adds no extra semantic 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 (select) and the target (option in a dropdown), distinguishing it from more general actions like click or type. However, it does not explicitly contrast with sibling tools, so it misses a bit of distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention when selecting is appropriate or when other actions (e.g., click, type) might be preferred.

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 word 'emulates' adds a useful behavioral nuance (simulating, not changing the real location), but the description does not mention side effects, persistence, or how to reset. Annotations already indicate destructiveHint=true, but the description adds little beyond that.

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

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

The description is one concise sentence with no redundant words. However, it omits potentially useful context like parameter specifics or behavioral notes, so it is not maximally informative.

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

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

For a simple tool, the description is minimally adequate, but it lacks any usage context, side-effect disclosure, or clarification of the destructive hint. With no output schema and no guidance on when to use, it falls short of being 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?

The schema describes all three parameters (latitude, longitude, accuracy) with ranges and optionality, giving 100% coverage. The description does not add any semantic detail beyond what the schema provides, so it meets the baseline.

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

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

The description clearly states the tool emulates a specific geographic location for the browser context, with a specific verb ('emulates') and resource. This distinguishes it from all sibling browser tools, none of which address 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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context such as when emulation might be needed. It lacks any 'use when' or exclusionary language.

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, so the safety profile is clear. The description adds 'capture' but no further behavioral detail beyond what annotations 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 concise sentence. The phrase 'this is better than screenshot' adds some comparative value but could be considered slightly extraneous.

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

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

There is no output schema and the description does not explain what format the snapshot takes, how parameters like depth or target affect the result, or what kind of accessibility information is included. This leaves important context missing for an agent deciding whether and how to call the tool.

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

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

Schema covers all 4 parameters with descriptions, so the baseline is 3. The description does not add any additional parameter meaning or usage notes beyond the schema.

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

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

States a clear action ('capture') and object ('accessibility snapshot of the current page'), and distinguishes itself from screenshot with a comparative remark, though 'better than screenshot' is somewhat vague.

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

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

Gives minimal guidance by saying 'better than screenshot', but does not explicitly state when to use this tool over alternatives like browser_evaluate or browser_console_messages, nor when not to use 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. However, the description adds no behavioral context beyond what the schema provides (e.g., index omission for close closes current tab is in schema). No mention of side effects like tab switching or browser-level changes.

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 efficiently lists all supported actions. It is front-loaded with verbs and avoids unnecessary 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?

The tool has multiple actions and a required action parameter. The description lists the actions but does not explain action-specific requirements (e.g., URL required for new, index for close/select) or edge cases like closing the last tab. Given the schema covers parameter details, the description is adequate but not rich. With no output schema, the agent must infer return values from the 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 description coverage is 100% with each parameter having a description (url, index, action with enum). The tool description adds no parameter-level detail, so it does not go beyond schema. Baseline 3 applies.

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

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

The description clearly states the tool's purpose with specific verbs (list, create, close, select) and a specific resource (browser tab). It distinguishes from siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab) by focusing on tab 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?

The description implies usage through the list of actions but provides no explicit when-to-use guidance or exclusions. Given siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab), an agent might benefit from explicit differentiation, but the actions themselves are clear enough that usage is implied.

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

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

The annotations already indicate read-only and non-destructive behavior. The description adds useful context beyond annotations by clarifying that screenshots are not suitable for interaction and that browser_snapshot should be used for actions. This is helpful but not extensive.

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 well-structured: two sentences that front-load the core purpose and immediately follow with a crucial usage caveat. There is no unnecessary verbosity 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?

Given the simple nature of the tool and the rich schema annotations, the description is largely complete. It could mention that screenshots are for visual inspection, but the title and schema fill most gaps. The explicit distinction from browser_snapshot adds important context.

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 description coverage is 100%, so the baseline is 3. The description itself does not add parameter details, but the schema already provides clear explanations for each parameter, including enums, defaults, and constraints.

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: 'Take a screenshot of the current page.' It also distinguishes itself from browser_snapshot by explicitly noting that screenshots cannot be used for actions, which helps differentiate it from a key sibling tool.

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

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

It provides explicit when-not-to-use guidance by stating 'You can't perform actions based on the screenshot, use browser_snapshot for actions.' This directly names the alternative tool and the condition for choosing 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?

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, establishing the safety profile. The description adds the behavioral detail that the screenshot is saved to the workspace, which is not covered by annotations. It does not contradict the read-only hint, as saving a local file does not mutate the external browser state.

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, tightly worded sentence that front-loads the core action and destination. It contains no filler, redundancy, or unnecessary qualifiers. Every phrase contributes to understanding the tool's function.

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 full schema coverage and clear annotations, the description is adequate. It covers the primary behavior (element screenshot and workspace save) but does not mention what the tool returns (e.g., file path) since no output schema exists. This is a minor gap; the overall information provided by description, schema, and annotations is sufficient 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?

The schema has 100% parameter description coverage, with each of the three parameters (type, target, filename) fully explained. The description itself adds no extra parameter-level detail, but given the schema's thoroughness, the baseline of 3 is appropriate. No need for the description to repeat what the schema already provides.

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 that the tool takes a screenshot of a specific element and saves it to the workspace. This distinctive verb+resource phrasing sets it apart from the sibling browser_take_screenshot, which presumably captures the full page. The purpose is immediately obvious and 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 does not explicitly mention when to use this tool versus alternatives, such as browser_take_screenshot for full-page captures. No when-not conditions or alternative tool references are provided. Usage is implied by the name and description, but an agent must infer the distinction without direct guidance.

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

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

Annotations already indicate a write operation with destructive potential (readOnlyHint=false, destructiveHint=true). The description adds the trait 'deterministically' suggesting it sets the state directly, but does not elaborate on event firing or side effects. 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?

Single sentence, concise, front-loaded with action and target. 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 2-parameter tool and existing annotations, the description covers the core action but omits return behavior and any prerequisites. Since there is no output schema, the agent might need to know if a result is returned. Overall adequate but not rich.

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 100% of parameters with descriptions for target and checked. The tool description adds no additional semantic detail to the parameters beyond repeating 'checkbox/radio button'.

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 the specific verb 'Checks or unchecks' with resource 'checkbox/radio button element', clearly distinguishing it from sibling tools like browser_click or browser_select_option. It is specific and 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 does not explicitly state when to use this tool over alternatives like browser_click, nor does it mention preconditions or exclusions. The word 'deterministically' subtly hints at superiority over clicking but no direct guidance 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?

The annotation destructiveHint=true and readOnlyHint=false already signal that this tool can modify state, so the description does not contradict that. However, the main description adds no additional behavioral context beyond the annotations, such as whether typing overwrites existing content or triggers page events. The parameter descriptions do mention key-handler triggering and Enter submission, but the main description itself stays shallow.

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, focused sentence with no filler or repetition. It front-loads the verb and object, making the tool's primary purpose immediately obvious.

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 several closely related siblings (fill_form, press_key, click), the description is too thin to fully orient an agent. It lacks any mention of when typing is appropriate, how the target is resolved, or what side effects to expect, so the agent must rely on parameter descriptions and external context to make a confident choice.

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

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

Schema coverage is 100%, so the baseline is 3 because the input schema already documents all five parameters. The main description, 'Type text into editable element,' adds no meaning beyond the schema's parameter descriptions, which already define text, slowly, submit, target, and element clearly enough.

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

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

The description states a clear action ('Type text') and a clear target ('editable element'), which distinguishes it from many sibling tools at a high level. It is slightly vague about whether 'editable element' includes textareas, contenteditable regions, or only input fields, but the core purpose is unambiguous.

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

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

The description gives no guidance on when to prefer this tool over sibling tools such as browser_fill_form or browser_press_key. It does not mention exclusions, prerequisites, or scenarios where typing would be inappropriate, leaving the agent to infer usage from the tool name alone.

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

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

Annotations already declare the tool as destructive and a write operation, and the description adds the specific behavioral detail of bypassing the modal. However, it does not disclose additional traits such as replacement of existing selections, error conditions, or side effects on 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?

Single sentence, immediately front-loaded with the action, and every word contributes useful information. No redundancy or structure issues.

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

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

Despite the short length, the combination of the description and schema fully specifies how to invoke the tool: target identifies the file input element, paths provides local file paths, and the description clarifies the direct bypass mechanism. An output schema is absent, but for this simple mutation the description is sufficiently 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% with both parameters clearly described. The description adds no extra parameter-level meaning, so per rules the baseline score is 3.

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

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

Description clearly states a specific action ('directly sets input files on a file input element') and includes a differentiator ('bypassing the file-chooser modal requirement'), which distinguishes it from standard upload tools. This gives the agent an accurate understanding of the tool's unique 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 implies a use case (when bypassing the file-chooser modal is desired) but does not explicitly state when to use this tool versus siblings like browser_file_upload or browser_drop, and lacks exclusions 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?

The description adds behavioral detail beyond the readOnlyHint by explaining that it waits for text appearance/disappearance or a time delay. However, it does not specify what happens if multiple parameters are provided or if none are provided, so behavior 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 a single concise sentence that front-loads the core action and conditions. It contains no unnecessary words and 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?

For a simple wait tool with no output schema, the description covers the main use cases, but it omits edge cases such as default behavior when no parameters are supplied, timeout behavior, or error conditions. These gaps make it only partially 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 schema descriptions already cover each parameter individually, and the tool description mostly restates them. It does not clarify the relationship between text, textGone, and time (e.g., whether they are mutually exclusive or combinable), so minimal semantic value is added beyond the schema.

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

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

The description clearly states the tool waits for a condition: text to appear, text to disappear, or a specified time to pass. This distinguishes it from sibling tools like click, navigate, or type, and its 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 implies when to use the tool (when waiting for page state or a delay), but it does not explicitly state when to prefer this over alternatives or how to choose among text, textGone, and time parameters. It provides functional guidance but lacks explicit usage conditions.

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

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

The description adds meaningful behavioral detail beyond the annotations: the 500ms idle threshold requirement. It clarifies that it waits for a stable idle state, which is useful context. Annotations already cover read-only and non-destructive nature, so the bar is lower, and this description 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?

A single, focused sentence that states exactly what the tool does. No redundancy or extraneous information.

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

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

For a simple, single-parameter wait tool with read-only annotations, the description provides sufficient detail: the trigger condition and the stability threshold. No output schema is needed, and the absence of extra behavior 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?

Schema coverage is 100% — the timeout parameter is fully described in the schema with its default and unit. The description adds no extra parametric detail, so the baseline 3 applies.

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

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

The description uses a specific verb 'waits' and clearly identifies the resource and condition: network idle state for at least 500ms. This distinguishes it from siblings like browser_wait_for (which likely waits for other conditions) and browser_network_requests (which lists requests).

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: use this when you need to wait for network activity to settle. However, it does not explicitly mention alternatives or when not to use it, leaving the agent to infer from the name and sibling tool names.

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 signal side effects (destructiveHint=true, readOnlyHint=false), so the description appropriately doesn't repeat safety warnings. It adds useful specifics like saving to a target directory and returning a local path, but doesn't disclose overwrite behavior or failure scenarios, which is a minor gap 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?

The description is compact (two sentences), front-loaded with the primary action, and every phrase adds value. No filler or redundancy.

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

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

For a simple tool with well-documented parameters and no output schema, the description adequately covers the return value and main behavior. It could mention error handling or edge cases, but given the tool's simplicity and the presence of annotations, it is sufficiently complete. A 4 reflects that minor behavioral details are missing.

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

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

The input schema has 100% coverage with descriptive text for both url and outputDir. The description mentions target directory and absolute local path, but these echo the schema without adding significant new meaning. 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 action (downloads an image, converts it to PNG), the resource (image from a URL), and the output (saves to a directory, returns absolute local path). This specificity distinguishes it from all sibling browser tools, which are unrelated to image processing.

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 a clear context: use this tool when you need to download an image and convert it to PNG, saving it locally. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous given the tool's unique function among siblings.

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