Chrome Bridge
Server Quality Checklist
Latest release: v1.15.0
- Disambiguation4/5
Most tools have clearly distinct purposes, but some overlap exists (e.g., multiple screenshot and page-reading tools). Descriptions help differentiate, but agents may occasionally select the wrong tool for a task.
Naming Consistency3/5Tool names generally follow a verb_noun pattern (e.g., get_status, click), but exceptions like tab_action, viewport_resize, full_page_screenshot, and screenshot_diff break consistency. Conventions are mixed but still readable.
Tool Count2/560 tools is excessive for a single MCP server. Many tools (e.g., accessibility_audit, unused_css) are niche and could be separated. The large surface area may overwhelm an agent.
Completeness5/5The tool set comprehensively covers browser automation: navigation, interaction, DOM, storage, network, screenshots, performance, accessibility, SEO, and more. No major gaps are apparent for the stated purpose.
Average 4.1/5 across 55 of 60 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 162 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states the tool can write to clipboard, but annotation idempotentHint=true implies the operation is safe to retry without side effects. Writing is typically not idempotent, creating a contradiction. The description adds 'activates the tab first' but is undermined by the inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose and a key behavior (tab activation). No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention return values for read operations or error handling. With no output schema, the user is left uninformed about what the tool returns on read. The tab_id parameter behavior is explained in schema but not reinforced in description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides for the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read or write' and the resource 'system clipboard (text)', and adds a specific behavioral detail 'activates the tab first'. It uniquely identifies the tool among siblings, as no other sibling tool mentions clipboard operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies clipboard interaction but does not mention when-not or suggest alternative tools for similar tasks (e.g., using type_text for paste).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations: it says 'start one' (action=download) which has side effects (creates a file in the Downloads folder), while annotations declare readOnlyHint=true, implying no side effects. Although the description richly describes the saveAs behavior, the contradiction is a serious issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, and each sentence provides relevant detail. It is concise without being terse, though the technical depth might be slightly heavy for a quick scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema. The description explains the trickiest part (download state) but does not describe the return format for list or wait_for_complete, nor does it mention timeout/limit behaviors beyond what the schema already states. This leaves some gaps for an agent to fully understand expected outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters, but the description adds crucial nuance beyond the schema, particularly for action=download: it explains that it reports the real download state and details the waiting_for_user behavior under saveAs prompts. This adds value beyond the structured field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with specific verbs: 'List downloads, start one, or wait for the newest to finish.' It clearly identifies the resource (downloads) and the three distinct operations, distinguishing it from sibling browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('Files land in the browser Downloads folder, not on the server') but does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or alternative tools. The usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that contrast check is approximate, but does not disclose output format or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise line; no wasted words. Could be slightly more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description should explain what the tool returns (e.g., list of issues). It only lists checks, leaving output ambiguity. Incomplete for a multi-check audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% parameters. Description adds natural language meaning to the checks parameter by listing specific issues (e.g., 'missing alt' for images), going beyond schema enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'audit' and resource 'accessibility', listing specific checks (alt, links, headings, ARIA, contrast, forms). Distinct from sibling tools like seo_audit and check_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description omits the destructive side effect of clearing the buffer via the 'clear' parameter. It does not elaborate on behavioral traits beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise 12-word sentence that efficiently communicates the tool's core function without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 5 parameters and no output schema, the description lacks guidance on output format and does not address the destructive nature of the 'clear' parameter. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds no extra meaning or context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'console messages captured since page load', specifying the scope and types included. This uniquely identifies the tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like query_dom or get_status. It lacks any when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds stateful behavior (install watcher on first call) which contradicts the 'idempotentHint: true' annotation. While it discloses more about usage pattern than annotations alone, the contradiction reduces reliability. Missing details on side effects like buffer limits or callback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences covering the core functionality and phase behavior. No redundant words; essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameter details are fully covered by the schema, the description lacks information about return format, how mutations are structured, and the lifecycle of the watcher. For a tool with 9 parameters, more behavioral context (e.g., how to stop/clear) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no additional meaning beyond the schema. Each parameter's purpose is already clear from the schema, so no extra value from the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool watches DOM mutations via MutationObserver and explains the two-phase behavior (install then read). It distinguishes itself from siblings like 'query_dom' or 'modify_dom' by specifying the observation pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for tracking DOM changes over time but does not explicitly state when to use it versus alternatives like 'get_interactives' or 'execute_js'. No exclusions or prerequisite conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety and idempotency are clear. Description adds specific metadata types, but no additional behavioral context (e.g., network requests, performance impact).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, clearly front-loading the purpose. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists the output components (meta tags, scripts, etc.), providing sufficient context for an agent to understand what will be returned, even without an output schema. Could mention return format but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description does not add extra parameter information beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb and resource: 'Get page metadata' and lists specific items (meta tags, scripts, stylesheets, links, forms). Distinguishes from siblings like query_dom (broader) and get_interactives (interactive elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Among many sibling tools, no context is provided for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds that the tool writes an MHTML archive to the server filesystem, which elaborates on the destructive nature but does not detail side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all essential information without redundancy or unnecessary details. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description adequately covers the operation. However, it omits potential edge cases, such as errors from invalid paths or overwrite behavior, which could be important for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already describes both parameters. The description adds no extra semantics beyond the schema, such as the meaning of 'last tab navigated' for tab_id. Therefore, it provides minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (save), the resource (full page), and the output format (MHTML archive file). It distinguishes from sibling tools like screenshot (image capture) and read_page (content extraction) by specifying the archive format and filesystem destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to prefer save_page over screenshot or get_page_info. No context about prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by differentiating the two scroll modes and mentioning conditions like 'network idle' and 'infinite scroll.' However, it does not disclose potential side effects such as triggering lazy loading or the impact of parameters like settle_ms and step_px. Annotations are minimal, so the description carries some burden but is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the key information about the two actions. The redundant 'Scroll.' at the start is minor. It is well-structured for quick reading, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema), the description provides a minimal overview of the two main modes but lacks details on how to use parameters like 'selector', 'offset_y', 'step_px', etc. It is enough for basic understanding but incomplete for advanced usage. The schema descriptions help, but the tool description could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description provides a high-level overview of the 'action' and 'until' parameters, but does not add significant meaning to other parameters like 'x', 'y', 'selector', or 'offset_y'. It clarifies the purpose of the two modes, which is useful, but overall adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the page and defines the two distinct actions ('to' and 'until') with specific behaviors. However, it could be more explicit about the overall function (e.g., 'Scroll the current page') rather than just 'Scroll.' Distinguishes between modes but not from sibling tools, which are mostly unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each action: 'to' for one-time scroll to element/coordinates, 'until' for repeated scrolling until a condition. This provides clear context but does not include explicit when-not or alternatives, though none are obviously needed for a scroll tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 value by listing the specific checks performed, which helps the agent understand what the tool examines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the tool's purpose and lists checks. It wastes no words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the checks but omits information about the output format, return structure, or how results are presented. Given the absence of an output schema, this lack of detail could hinder the agent's understanding of what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter ('tab_id'). The description does not add additional semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an SEO audit and lists specific checks (title/description lengths, canonical, etc.). It uses a specific verb ('audit') and resource ('SEO'), and effectively distinguishes from sibling tools like 'accessibility_audit' and 'check_links'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when SEO analysis is needed, but does not explicitly specify when to use this tool versus alternatives (e.g., 'web_vitals', 'accessibility_audit'). No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive. The description adds that it writes a JSONL file and strips tab_id. It does not disclose potential side effects like file persistence or session state changes beyond recording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences provide essential information: recording purpose, CLI replay command, and tab_id behavior. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers key behaviors. Minor gaps: no details on return from status/list actions or file location.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters. The tool description does not add meaningful parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records session commands to a replayable JSONL file. It mentions CLI replay and tab_id stripping. However, it does not explicitly differentiate from sibling tools like session_fixture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording sessions and mentions replay behavior, but does not provide explicit guidance on when to use this tool vs alternatives, nor reasons 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and readOnlyHint=false, which the description does not contradict. The description adds that it is a page-level patch and that reset restores native behavior, but does not elaborate on persistence or scope beyond the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with the main action. It is efficient but could be slightly more structured with separation of setting and resetting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is adequate but does not explain the interaction between reset and coordinates, or the temporary/durable nature of the override. It lacks guidance for typical testing scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema (e.g., 'reset restores native' is implicit in the reset parameter description).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: override navigator.geolocation with fixed coordinates. It also mentions the reset capability. This distinguishes it from sibling tools, as no other tool handles geolocation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (setting coordinates for testing), but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that verification is server-side with no CORS limits and real HTTP status, which provides useful context beyond annotations but does not disclose potential rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. Every word earns its place with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6 parameters and no output schema, the description is quite minimal. It does not explain what constitutes a 'broken' link (e.g., 4xx, 5xx, timeouts) or how results are returned (lines/json), though the schema provides some clues. More detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and adequately documents each parameter. The description does not add extra meaning or usage guidance for parameters beyond what the schema provides, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks page links for broken URLs, verified server-side. This distinguishes it from client-side link checks and other diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for server-side link verification, but does not explicitly state when to use it over sibling tools like 'accessibility_audit' or 'get_status.' No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying that events are 'React-compatible', indicating synthetic event dispatch. It also lists handled element types. Annotations already denote idempotency (idempotentHint=true) and non-destructive nature (destructiveHint=false). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling ~15 words. It front-loads the verb 'fill' and quickly covers scope. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, batch operation) and lack of output schema, the description omits details about return values, error handling for missing fields, or effect of submit_selector. It's minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description does not elaborate on individual parameters beyond what the schema already provides. The mention of 'React-compatible events' is general context, not parameter-specific, so the description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: batch filling form fields with React-compatible events. It specifies the supported element types (input, select, checkbox, radio, textarea), distinguishing it from siblings like type_text for single-field input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use fill_form versus alternatives like type_text or click. It does not mention efficiency trade-offs or appropriateness for single-field vs. multi-field scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world behavior. The description adds valuable context: results depend on real navigations and may require reloading. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with header list, no fluff. Each sentence provides necessary information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of output format or return values. With no output schema, the description could be more complete, though the tool's simplicity and annotations partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter tab_id described. The description adds no additional meaning to the parameter, staying at baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it audits security headers, listing specific ones like CSP, HSTS, XCTO. The verb 'audit' and explicit header names make purpose unambiguous. No sibling tool has overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives like accessibility_audit or seo_audit. The note 'reload if unavailable' implies a dependency on navigation but does not provide clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating that hover triggers CSS and JS hover handlers. Annotations already provide idempotentHint=true and destructiveHint=false, so this context is useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no wasted words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple hover action with no output schema, the description adequately covers the tool's behavior. It mentions the triggered events, which is sufficient. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds minor context ('by CSS selector or ref' and events triggered), but not significant beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover) and the resource (element by CSS selector or ref), and it distinguishes from sibling tools like click and type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives, such as click or type_text. The description does not mention conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint, readOnlyHint, and destructiveHint. The description adds the behavior of returning interactive element previews, which is useful beyond annotations. However, it does not mention waiting for page load or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the core action, second describes the return value. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value. It covers the primary behavior and return format. However, it lacks details on error scenarios or prerequisites (e.g., tab existence).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both 'url' and 'tab_id' are fully documented in the schema. The description repeats 'URL' but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Navigate a Chrome tab to a URL') and the return value (preview of interactive elements). It distinguishes 'navigate' from sibling interaction tools like 'click' and 'type_text' by focusing on URL navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after navigation for element interaction, but does not explicitly state when to use 'navigate' vs alternatives like 'create_tab' or 'get_tabs'. No exclusion criteria or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are mostly false, so description carries burden. It discloses the DataTransfer mechanism and a 10MB limit, but omits behavior on size exceedance, path errors, or whether it clears existing files. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words. Front-loaded with the action and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 params fully described in schema, the description adds the 10MB limit and mechanism. Missing error behavior or return value, but complete enough for a straightforward file upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds only the 10MB limit, which is not per-parameter. Baseline 3 achieved; no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a file from the server filesystem to an input[type=file] via DataTransfer, with a 10MB limit. This is specific and distinct from sibling tools like fill_form or type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for file inputs but does not explicitly state when to use vs alternatives or any exclusions. No 'when not to use' or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive behavior. The description adds the event family implementation detail but does not disclose other behavioral traits like timing, side effects (e.g., element reordering), or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. Every word adds meaning, and the semicolon effectively separates the general action from mode specifics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of drag-and-drop (source, target, modes, frames, tabs) and no output schema, the description is adequate but thin. It does not explain return values, waiting behavior, or what constitutes a successful drop.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage), so the tool description's role is diminished. However, it adds valuable context for the 'mode' parameter by explaining the difference between html5 and pointer events, which goes beyond the schema's 'which event family to emit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Drag an element onto another') and distinguishes by specifying two event families (html5 vs pointer). This verb+resource structure is specific and distinct from sibling tools like click or hover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description explains when to use each mode ('html5 = DragEvent+DataTransfer; pointer = pointer/mouse events'), it lacks explicit guidance on when not to use this tool or alternative approaches. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show idempotent, not read-only, not destructive. The description adds useful behavioral details: rules survive reloads, stub responses use a local helper, and HTTPS pages require a trustworthy stub host. However, the 'list' and 'clear' actions are omitted from the description, creating a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently conveys scope, persistence, and capabilities. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core interception capabilities but omits actions 'list' and 'clear', the url_filter parameter, and resource_types. The lack of an output schema is not compensated by description. Adequate but not fully comprehensive for a complex tool with 10 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description summarizes action types but does not add new meaning or detail beyond the schema (e.g., url_filter, resource_types).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool intercepts network requests browser-wide, survives reloads, and lists specific actions: block, redirect, set/remove headers, stub responses. This distinguishes it from sibling tools like http_request (single request) and monitor_network (monitoring only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for persistent network rule manipulation but does not explicitly contrast with alternatives like monitor_network or http_request. No 'use this for' or 'if you need' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context about polling timeout and pattern syntax, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core functionality and pattern syntax are conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers main conditions, patterns, and replay context. It lacks explicit return behavior but is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described. The description adds minimal extra meaning, only summarizing condition types and pattern styles. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to assert page conditions (element existence/visibility, text, URL/title) with polling until timeout. It distinguishes from siblings by focusing on assertion rather than observation or waiting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for assertions but does not provide explicit guidance on when to use this tool versus alternatives like wait_for or query_dom. No exclusions or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details about attaching nearby interactive elements with refs for interaction. This is valuable context beyond annotations, though it does not cover edge cases like no match found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose, followed by an important behavioral detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values (parent selector, context, visibility, position, interactive elements). It covers the main aspects but could be more explicit about the list of matches and behavior when no match is found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description does not add additional meaning or usage hints for parameters beyond what the schema provides. The mention of 'parent selector, context, visibility, position' refers to output, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds text on a page and specifies what it returns: parent selector, context, visibility, position per match, and attached interactive elements for the first visible match. This is specific and distinguishes it from sibling tools like query_dom or get_interactives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding text and obtaining interactive elements, but it lacks explicit guidance on when to use this versus alternatives like query_dom. No when-not-to-use conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds minimal extra context beyond listing fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check, the description adequately lists key fields. Could elaborate on field meanings or possible values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (100% coverage). Description lists output fields, adding value beyond empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check bridge status' and lists specific fields (extension connection, server mode, port, version). This distinguishes it from sibling browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for checking bridge status, but no explicit when-to-use or when-not-to-use compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by specifying 'since page load', which limits the scope. Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which are consistent. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It is front-loaded with the verb and resource, then succinctly describes the output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by indicating the output format (counts by type + recent entries). However, it could elaborate on what constitutes 'recent entries' or any limits. Overall, it is sufficiently complete for a non-complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description does not add significant new meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing addEventListener registrations since page load, with specifics on output (counts by type and recent entries). This distinguishes it from other sibling tools like query_dom or get_interactives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting event listeners, but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions. Some guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by stating what is returned (structure, attributes, bounding rect, computed styles), and the schema covers the limit and selector details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and key details. No unnecessary words; highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately hints at the return format (structure, attributes, bounding rect, computed styles). It could mention that results are an array or ordered by DOM order, but it is sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only mentions the selector in the tool description but not the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Query DOM elements by CSS selector) and the return data (structure, attributes, bounding rect, computed styles). It is specific and distinguishes from siblings like get_interactives or modify_dom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus others. It implies usage for general DOM querying but does not mention alternatives or exclusions. Given many sibling tools, more context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds value by disclosing the approximation and the limitation of cross-origin sheets being unreadable, which is helpful for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with full schema coverage and no output schema, the description covers purpose and limitations. However, it could mention the output format (list of selectors) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any extra meaning about the parameters beyond what the schema provides via their descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'CSS selectors matching nothing in the current DOM', and distinguishes it from siblings like 'query_dom' and 'inject_css' by focusing on unused selectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for detecting unused CSS rules but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives despite many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds that the tool lists frames with specific fields, which is consistent with annotations and not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 16-word sentence that is front-loaded with the verb 'List' and resource. Every word adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description covers the purpose, output structure, and usage context. It is complete enough for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter tab_id, and the description does not add any additional semantics or details about the parameter beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List frames (main + iframes) with frameId, parent, URL', specifying the verb (List), resource (frames), and output fields. It distinguishes from siblings like get_tabs by targeting frame IDs for DOM tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'for the frame_id parameter of DOM tools', indicating when to use this tool (to get frame IDs for DOM operations). It does not mention when not to use or list alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, and the description adds logging behavior and the reset functionality. It discloses that dialogs are auto-handled and logged, but does not detail the log format or potential side effects like interference with user interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise, and front-loaded with the primary action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with clear schema and annotations, the description and schema together fully explain the tool's capabilities. The log return is mentioned, and optional parameters are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description adds minimal extra value beyond what the schema already provides. The description mentions logging and reset but not parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool auto-accepts or dismisses future JS dialogs (alert/confirm/prompt) and logging them, with a reset option. It uniquely identifies the resource and action among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dialog handling but does not explicitly state when to use this tool vs alternatives or when not to use it. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-readonly behavior. The description adds important context about MAIN world execution and the permission toggle, complementing annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise two sentences: first sentence states core purpose, second sentence adds essential setup requirement. No wasted words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and setup requirement well. Schema already documents that the return value is the last expression result. Could mention async behavior, but overall sufficiently complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully documented in the schema with 100% coverage. The description adds no additional semantics beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs JavaScript in the MAIN world of the page, using specific verb 'run' and resource 'JavaScript in the page', distinguishing it from similar sibling tools that may operate in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear precondition (requires 'Allow user scripts' toggle) and a helpful note about error messages explaining setup if disabled. However, it does not explicitly compare with alternative tools like query_dom or modify_dom.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds useful context: deterministic, parsed server-side from main-document HTML. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose. Every part adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested object, no output schema), the description covers the core usage and behavioral context. It lacks explicit mention of defaults or output format, but schema descriptions fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The description adds a general pattern explanation but does not provide details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads repeated non-tabular structures as records per item, with specific examples (product cards, list items, search results). It distinguishes from siblings like extract_table by specifying 'non-tabular'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (non-tabular structures) and hints at alternatives (extract_table for tables), but does not explicitly state when not to use or list alternatives. The context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by detailing what elements are considered actionable (buttons, links, inputs, roles, onclick) and that it returns selectors, labels, positions, and flags. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Only two sentences, both front-loaded with the tool's purpose and key benefit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage, no output schema, and annotations, the description provides sufficient context about what the tool returns and when to use it. It could mention return format (lines/json) but the schema already covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description does not add parameter-specific meaning beyond the schema, but the overall usage context helps. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists actionable elements (buttons, links, etc.) with ready-to-use CSS selectors, labels, positions, and flags. It distinguishes itself from sibling tools by recommending preference over dumping HTML.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer this tool over dumping HTML to discover selectors, providing clear usage guidance. Could be strengthened by mentioning conditions where alternatives are better, but it's still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds valuable context: credentials are stored in-memory only, browser-wide. This is consistent with annotations and improves understanding beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that captures verb, resource, scope, and key constraints. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers purpose, scope, and parameter dependencies. It could mention that credentials apply to all requests (global) or note potential security considerations, but for a simple set/clear tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The description reinforces the action enum and indicates username/password are required for action=set. This adds marginal clarity, but the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set/clear), the resource (credentials for HTTP Basic/Digest auth dialogs), and the scope (browser-wide, in-memory only). It is specific and distinct from sibling tools, which are unrelated to auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for HTTP Basic/Digest auth dialogs'), providing clear context. It does not explicitly mention when not to use or alternatives, but the context is sufficiently narrow given the diverse sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint true and readOnlyHint false, but the description adds critical context: the request carries browser cookies, text bodies are capped by max_length, and save_to writes bytes to a path. It explains why read_page fails on PDFs. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the key feature (carries session cookies) and provides necessary details without redundancy. Every sentence adds value, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description addresses authentication and binary content handling effectively, but lacks details on response structure (e.g., status codes, headers) and error behavior. Given the tool's complexity and no output schema, more context on return types and possible failures would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds semantic value by explaining how max_length and save_to interact (text vs. binary) and the effect of method HEAD as noted in schema. This goes beyond the schema's attribute descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool makes HTTP requests from the browser, carrying session cookies, which distinguishes it from server-side requests. It explicitly mentions fetching authenticated content like invoices and JSON, and explains the use of save_to for binary files such as PDFs, differentiating from read_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains that the tool carries session cookies, making it suitable for authenticated content. It provides explicit guidance on using save_to for binary content like PDFs instead of read_page. However, it does not explicitly list when to avoid using this tool or compare with other tools beyond the PDF scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes dependency on zoom and viewport, advising use of set_zoom(1) and fixed viewport_resize for consistency. Adds behavioral context beyond readOnlyHint and idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose, followed by behavioral context. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters implicitly, and behavioral context. Missing output description (no output schema), but otherwise sufficiently complete for a measurement tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover parameters (100% coverage). Description adds minor detail about shadow DOM piercing for selector2, but does not significantly enhance meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the verb 'measure' and the resource 'gap, overlap and distance in CSS pixels between two elements'. Distinguishes from sibling tools like query_dom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for layout measurement but lacks explicit guidance on when to use vs alternatives or when not to use. Suggests using set_zoom and viewport_resize for comparability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. Description adds transparency that changes are not persisted across reloads and that only the first match is modified. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a one-sentence alternative recommendation. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters fully described in the schema, no output schema, and annotations providing safety profile, the description adequately covers core functionality and persistence behavior. Could enhance by contrasting with query_dom for read-only access.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and descriptions. The description does not add additional context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes an element in the live DOM, enumerates specific actions (setAttribute, removeAttribute, etc.), and contrasts with inject_css for bulk styling. It differentiates itself from sibling tools like inject_css.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use inject_css instead for many elements, providing clear guidance. Does not explicitly exclude other scenarios, but the contrast is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds valuable context about the source=page hook being 'installed on first call' and that format=har exports HAR 1.2 for external tooling. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with key details front-loaded. No redundant phrases or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Core behavior and all parameters are documented in schema. Description adds source installation detail and har export purpose. Could briefly describe lines/json output format, but overall sufficient for a monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds nuance beyond schema: 'source=page: XHR/fetch hook (installed on first call); source=browser: all requests incl. static assets. format=har exports HAR 1.2.' This helps understanding installation behavior and har purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors network requests and distinguishes between two sources (page vs browser) and three formats (lines, json, har). This specificity differentiates it from sibling tools like http_request or network_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains options but does not explicitly state when to use this tool over alternatives like http_request or network_rules. Usage context is implied but no exclusions or guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it activates tab in background without stealing focus, restores previous tab, and downscales to ≤1568px. Annotations already indicate read-only, idempotent, non-destructive, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short segments, front-loaded with the core purpose. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two optional params and no output schema. The description covers purpose, behavioral constraints, and side effects. It could mention the return format explicitly, but overall it is sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description does not add significant meaning beyond the schema's descriptions for tab_id and save_to; it mainly provides context about the output (PNG) and constraints (downscaling) which are not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool captures a screenshot of the visible viewport as a PNG at the current scroll position. It distinguishes itself from sibling tools like element_screenshot and full_page_screenshot by explicitly stating 'viewport only' and 'current scroll position'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (viewport screenshot) and mentions behaviors like background tab activation and downscaling. It does not explicitly state when not to use or compare with alternatives, but the context of sibling tools and the specific constraints provide adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing that close discards unsaved content and cannot be undone, that reload/navigation drop injected CSS, emulations, and page hooks, and that duplicate has special restrictions (works on chrome-untrusted://, lands in source window). It also discloses that discard replaces the tab id, making saved ids stale. These are substantive behavioral traits not captured by the readOnlyHint/destructiveHint annotations, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a succinct summary of actions, and each sentence conveys unique operational details. The long sentence about duplicate is dense but contains critical, tool-specific facts. It is appropriately sized for a multi-action tool, though it could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 enum actions, multi-action behavior), the description does a good job covering destructive consequences (close), side effects (reload), edge cases (duplicate), and id-staleness (discard). However, it entirely omits the mute/unmute actions and does not explain back/forward history semantics or return values for other actions, leaving some gaps for an agent relying solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters, including enum descriptions for actions and notes on bypass_cache and tab_id. The description adds meaningful extra context not in the schema, such as bypass_cache being 'optional cache bypass,' duplicate's environment restrictions, and discard's id replacement. This elevates it above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Tab lifecycle' and enumerates specific operations (close, activate, reload, back, forward), making the general purpose clear. It distinguishes duplicate from the sibling create_tab by noting it works where create_tab is forbidden. However, it omits the mute and unmute actions that appear in the enum, and does not contrast back/forward with the navigate sibling, so the full scope is somewhat incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for duplicate as an alternative to create_tab and warns that close is irreversible and may affect a tab the user is working in. It also explains side effects of reload/navigation that should inform when to use this tool. It does not, however, offer explicit when-not-to-use guidance for back/forward versus navigate, or for activate/reload in all contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: maximized windows are restored first because they ignore bounds, and the monitor selection mechanism depends on reading a page from a window. It also explains the limitation of scriptable tabs. This complements the annotations (idempotentHint=true, destructiveHint=false) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose first, then constraints in the following sentences. No redundant words; every sentence adds information about scope, prerequisites, or edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested area object), the description covers the key behavioral aspects: scope, monitor selection, scriptable tab requirement, and maximized window handling. The schema covers parameter details. It lacks return value info, but no output schema exists and the tool likely returns nothing meaningful. Overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are documented in the schema with descriptions (100% coverage), so the description doesn't need to repeat them. It does add context that 'area' is used when no target window has a scriptable tab, which relates to the schema description. The baseline of 3 is appropriate since the description adds marginal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Tile Chrome windows over one monitor, splitting its usable area into equal parts that leave no gap.' It specifies the resource (Chrome windows) and the action (tiling over a monitor), and distinguishes from siblings by noting the extension limitation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: it only works on Chrome windows ('Only Chrome windows: an extension cannot touch other applications'), and it explains the prerequisite that at least one target window needs a scriptable tab. It also clarifies when to use the 'area' parameter indirectly. No explicit alternative tool is named, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds crucial behavioral details: overlays are injected DOM nodes, reload/navigation drops them, and they sit above the page without altering layout or styles. This enriches the agent's understanding of side effects and persistence, fully leveraging the annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loads the core purpose in the first sentence. Each subsequent sentence adds valuable behavioral context without redundancy. Minor improvement would be reordering to place usage context earlier, but overall very effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description covers the main behavior, clearing mechanism, and lack of permanence. It does not explain return values, but for a visual feedback tool, this is acceptable. Slightly more context on what happens after highlighting (e.g., can it be removed via remove=true) is already included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for all 6 parameters. The tool description does not add new parameter details beyond summarizing the overall behavior, which is appropriate. Baseline 3 is correct as the schema already provides sufficient parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool outlines every element matching a selector with a coloured overlay, using a specific verb ('outline') and resource ('elements matching a selector'). It distinguishes itself from sibling tools by focusing on visual highlighting for selector verification, not DOM modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: 'to see on a screenshot what a selector actually caught'. It also clarifies call behavior (clears previous overlays) and the effect of remove=true. However, it does not explicitly state when not to use it or compare with alternatives among siblings, slightly lowering the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond annotations: the emulation is temporary (until reset or reload), and it details the scope of userAgent override (only page JS, not HTTP header). Annotations indicate idempotentHint=true and destructiveHint=false, which are consistent. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary purpose. Every sentence adds value: first sentence defines the tool and lists overrides; second sentence clarifies a common confusion (userAgent vs header) and suggests a pairing. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema), the description covers the main functionality, scope (until reset/reload), and relevant sibling tools. It does not explicitly describe the reset parameter's effect or return values, but these are handled by the schema. Overall it provides sufficient context for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about the overall effect (e.g., 'print mode' overrides matchMedia) and relationships to other tools, but does not provide additional meaning for individual parameters beyond the schema descriptions. It adds moderate value but not significant per-parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: making the page believe it runs in a different environment, listing specific overrides (prefers-color-scheme, prefers-reduced-motion, print mode, userAgent/platform). It distinguishes from sibling tools like network_rules for user-agent headers and suggests pairing with viewport_resize for device emulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives (e.g., network_rules for modifying the User-Agent HTTP header) and suggests pairing with viewport_resize for device emulation. However, it does not explicitly mention when to use the reset parameter or when the tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description reinforces with 'Read-only' and adds details on filtering behavior and row counts, providing extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core purpose, add efficiency context, and describe key filtering behavior with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by mentioning output fields. It covers main usage patterns and performance considerations, though interaction between offset and row limits could be clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, but the description adds value by explaining the filtering logic of `where` (case-insensitive contains, 'any' key) and hints at output fields like `row_count` and `match_count` not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it reads a table as JSON with specific structure, and the scope 'Only for tabular markup' distinguishes it from generic DOM queries or page reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Only for tabular markup' and highlights efficiency benefits of server-side filtering, but does not explicitly state when not to use or name alternative tools for non-tabular data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, idempotentHint, destructiveHint; the description adds that no reload is triggered and explains when numbers are meaningful, adding 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with key behavior, and every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description hints at return types (timing, metrics, heap size); could specify format but complete enough given annotations and complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description for tab_id; the tool description does not repeat parameter info, which is acceptable as schema covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides 'Navigation timing, paint metrics, JS heap size and per-resource load times', clearly distinguishing it from sibling tools like 'web_vitals' which cover layout-shift and interaction metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises waiting for network idle before using, and contrasts with metrics that accumulate after loading, providing clear guidance on when and why to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, etc. Description adds specifics about cookie details (domain, path, expiry, flags) and confirms read-only nature. Consistent and adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and resource. No wasted words; each sentence contributes purpose and detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions cookie structure. For a simple read tool, it sufficiently covers behavior and output shape. Adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage. Description adds context for 'type' (all returns three together) and 'tab_id' default behavior, complementing the schema well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads localStorage, sessionStorage, or cookies of the current origin. It differentiates from siblings set_storage and session_fixture by mentioning write and snapshot operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use, e.g., checking for session cookies, and hints at alternatives. Lacks explicit when-not-to-use but offers good guidance overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-idempotent (idempotentHint=false) and non-destructive. Description adds that it simulates a real key sequence and focuses the element if a selector is provided. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a clear purpose: first explains the action and effect, second provides usage guidance and idempotency warning. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what the tool does, key sequence, focusing behavior, example keys, and idempotency. No output schema, so return values are not needed. Sufficient for an 8-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 8 parameters with descriptions (100% coverage). Description only adds context about focusing when a selector is used, which is already implied. Little additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a key to the focused element') and specifies the key sequence (keydown/keypress/keyup). It distinguishes from type_text for typing values and gives examples like Enter, Tab, Escape, arrows, and shortcuts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (Enter, Tab, Escape, arrows, shortcuts) and when not ('For typing a value use type_text'). Also warns about non-idempotency: 'Not idempotent: two calls send the key twice'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adding to the annotations (readOnlyHint, destructiveHint, idempotentHint), the description discloses scrolling behavior, format (PNG), and performance profile (cheapest). No contradictions between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading key information: purpose, action, and performance. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, well-annotated, single-element screenshot tool with no output schema, the description covers all essential aspects: what it does, how it behaves (scroll), and why to use it (cheapest). Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no new semantic information beyond the schema; it repeats 'scrolled into view' which is already in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it takes a screenshot of a single element, cropped to that element, and scrolled into view. It explicitly distinguishes from siblings by calling itself the cheapest image, which differentiates it from full-page or screenshot tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when to use this tool by highlighting cost/performance (cheapest) and scope (single element). It implies this is for minimal images, but does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: lifetime (until navigation/reload), idempotency (re-inject replaces), and non-destructive nature (stylesheets untouched). Annotations already indicate idempotent=true and destructive=false, but description enriches with concrete details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no redundancy. Each sentence adds essential information: purpose, behavioral details, and scope. Excellent efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of detailed parameter schema, the description covers all necessary aspects: what it does, how it behaves (lifetime, idempotency), and its non-destructive nature. No missing essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions for both parameters. The description does not add new parameter-level information beyond what's in the schema. The mention of 'same id' in the description implies an identifier not present in the parameters, which could cause confusion but does not directly affect parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inject' and the resource 'CSS rule into the page'. It distinguishes this tool from siblings like modify_dom or execute_js by focusing specifically on CSS injection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains persistence ('stays until next navigation') and idempotency ('re-injecting the same id replaces it'). It also clarifies it only affects rendered content, not the site's stylesheet. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, etc. The description adds critical behavior beyond annotations: the hook installs on first call and earlier connections are missed, plus the 500-char preview limit. This significantly aids the agent in understanding the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. No unnecessary words. Every sentence adds value: first sentence defines purpose, second explains important behavioral caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description is complete. It explains what it monitors, the preview limitation, and the hook installation nuance. No additional information about return values is needed as the tool likely provides streamed data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('clear' and 'tab_id'). The description does not add further parameter semantics beyond the schema, so baseline 3 is appropriate. The schema descriptions are clear and sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors WebSocket connections and messages with 500-character previews. It uses a specific verb ('Monitor') and resource ('WebSocket connections/messages'), and distinguishes from sibling tools like monitor_network by focusing on WebSocket traffic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a key usage guideline: 'Hook installs on first call; earlier connections are missed.' This tells the agent to call early to capture all messages. While it doesn't explicitly list when not to use or alternatives, the context of siblings and the guideline provided is sufficient for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, but the description adds critical behavior: baselines are in-memory and lost on service worker restart. This goes beyond annotations and helps the agent understand state persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, return values, and a key caveat (in-memory baselines). No redundant or filler content; every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visual regression tool with 5 parameters and no output schema, the description covers purpose, return format (changed-pixel % and diff image), and critical limitations. It is sufficiently complete for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 5 parameters with descriptions, and the description enriches them with additional context (e.g., action enum meanings, default tab_id behavior, threshold range). Schema coverage is 100%, so baseline is 3; the extra context justifies 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs visual regression: saving a named baseline and comparing later, returning changed-pixel percentage and a diff image. It distinguishes from sibling tools like 'screenshot' and 'full_page_screenshot' by specifying visual comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for visual regression testing and mentions the ephemeral nature of baselines (lost on service worker restart). However, it lacks explicit when-not-to-use guidance or direct comparisons with alternative tools, so it's clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true), the description adds the duality of read/write behavior, the allowed zoom range, and the effect of reset. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and then details additional behaviors. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers all parameter behaviors, return modes (read vs set), and the reset option. It is fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds extra context: 'No factor = read current' for the factor parameter, and '1 = 100%' clarifies its meaning. The tab_id explanation about default behavior is also included.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual purpose (get or set zoom) and specifies the zoom range (0.25–5). It distinguishes itself from siblings by being the only zoom-related tool among many unrelated ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the tool: omit factor to read current zoom, provide factor to set, and use reset to restore default. This provides clear guidance on different usage modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it read-only, idempotent, non-destructive. The description reinforces this with 'Read-only: waiting changes nothing on the page' and details the non-raising timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, but the later sentence about timeout behavior could be more structured. Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, condition types), the description covers the key behavioral aspects (timeout, read-only, non-raising). No output schema, but return value is hinted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds marginal value. It provides context for condition types, default timeouts, and the 'Allow user scripts' toggle, but does not detail all 11 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool blocks until a condition holds, listing four distinct condition types (element, function, navigation, network_idle). It clearly distinguishes from siblings by focusing on waiting behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each condition type and what happens on timeout (returns found: false). It lacks explicit when-not-to-use guidance but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: requiring pre-load instrumentation, reporting hook status instead of returning zeros if not installed, and scoping to user-perceived stability after load. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loading the key metrics in the first sentence, then covering prerequisites and scope. Every sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and comprehensive annotations, the description sufficiently covers what the tool returns, its prerequisites, and what it does not cover. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter tab_id is fully described in the schema (100% coverage), and the description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it retrieves Core Web Vitals (CLS, LCP, FCP, TTFB, long tasks, INP approximation) accumulated since document load. It distinguishes itself by noting it covers user-perceived stability and responsiveness after load, not load timings, differentiating from siblings like get_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the prerequisite that page instrumentation must be active from before load (installed via navigate()), and that it reports whether it was hooked. It clarifies the scope (post-load) and implicitly suggests other tools for load timings, but does not explicitly name alternative tools for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: save overwrites without asking, restore uses URL-overlap matching because window IDs don't survive restarts, and unrecognized windows are reported rather than guessed. This fully discloses the tool's quirks and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core actions. Every sentence provides value: overwrite behavior, recognition logic, and the version requirement—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the essential behaviors and edge cases: overwriting, window ID instability, matching strategy, and version dependency. This is sufficient for an agent to invoke the tool correctly across all actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: name is required except for list, and action descriptions like 'save snapshots every window' clarify the effect. This goes beyond the simple enum descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves, restores, lists, or deletes named window arrangements, distinguishing it from sibling tools like tile_windows or move_tab. The verb+resource structure is explicit and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the action enum and the description's narrative, but there's no explicit guidance on when to use this tool versus alternatives, nor any exclusions or alternative recommendations. The version requirement is a partial prerequisite note but not a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the new tab becomes 'the implicit target of later commands in this session' and that each call creates another tab, behaviors not captured by the annotations. This provides critical context about statefulness and side effects beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and followed by a practical usage tip. Every sentence contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully self-contained for a state-changing tool: it explains the action, the session-wide implication, and the fallback to navigate(). It does not explicitly state the return value, but the mention of 'reuse a tab_id' implies a tab identifier is returned, which is sufficient given the tool's simplicity and the comprehensive schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond the schema, merely mentioning the optional URL, which is already documented. It does not introduce new information about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Open') and resource ('new tab'), clearly distinguishing this from navigation tools. It explicitly contrasts with navigate(), stating 'reuse a tab_id or navigate() to move an existing one instead of piling up tabs.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells the agent that each call creates a new tab and recommends reusing a tab_id or using navigate() to move an existing tab, preventing tab accumulation. This addresses when to use the tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it states that save overwrites without asking, restore writes on top without clearing first, restore refuses on different origin, and name is required except for list. Annotations already indicate destructiveHint=true and idempotentHint=true, but the description clarifies the specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose and common use case. Every sentence provides essential information without redundancy. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, annotations present), the description covers key behaviors, edge cases (different origin), and default behavior for tab_id. However, it does not describe what the list action returns, which might be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The description adds further meaning: it explains that name is required except for list, and tab_id omitted means the last navigated tab. It also clarifies the action enum values (save/restore/list). Thus it enriches beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: snapshotting localStorage, sessionStorage, and cookies into a named server fixture, restoring one, or listing saved fixtures. It specifically mentions 'A logged-in state is the usual reason,' which distinguishes this from sibling tools like get_storage or set_storage that operate directly on browser storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (for saving/restoring logged-in states). It also details important behaviors like overwriting without asking for save, writing on top for restore, and refusal on different origin. However, it does not explicitly mention when not to use or provide alternatives, though the context makes it apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that clearing cookies logs the user out and cannot be undone, giving critical behavioral context for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded core functionality and a critical warning. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters with full schema coverage and no output schema, the description covers the main behavior, destructive consequences, and prerequisite (read first). Could mention error conditions or parameter interactions, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds meaning by explaining action=clear wipes all entries of that type and that reading first is advisable, which goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes, deletes, or clears localStorage, sessionStorage, or cookies. It specifies the action, storage type, and parameters like path, domain, and expiry, making it distinct from siblings like get_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises reading current values first with get_storage, providing clear context for safe usage. It does not explicitly list when not to use, but the destructive hint and warning about logout imply caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: replaces whole value, uses native setter so frameworks register changes, fires input/change events, and details key event emission for keys mode. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with core purpose, then specifics about mode behavior and usage. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 2 enums, and no output schema, the description covers key behavioral nuances (mode behavior, event firing). Missing some edge cases like priority of ref over selector (partially in schema) but adequate for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining when to use each mode (set vs keys), notes that selector is ignored if ref given, and clarifies shadow DOM piercing with '>>>'. This supplements schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Put text' and the resources 'input, textarea or contenteditable', and specifies two methods: CSS selector or ref from get_interactives. It distinguishes from sibling tools like click and hover by focusing on text input, and the mode detail adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use 'mode=keys' (for autocomplete/masked fields) vs 'mode=set' (default), including a performance trade-off. However, it does not mention alternatives like fill_form for multiple fields, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it fires a real pointer sequence, can submit/dialog/navigate, is not idempotent, and that confirm() blocks the bridge. Adds significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two packed sentences with zero wasted words; front-loaded with purpose and targeting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough coverage of parameters and behavioral traits; no output schema but that is acceptable. Minor gap: does not mention return value (if any), but not essential for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful details for count (dblclick), button (context menu), selector (ignored with ref), and wait_after (settle behavior), all beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Click an element' with two targeting methods (CSS selector or ref), distinguishing it from sibling tools like hover or press_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use wait_after and handle_dialogs, but does not explicitly state when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description complements annotations by detailing the specific overlay dismissal approach (vendor-specific plus heuristic). Annotations already mark destructiveHint false and idempotentHint true, and description reinforces idempotency, adding valuable context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack the essential information: what it does, which overlays it targets, and idempotency. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema, annotations covering safety and idempotency, and the focused purpose, the description is fully adequate. No output schema needed for this straightforward action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for tab_id. The tool description adds the non-obvious default behavior: omitted means last tab navigated or active tab, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool dismisses cookie banners/modal overlays, listing specific vendor patterns (OneTrust, Cookiebot, Usercentrics) and a generic heuristic. This sets it apart from sibling tools that interact with page elements in other ways.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions idempotency, signaling safe repeated use. Implicitly suggests use when overlays block interaction. No explicit when-not-to-use or alternatives, but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already flagging mutation (readOnly=false) and non-destructiveness, the description goes far beyond by disclosing that the tab keeps its id/history/page state, works on chrome-untrusted:// tabs, and the exact error message for invalid destinations. This is valuable behavioral context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and every sentence adds relevant detail. However, it is a single dense paragraph with somewhat anecdotal content (e.g., 'verified on a ChromeOS Terminal tab') that could be tightened without losing value. Still, it remains purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no output schema), the description thoroughly covers constraints, error conditions, and a real-world use case. The only notable omission is the return value (what the caller gets after a successful move), but this is partially mitigated by the schema's parameter detail and the clear action-oriented nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context for new_window ('tabs.move needs an existing window, this does not') and for window_type (the terminal-window look). All other params are already well-described in the schema, so this extra context pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence immediately states the action: 'Move an existing tab into another window (chrome.tabs.move).' This is a specific verb + resource that distinguishes it from tab creation or tab_action siblings. It further clarifies the non-destructive nature and the new_window option, reinforcing purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use it: 'moving into [an app or popup window] is refused'. It also provides an alternative within the tool: 'new_window' for extracting a tab, and suggests 'viewport_resize' for positioning. The ChromeOS Terminal example gives concrete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important non-obvious behavior: the rendered viewport is smaller than requested by the browser chrome height, and a maximized window on ChromeOS ignores the request. It also explains the override semantics for width/height. With annotations already declaring idempotentHint and non-destructive, the description adds valuable context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a purpose: main functionality, viewport nuance, and override semantics plus a platform caveat. Front-loaded with the action, no filler words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no output schema, the description covers the core behavior, edge cases (browser chrome, ChromeOS maximized), and parameter relationships. Combined with the fully-described schema, it provides enough context for an agent to use the tool correctly. It omits action=get details, but those are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description adds meaning by explaining the relationship between presets and overrides ('preset plus width gives a custom width at the preset height') and the viewport vs window distinction, which affects how to interpret width/height. However, it doesn't elaborate on top/left/tab_id, which rely on schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Resize the Chrome **window** to a preset ... or to explicit dimensions.' It clearly distinguishes from sibling tools like set_zoom (zoom) and window_layout/tile_windows (window arrangement) by focusing on window size. It also clarifies the window-vs-viewport distinction, which is central to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: presets are listed, width/height override preset, and it warns about the ChromeOS maximized window behavior. It mentions using execute_js to measure the exact viewport, which is a cross-reference to a sibling tool. However, it doesn't explicitly state when to prefer this over alternatives or provide exclusion criteria, so it's clear but not explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds valuable behavioral info: cost warning ('expensive on large pages') and practical advice about token usage for HTML, which annotations do not cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly long but highly informative and well-structured: first sentence states purpose, then emphasizes read-only, recommends a mode, and warns about cost with alternatives. Front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple output modes, cost implications, alternatives), the description covers all essential aspects: what it does, when to use each mode, what to avoid, and how to use parameters like save_to. No output schema exists, but the description implies return of content or path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds semantic value by explaining the trade-offs between modes (e.g., markdown being cheaper than HTML) and suggesting default usage, going beyond mere enum listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the page as text (default), markdown, raw HTML, or accessibility tree' with a specific verb and resource. It distinguishes from siblings by explicitly naming alternatives like extract_table, extract, and get_interactives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: recommends markdown as the 'right middle ground', warns against using HTML on large pages, and directs users to other tools for tabular or repeated content and interactive elements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes expensive token cost, segment limit, scrolling process, and Chrome quota for delay, adding context beyond read-only and idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with main action, then details; every sentence adds value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a complex tool: explains return behavior, cost, pagination, and when to avoid use, despite no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions, but description adds meaningful context like Chrome quota for delay and cost implications for max_segments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly defines as full-page capture via scrolling with stitching, distinguishing from single-viewport screenshot and cheaper text-reading tools like read_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring read_page, extract, or find_text unless layout is needed, and explains cost and segment retrieval behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces with 'Read-only' and adds behavioral detail about listing every open tab and the include_windows effect on window attributes. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the core function and then expand on usage and the optional parameter. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema), the description provides all necessary return fields, usage guidance, and safety context, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema covers include_windows at 100%, the description adds meaning by explaining why you'd set it (before moving/tiling, to identify monitor) and what it returns (position, size, state, type), going beyond the schema's 'bounds, state, type and tab count'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'every open tab' and enumerates the exact fields returned (id, url, title, active flag). This distinguishes it from sibling tools like get_frames or get_page_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use it to find a tab_id when the implicit target (last navigated tab, else the active one) is not the tab you mean.' Also guides the include_windows option for moving/tiling and determining monitor placement, giving practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/frsorrentino/chrome-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server