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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits such as the requirement for Chrome to be running with specific flags and the use of CDP, but it lacks details on error handling, connection persistence, or what happens after connection (e.g., does it return a session ID?). This is adequate but has gaps for a tool with no annotations.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential prerequisites and a concrete example. Every sentence earns its place by providing critical information without redundancy, making it highly efficient and well-structured.

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

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

Given the tool's complexity (connecting to a browser via CDP), no annotations, and no output schema, the description does a good job covering prerequisites and usage. However, it lacks details on what the tool returns (e.g., connection status or session handle) and potential failure modes, which would enhance completeness for a tool with no structured output information.

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

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

Schema description coverage is 100%, so the schema already fully documents the single parameter 'debugUrl' with its type, format, default, and description. The description does not add any meaningful parameter semantics beyond what the schema provides, such as explaining why the default is used or edge cases for the URL. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Connect to a running Chrome browser') and the mechanism ('via the Chrome DevTools Protocol'), distinguishing it from siblings like browser_disconnect or browser_navigate. It provides a precise verb+resource combination that leaves no ambiguity about what the tool does.

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

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

The description explicitly states when to use this tool by specifying the prerequisite condition ('Chrome must be started with --remote-debugging-port=9222') and provides a concrete command example. However, it does not explicitly contrast when to use this versus alternatives like browser_disconnect or other browser-related tools, which prevents a perfect score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's effect ('Close the CDP connection', 'release the connection') and explicitly states what it does NOT do ('Does NOT kill the Chrome process'), which is crucial behavioral context. However, it doesn't mention potential side effects like whether other tools become unusable after disconnection or if reconnection is possible.

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

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

The description is perfectly concise with three sentences that each earn their place: the first states the core action, the second clarifies what it doesn't do (preventing a common misconception), and the third provides clear usage timing. It's front-loaded with the main purpose and wastes no words while covering all essential information.

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

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It explains what the tool does, what it doesn't do, and when to use it. The only minor gap is not explicitly stating that other browser tools may become unusable after disconnection, but this is somewhat implied by the 'release the connection' language and the sibling tool context.

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

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context. No parameter information is needed or expected given the empty input schema.

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

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

The description clearly states the specific action ('Close the CDP connection to Chrome') and resource ('Chrome'), distinguishing it from siblings like browser_connect (which establishes connection) and browser_navigate (which navigates within an active connection). It explicitly clarifies what it does NOT do ('Does NOT kill the Chrome process'), preventing confusion with potential destructive alternatives.

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

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

The description provides explicit guidance on when to use this tool ('Call this when you are done to release the connection'), establishing a clear lifecycle context. It also specifies when NOT to use it ('Does NOT kill the Chrome process'), preventing misuse for process termination. The context implies this should be called after using other browser tools to clean up resources.

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

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

With no annotations provided, the description carries full burden. It discloses the return values (page title and HTTP status code) and implies navigation completion, which is useful. However, it lacks details on error handling (e.g., timeouts, invalid URLs), side effects (e.g., page reload, history changes), or performance considerations, leaving behavioral gaps.

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

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

The description is two sentences with zero waste: the first states the action and resource, the second specifies return values. It's front-loaded with the core purpose and efficiently structured, making every sentence earn its place.

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

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

Given no annotations and no output schema, the description partially compensates by stating return values. However, for a navigation tool with 3 parameters and potential side effects, it lacks details on prerequisites, error scenarios, and behavioral nuances, making it minimally adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the schema fully documents all parameters (url, waitUntil, timeout). The description adds no parameter-specific information beyond what the schema provides, such as explaining waitUntil options or timeout implications. Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the specific action ('Navigate') and resource ('connected browser to a URL'), distinguishing it from siblings like browser_connect/disconnect (connection management) or get_element_properties (element inspection). It precisely communicates the core function without ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., browser must be connected via browser_connect), exclusions (e.g., not for interacting with page elements), or comparisons to sibling tools like get_interactive_elements for post-navigation actions.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it returns a hierarchical tree structure, mentions performance implications ('slower but more accurate' for useFullTree), and describes the effect of parameters on output. It doesn't cover error conditions or permissions, but provides substantial operational context.

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

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

The description is efficiently structured with three focused sentences: first states the core purpose, second describes the return format, and third provides parameter usage tips. Every sentence adds value with zero waste, and it's front-loaded with the main action.

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

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

Given 3 parameters with full schema coverage and no output schema, the description provides good context about what the tool returns and how parameters affect behavior. It could be more complete by mentioning typical use cases or limitations, but covers the essential operational aspects adequately for this complexity level.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal value by restating parameter purposes in a more conversational tone (e.g., 'Use interestingOnly=false for the complete raw tree'), but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the specific action ('Capture a snapshot') and resource ('current page's accessibility tree'), and distinguishes it from sibling 'query_accessibility_tree' by focusing on snapshot capture rather than querying. It explicitly mentions the hierarchical structure and key attributes returned.

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

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

The description provides clear context on when to use specific parameter settings (e.g., 'use interestingOnly=false for the complete raw tree'), but does not explicitly state when to choose this tool over alternatives like 'query_accessibility_tree' or other sibling tools. It offers practical guidance without naming exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses the return content (accessibility properties and test selectors) and selector prioritization behavior, which is valuable. However, it doesn't mention potential errors (e.g., if selector finds no element), performance characteristics, or authentication needs, leaving gaps for a tool with no annotation coverage.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose, output, and key behavioral detail (selector prioritization). Every part earns its place with no wasted words, making it easy to parse and front-loaded with essential information.

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

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

Given no annotations and no output schema, the description provides good coverage of what the tool returns and its selector behavior. However, for a tool that interacts with a browser (implied by sibling tools), it lacks context on dependencies (e.g., requires an active browser session), error handling, or output format details, which could hinder an agent's ability to use it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain selector syntax further or clarify 'includeHtml' implications). Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('returns') and the exact resources ('element's full accessibility properties and multi-framework test selectors'), naming four specific frameworks. It distinguishes from siblings like 'get_accessibility_tree' by focusing on a single element's properties rather than the entire tree.

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

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

The description implies usage by specifying 'Given a CSS selector' and mentions selector prioritization, which provides some context. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_focused_element' or 'get_interactive_elements', and doesn't state any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool returns but doesn't describe behavioral traits such as whether it requires a browser connection (implied by sibling tools), potential errors if no element is focused, performance characteristics, or output format details. The description adds minimal context beyond the basic purpose.

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

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

The description is concise and well-structured with two sentences. The first sentence states the core functionality, and the second provides usage context. Every sentence earns its place without redundancy or unnecessary details.

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

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

Given the tool's moderate complexity (retrieving focused element data) and lack of annotations or output schema, the description is adequate but has gaps. It explains the purpose and usage context but doesn't cover behavioral aspects like dependencies on browser state or output structure. For a tool with no structured metadata, more completeness would be beneficial.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here. A baseline of 4 is applied for tools with no parameters, as there's nothing to compensate for.

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

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

The description clearly states the tool's purpose: 'Returns the currently keyboard-focused element's accessibility info and suggested selectors.' It specifies the verb ('returns'), resource ('currently keyboard-focused element'), and output type ('accessibility info and suggested selectors'). However, it doesn't explicitly differentiate from sibling tools like 'get_element_properties' or 'get_accessibility_tree', which also retrieve accessibility-related information.

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

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

The description provides implied usage guidance: 'Useful for checking focus management in accessible UIs.' This suggests a context (accessibility testing) but doesn't explicitly state when to use this tool versus alternatives like 'get_interactive_elements' or 'query_accessibility_tree'. No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (finds interactive elements and returns accessibility info with test selectors), covers 20 ARIA roles, and mentions filtering capability. However, it doesn't disclose performance characteristics, rate limits, or error handling, which would be helpful for a tool that might return up to 100 elements.

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

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

The description is two sentences that are front-loaded with the core purpose and efficiently convey key details (coverage of 20 roles, filtering capability). Every sentence earns its place with no wasted words or redundancy.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is fairly complete. It explains what the tool does, what it returns, and how to filter results. However, without an output schema, it could benefit from more detail on the return format (e.g., structure of accessibility info and test selectors) to fully guide the agent.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds value by mentioning 'Use roles[] to filter to specific roles', which clarifies the purpose of the roles parameter beyond the schema's list of default roles. However, it doesn't provide additional context for includeDisabled or maxElements beyond what the schema states.

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

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

The description clearly states the verb 'find' and resource 'interactive elements on the page', specifying the types (buttons, inputs, links, etc.) and what information is returned (accessibility info plus multi-framework test selectors). It distinguishes from sibling tools like get_accessibility_tree by focusing specifically on interactive elements rather than the full accessibility tree.

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

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

The description implies usage by mentioning 'Covers 20 interactive ARIA roles' and 'Use roles[] to filter to specific roles', which suggests when to use this tool for interactive element analysis. However, it doesn't explicitly state when to choose this over alternatives like get_accessibility_tree or query_accessibility_tree, nor does it provide exclusion criteria or prerequisites.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It describes what the tool does (search by criteria, return matching nodes with properties) and includes useful behavioral details like case-insensitive matching and partial name matching. However, it doesn't mention important aspects like whether all parameters are optional, search scope limitations, performance characteristics, or what specific properties are returned.

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

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

The description is perfectly concise - two sentences that each earn their place. The first sentence states the core functionality, the second provides a concrete example that reinforces understanding. No wasted words, well-structured, and front-loaded with the essential information.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains the search purpose well but doesn't describe the return format (what 'properties' includes), doesn't mention that all parameters are optional (though schema shows this), and doesn't provide context about search scope or limitations. For a search tool with no output schema, more detail about return values would be helpful.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions the same two parameters (role and accessibleName) in the example but doesn't explain the backendNodeId parameter or provide additional semantic context. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the tool's purpose with specific verbs ('Search', 'Returns') and resources ('accessibility tree', 'matching nodes with their properties'). It distinguishes from siblings like 'get_accessibility_tree' (which presumably retrieves the entire tree) by emphasizing search/filtering capabilities. The example further clarifies the specific use case.

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

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

The description provides clear context for when to use this tool: to search/filter the accessibility tree by ARIA role and/or accessible name. It doesn't explicitly state when NOT to use it or name specific alternatives, but the context implies it's for filtered searches rather than retrieving the full tree (which 'get_accessibility_tree' likely does). No misleading guidance is present.

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