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

No annotations are present, so the description must fully disclose behavior. It does not mention performance implications, the structure of the returned tree, or the effect of the 'interesting_only' parameter. The description is too minimal.

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

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

While the description is short, it lacks necessary details. Conciseness is not achieved at the expense of completeness; here, important information about parameters and behavior is missing.

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

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

Given the tool has one parameter and no explanation in the description, the contextual completeness is poor. The agent would not understand what 'interesting_only' means or how the return value is structured, despite an output schema being available.

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 description does not mention the single parameter 'interesting_only'. With 0% schema description coverage, the description should clarify what 'interesting' means, but it adds no value beyond the parameter name.

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

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

The description clearly states it returns the ARIA accessibility tree of the current page, which is a specific and distinct function from sibling tools like 'browser_snapshot' or 'describe_page'. It uses a specific verb and resource.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'browser_snapshot' or 'extract_structured'. The description does not specify context 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. It specifies the verification criteria, the alternative identification methods, and the return type. However, it does not disclose potential side effects or details about waiting/polling behavior beyond the timeout parameter.

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

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

The description is extremely concise, consisting of three short lines. It front-loads the purpose with an emoji and provides all key information without any unnecessary words.

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

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

Given the tool has 3 parameters and a mentioned return type (ok(rect) or err(timeout)), the description is fairly complete. It covers identification methods, visibility criteria, and the timeout parameter. Some implicit context (e.g., works on current page) is assumed but not critical.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that selector and text are alternative identifiers and that text uses fuzzy contains match, adding meaning beyond the schema. The timeout parameter is mentioned with its default, though the default is already in the schema.

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

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

The description clearly states the tool verifies element visibility with specific criteria (rendered, non-zero size, not hidden). It also explains two identification methods (selector or text with fuzzy match), which distinguishes it from siblings like 'check' or 'inspect_element'.

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

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

The description does not explicitly state when to use this tool versus alternatives like 'assert_text_present' or 'assert_url_matches'. The usage is implied through the return type (ok(rect) or err(timeout)), but no direct guidance is provided.

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

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

With no annotations provided, the description must fully disclose behavior. It mentions the return types and timeout, but does not specify whether hidden text is considered, case sensitivity, or if it works across iframes—typical 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?

Two concise sentences with a prominent emoji star and front-loaded verb. Every word is functional, zero verbosity.

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

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

The tool is simple, but missing details on text matching behavior (e.g., exact match vs substring) and whether timeout is in seconds or milliseconds. An output schema exists but description doesn't reference it.

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

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

Schema description coverage is 0%, so the description must add meaning. It mentions 'text' and 'timeout' implicitly but provides no details on matching rules (exact, substring, case) or timeout unit/behavior.

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

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

The description uses a clear verb ('Verify'), a specific resource ('text appears anywhere on page'), and a condition ('within timeout'), distinguishing it from sibling assertions like assert_element_visible and assert_url_matches.

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 the return format ('ok(found) or err(not found + sample of body text)'), implying when to use it for text presence checks. However, it does not explicitly mention when not to use it or alternative tools.

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

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

With no annotations, the description carries full burden and discloses the timeout behavior and return format (ok/err with last URL). It could detail polling behavior but is sufficient.

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

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

Two short sentences with no fluff: first states purpose, second states return values. Every sentence earns its place.

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

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

Basic completeness with output schema existing and return values mentioned, but missing parameter descriptions and usage guidance for a tool with siblings like wait_for_url.

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 0%, and the description adds no parameter explanations (e.g., pattern is a regex, timeout is seconds). This leaves agents to infer from names alone.

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

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

The description clearly states the verb 'Verify', the resource 'current URL', and the condition 'matches regex' with a timeout, distinguishing it from siblings like get_url (just returns URL) and wait_for_url (waits for URL to become something).

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

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

The description implies usage for verifying URL after navigation but does not explicitly state when to use this tool over alternatives like wait_for_url or give exclusion criteria.

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

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

No annotations present, so description carries full burden. Discloses key behaviors: auto-detects port, requires Chrome to be started with --remote-debugging-port, warns that browser_close after attach closes Chrome. Minor omission: error handling if Chrome not found.

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

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

Well-structured with emoji, clear sections, and front-loaded purpose. No unnecessary words; every sentence adds value.

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

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

Adequately covers the tool's complexity with three parameters and an output schema (not shown but exists). Could add brief description of instance_id parameter for full completeness.

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

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

Schema coverage is 0%, so description must add meaning. Explains port (auto-detects, defaults to lowest) and host (remote connections). However, instance_id parameter is not described beyond its default 'attached', leaving ambiguity about its purpose.

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 attaches to an existing Chrome instance via CDP, distinguishing it from siblings like browser_launch (which launches new browser) and detach. It specifies the exact resource (Chrome instance) and action (attach).

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

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

Provides explicit use cases: controlling existing Chrome, manually launched Chrome, remote/Docker Chrome. Also tells when not to use browser_close (use detach instead). References sibling tool detach() as alternative.

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, the description thoroughly discloses behavior: intercepts requests, stops after count matches, has timeout, optionally includes response headers, and returns a JSON array.

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?

Well-structured with brief intro, pattern note, argument list, and return format. A star emoji adds minimal verbosity but doesn't detract.

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 and no annotations, the description covers all necessary aspects: use case, pattern details, parameters, and return format, making it fully informative.

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

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

Schema coverage is 0%, so description compensates by explaining each parameter's purpose and defaults, adding value beyond raw schema.

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

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

The description clearly states the tool intercepts requests matching a URL pattern to capture headers, and explicitly distinguishes from sibling tool network_get for regex matching.

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

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

It provides explicit context for when to use (SPAs with bearer tokens in JS memory) and when not to (use network_get for regex), plus pattern matching details.

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. It states the actions are executed sequentially, but lacks details on error handling, atomicity, or what happens on failure. The return value is not mentioned.

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 plus an example, front-loaded with the core purpose. Every element is relevant and non-redundant.

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

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

Given the tool's complexity (batch execution) and the presence of an output schema (not shown), the description does not explain return values or execution results. It covers the basics but lacks depth for a batch operation.

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

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

Schema coverage is 0%, so the description must compensate. It provides structure and an example, adding meaning beyond the raw schema. However, it does not document all possible parameters for each action type, leaving gaps.

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 'Execute a list of actions sequentially' with an example showing structure. It distinguishes from sibling tools like click, fill, etc., which are individual actions.

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

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

The description implies usage for running multiple actions in order, but does not explicitly state when not to use it or provide alternative tools for single actions. The context of sibling tools makes it clear enough.

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

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

With no annotations, the description carries the full burden. It discloses closing the browser and freeing the profile lock, but does not mention side effects like unsaved data loss or whether the tool is idempotent.

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

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

The description is a single sentence with no wasted words. It conveys the essential action and outcome efficiently.

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

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

For a tool with no parameters and an output schema (implied), the description adequately covers the action and consequence. It lacks usage guidance but is complete for the basic operation.

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

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

There are zero parameters and schema coverage is 100%. The description does not need to add parameter info, so baseline 3 is appropriate. It does not provide additional parameter context.

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

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

The description uses a specific verb ('Close') and resource ('browser'), and adds a unique detail ('free the profile lock'). It clearly differentiates from sibling tools like browser_launch or attach_to_chrome.

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

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

No guidance is provided on when to use this tool versus alternatives (e.g., close_all_instances, detach). There is no mention of prerequisites or conditions for closing the browser.

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, the description carries the full burden of disclosing behavior. It covers stealth modifications, persistent profile default, headless detection warning, testing_mode impacts, auto_verify behavior, and user_data_dir constraints. However, it does not describe the output behavior (e.g., returns a browser instance ID) or lifecycle aspects.

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

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

The description is well-structured with a clear purpose statement followed by a detailed parameter list. It is relatively long but each sentence adds value. Minor improvement could be using bullet points for readability, but it remains efficient.

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 14 parameters, no annotations, and an output schema that is not explained, the description covers all parameters with thorough explanations, including edge cases and warnings. It provides sufficient context for an AI agent to correctly invoke the tool.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does so excellently: each parameter is described with context, warnings, and defaults (e.g., 'many sites detect headless — prefer False', 'caps at 2 attempts ~6s total'). This adds significant value beyond the schema.

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

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

The description explicitly states 'Launch stealth Chrome via nodriver. Creates persistent profile by default.' This clearly identifies the tool's action and resource, distinguishing it from siblings like attach_to_chrome (which attaches to existing instances) and spawn_browser.

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

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

No explicit guidance is given on when to use this tool versus alternatives. The description does not mention when to prefer browser_launch over sibling tools like spawn_browser or attach_to_chrome, nor does it provide exclusion criteria.

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

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

The description details all steps of recovery including killing orphan PIDs, resetting state, clearing caches, and wiping lock files. It notes that the operation 'Always succeeds — never raises.' With no annotations provided, the description fully discloses the aggressive and destructive nature of the tool.

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

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

The description is well-structured with a lead sentence and numbered steps. Every sentence serves a purpose, and it is appropriately sized for the tool's complexity.

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

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

Given no parameters and an output schema, the description fully explains the tool's behavior, prerequisites, and post-conditions. It covers all necessary contextual 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?

The tool has no parameters, so the schema does not need description. Per guidelines, baseline is 4 for zero parameters. The description correctly omits parameter details.

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

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

The description starts with a clear verb+resource: 'Force-recover from a stuck browser state.' It explicitly distinguishes itself from siblings like browser_close by stating it's an 'escape hatch when browser_close() can't run.'

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: 'Use this when normal close hangs or returns an error you can't diagnose.' It also explains the follow-up action: 'After this, browser_launch() again to start fresh.' This provides clear guidance and alternatives.

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

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

With no annotations provided, the description fully bears the burden. It discloses that refs are attached via data-mcp-ref and are valid until next navigation, explains the tradeoffs of different modes, and describes the caching behavior of diff_from_last. This provides comprehensive behavioral understanding.

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

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

The description is well-structured with clear sections for modes and diff_from_last. It is somewhat lengthy but each sentence adds value. Minor redundancy could be trimmed, but overall it is efficient.

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 presence of an output schema (though not shown), the description does not need to detail return values. It covers purpose, modes, and caching behavior adequately. However, it lacks mention of prerequisites, side effects, or what happens if called before navigation, which would improve completeness.

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

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

Schema coverage is 0%, so the description must add meaning. It thoroughly explains both parameters: the mode parameter's three options with their performance and fidelity differences, and the diff_from_last boolean's caching mechanism. This goes well beyond the schema's minimal definitions.

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 injects SNAPSHOT_JS and returns a ref-indexed list of interactive elements. It distinguishes itself from siblings like accessibility_snapshot and navigate_and_snapshot by focusing on interactive elements and performance tradeoffs.

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 each mode (full, fast, viewport) based on performance vs completeness tradeoffs, and explains the diff_from_last option. It implies usage for taking snapshots after navigation but does not explicitly mention when not to use it or list alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses the specific scope (HTTP cache only) and explicitly lists what is not affected. It lacks mention of prerequisites or error conditions, but for a simple zero-parameter tool, this is highly transparent.

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

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

The description is concise: one sentence for the core action, one for context, and one for exclusions. Every sentence adds value, no fluff. Front-loaded with the primary purpose.

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

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

Given zero parameters, no annotations, and an output schema (presumed present), the description is complete. It covers the tool's exact scope, boundaries, and relationships to sibling tools, leaving no ambiguity for agent invocation.

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

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

The tool has no parameters, so schema coverage is 100%. The baseline for 0 params is 4, and the description correctly adds no redundant info beyond the schema.

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

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

The description clearly states the tool's purpose: clearing the browser HTTP cache via CDP Network.clearBrowserCache. It explicitly distinguishes itself from siblings by noting what it does NOT affect (cookies, localStorage, IndexedDB), providing clear differentiation.

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

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

The description gives explicit guidance: use this tool for clearing only the HTTP cache; for a full wipe, use dedicated tools or browser_launch(persistent=False). This helps the agent decide when to use this tool vs alternatives.

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

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

No annotations are provided, so the description carries full burden. It only mentions idempotency but fails to disclose behavior on already-checked elements, missing elements, or side effects (e.g., events triggered). Minimal transparency.

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

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

The description is a single, efficient sentence with no fluff. However, it may be too concise, omitting necessary details for correct invocation.

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 two optional parameters and existence of sibling tools like 'click' and 'uncheck', the description lacks information on parameter usage, return values, and when to deploy this tool over alternatives.

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 0%, and the description provides no explanation of the two parameters ('ref' and 'selector'). The agent cannot infer how to target the element or what each parameter means.

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

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

The description clearly states the action ('Tick') and the target resource ('checkbox/radio'), and the idempotency qualifier distinguishes it from sibling tools like 'uncheck'. It is specific and unambiguous.

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

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

No guidance on when to use this tool versus alternatives (e.g., 'click' or 'uncheck'). The idempotency hint is present but no when-not-to-use or context for selecting between siblings.

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

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

With no annotations, the description carries full burden. It mentions 'JS fallback on failure' but omits critical details: what happens on success (navigation? page load?), whether it scrolls into view, and how 'humanize' parameter affects behavior.

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

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

The description is a single concise sentence, but could be restructured to separate targeting modes and behavioral notes.

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 undocumented parameters, no annotations, and many sibling tools, the description is insufficient. It lacks details on parameter interplay, return value (output schema exists but not hinted), and when to use fallback.

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 0%, so the description must compensate. It only mentions 'ref' and 'selector' generically, with no explanation of optionality, mutual exclusivity, or the 'humanize' parameter.

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

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

The description clearly states the action ('Click an element') and the two modes of targeting: by ref from snapshot or by CSS selector. This distinguishes it from sibling tools that click by text, role, or coordinates.

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 like click_text, click_role, or click_and_wait. It does not explain trade-offs 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. It discloses the behavioral traits: click action, waiting for various conditions, and response JSON structure. It lacks explicit mention of page state changes or destructive potential, but for a click tool the transparency is adequate.

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

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

The description is concise yet comprehensive. It front-loads the core purpose with an emoji, then uses a bullet list with clear labels for each parameter and value. Every sentence adds information without redundancy.

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

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

Given 9 parameters and no annotations, the description covers all necessary details: what the tool does, how to use each parameter, what to expect in the return value, and the behavioral nuances of each expect mode. It is fully self-contained for an agent to invoke correctly.

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

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

The input schema has 0% description coverage, but the description adds rich semantic meaning for every parameter: explains element selection methods (fuzzy match for text), enumerates all expect modes with clear definitions, and describes the expect_* targets and timeout. This fully compensates for the schema gap.

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 performs a click and then waits for a side-effect, distinguishing it from a plain click that may silently fail. It uses a specific verb-resource pair and contrasts with 'click()' to emphasize verification of outcomes.

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

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

The description explains when to use the tool (to confirm a successful action) and contrasts it with silent failure scenarios. It does not explicitly list when not to use or name alternative sibling tools, but the purpose is clear enough for an agent to differentiate.

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?

Discloses the corner parameter and offset behavior (inset pixels from corner, default 8px), which is not in the schema. However, it omits error handling behavior (e.g., if element not found) and does not mention any side effects, which would be helpful for a click action tool.

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

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

Extremely concise: two lines for purpose and explicit use cases, then two lines for parameter details. Every sentence adds value with no redundancy.

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

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

The description covers the core behavior and primary parameters, but lacks explanation for the optional 'ref' and 'selector' parameters. Given that the schema has no descriptions (0% coverage) and no annotations, the description should address all parameters to be fully complete.

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

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

The description explains the 'corner' enum and 'offset' integer (with example default). However, it does not document 'ref' and 'selector' parameters, which remain entirely unexplained despite 0% schema description coverage. Only 2 of 4 parameters are clarified.

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

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

Description clearly states 'Click at a corner of element' with specific use cases like close X buttons and delete icons. This effectively distinguishes it from sibling tools like 'click' (center click) and 'click_element_offset' (arbitrary offset).

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?

Description implies usage for corner-based interactions (dismiss buttons, delete icons) but does not explicitly state when to use this tool versus alternatives like 'click' or 'click_element_offset'. No exclusions or when-not-to-use guidance provided.

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

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

No annotations are provided, so the description bears full responsibility. It discloses the basic action sequence but omits important behaviors: error handling if image not found, wait times, scrolling needed, return value, or that humanize_move introduces random delays. The lack of these details is a significant gap.

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

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

The description is two concise sentences, front-loaded with the core action. The emoji provides quick visual context. No extraneous words; every sentence earns its place.

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

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

Given the tool's complexity (template matching + composite click), the description omits parameter details, return value (despite having an output schema), and error conditions. It is not complete enough for an agent to safely invoke without guessing.

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 0%, so the description must add meaning. It only implicitly covers 'template_path' (the image to find) but fails to explain 'threshold' (controls matching sensitivity) or 'humanize' (whether to add human-like randomness). Most parameter semantics are missing.

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

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

The description clearly states it finds an image via template matching and clicks its center. It uses specific verbs ('Find', 'click') and distinguishes itself from siblings like 'find_by_image' and 'humanize_click' by explicitly stating it combines multiple actions.

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 suggests use cases: 'visual CAPTCHAs, custom buttons without reliable selectors, or interacting with canvas-based UIs.' It does not mention when not to use or directly compare with alternatives, but the context is clear and actionable.

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

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

The description discloses core behavior (click at percentage position) and hints that it is not center. However, it does not mention scrolling, waiting, or the 'humanize' default behavior, which would be valuable given 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 concise with one sentence plus examples. It front-loads the purpose. However, it lacks parameter explanations, which would improve structure.

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

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

Given the tool has 5 parameters and no annotations, the description is incomplete. It does not explain how to target an element (ref vs selector), the humanize behavior, or the return value (output schema exists but not described).

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 description fails to explain the five parameters, especially 'ref', 'selector', and 'humanize'. The examples only illustrate x_percent and y_percent values. With 0% schema description coverage, the description should compensate but does not.

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 clicks inside an element at a percentage position, not the center. It distinguishes from sibling tools like 'click' (which likely clicks center) and provides examples that illustrate specific use cases.

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

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

The description implies when to use (clicking at a specific offset) by stating 'not center' and giving examples. It does not explicitly list alternatives or when not to use, 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.

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

The description only explains the targeting method (by ARIA role) but does not disclose behavioral traits such as waiting behavior, handling of multiple matches, or whether it works on hidden elements. With no annotations, the description carries the full burden.

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

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

The description is a single concise sentence that immediately conveys the purpose and key parameters. No extraneous words.

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

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

The description is adequate for a simple click action but lacks details on error handling (e.g., element not found) and does not leverage the existence of an output schema. Given the many sibling tools, more context on when to prefer this tool would improve completeness.

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

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

The description adds significant meaning beyond the bare schema by explaining 'role' as an ARIA role (with examples) and 'name' as an accessible name. This helps the agent understand valid inputs.

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 clicks an element identified by its ARIA role, with an optional accessible name. This distinguishes it from sibling tools like 'click' (by selector) and other click variants.

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 like 'click' or 'click_text'. It does not mention prerequisites or typical use cases.

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

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

No annotations provided. The description does not disclose behavioral traits such as whether it scrolls into view, waits for element availability, or triggers navigation. Only the basic search-and-click mechanism is implied.

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

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

A single sentence of 7 words is very concise with no fluff. However, it sacrifices some necessary detail for brevity, earning a high but not perfect score.

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

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

Given the tool has 2 parameters, no annotations, and an output schema (not shown), the description fails to cover return values, search scope, or post-click behavior. It is insufficient for an agent to use correctly without additional 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 description adds meaning to the 'text' parameter by stating matching is involved, but it does not explain the 'exact' boolean parameter (e.g., whether it controls case sensitivity or substring matching). With 0% schema description coverage, the description partially compensates.

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 'Find and click element whose text matches' clearly states the action (find and click) and the resource (element by text). It distinguishes from sibling tools like 'click' (which likely uses selectors) and 'click_role' (by role).

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

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

No guidance on when to use this tool vs alternatives like 'click', 'click_role', or 'click_and_wait'. No exclusions or context about when this is appropriate.

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 provided, so description carries full burden. It details the three-tier detection strategy, fallback behavior, and limitations comprehensively.

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?

Well-structured with numbered tiers and parameter descriptions. Slightly long but every sentence adds value. Could be slightly more concise.

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

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

Given 3 parameters with no schema descriptions and no annotations, the description is thorough: covers purpose, mechanism, usage guidance, parameter details, and limitations. Fully complete.

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

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

Schema coverage is 0%, so description must compensate. It explains each parameter's purpose, default, and calibration (e.g., offset_x calibrated for CF checkbox).

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

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

Clearly states it auto-finds and clicks the Cloudflare Turnstile checkbox. Specific verb and resource, distinguishes from sibling click tools.

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

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

Explicitly says when NOT to use (Cloudflare managed-mode interstitials) and provides alternatives (solve_captcha or storage_state_load). Also lists known working sites.

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, the description fully carries the burden of behavioral disclosure. It explains the tool is safe (reads without modification), copies to a specific directory, checks SingletonLock, and details what is preserved or skipped (with cache details). This is comprehensive.

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

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

The description is well-structured with headings (SAFE, Args, After clone) and bullet points. It is concise, every sentence adds value, and the key information is front-loaded.

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

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

Given the tool's complexity (4 parameters, 0 required) and the presence of an output schema (though not shown), the description is complete. It covers the operation, side effects, parameter details, and post-clone actions, leaving no 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 0%, but the description provides detailed explanations for all four parameters. It explains source_profile (use list_chrome_profiles), target_instance_id, skip_cache (excludes large regenerable directories), and overwrite. This adds significant meaning beyond the schema.

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

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

The description clearly states it clones an existing Chrome profile into an isolated location. It distinguishes itself from sibling tools like list_chrome_profiles and spawn_browser by explaining the cloning process and its purpose.

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 mentions prerequisites (Chrome must be closed) and how to use the cloned profile (launch with spawn_browser). It provides a tip to use list_chrome_profiles for source options. However, it does not explicitly state when not to use this tool or what alternatives exist.

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. It states the action but does not disclose consequences such as unsaved data loss or that all instances will be closed without confirmation.

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

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

The description is a single sentence with no wasted words, front-loading the core action.

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

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

For a simple no-parameter tool with an output schema, the description is largely sufficient, though it could mention lack of confirmation or irreversible effects.

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

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

There are no parameters (schema coverage 100%), and the description adds no parameter info; baseline of 4 is appropriate for zero-parameter tools.

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 'Close every running browser instance' with a specific verb and resource, and it distinguishes from siblings like close_instance (singular) and browser_close (current browser).

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

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

The description says 'Useful for cleanup' but does not explicitly state when to use versus alternatives like close_instance or browser_close, lacking explicit context for selection.

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

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

With no annotations, the description carries the full burden. It discloses that closing frees profile and memory, indicating a destructive side effect. However, it omits details about irreversibility, error conditions, or required permissions.

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

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

The description is extremely concise—one sentence plus a parenthetical note. It front-loads the core action, and every word earns its place without redundancy.

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

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

Given the tool has one parameter and an output schema (not documented), the description is too brief. It lacks information about return value, error handling, and prerequisites (e.g., instance must be open). For a simple tool, this is a significant gap.

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

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

Schema coverage for parameters is 0%, so the description must compensate. The phrase 'specific browser instance' weakly implies the parameter identifies the instance, but it adds no detail about the expected format, validation, or behavior if the ID is invalid.

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

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

The description uses a specific verb ('Close') and resource ('a specific browser instance'), making the action unmistakable. It distinguishes from siblings like 'close_all_instances' by emphasizing 'specific', implying the need for an instance identifier.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'browser_close' or 'close_all_instances'. It does not mention prerequisites (e.g., instance must exist) or exclusions.

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

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

With no annotations, the description carries the full burden. It transparently states both effects: clearing the captured buffer and calling console.clear() in the page. No contradictions or hidden side effects.

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

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

The description is a single sentence that is concise and front-loaded. Every word is necessary, no waste.

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

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

Given the tool's simplicity (no parameters, trivial input schema, and presence of output schema), the description is complete enough. It explains the action and side effects clearly.

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 no parameters, and schema coverage is 100% trivially. According to guidelines, baseline is 3 when coverage is high. The description adds no parameter info, which is fine.

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

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

The description clearly states the tool's action: clearing the captured console buffer and calling console.clear() in the page. It uses a specific verb and resource, distinguishing it from sibling tools like console_get and console_start.

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

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

The description implies the tool is used to clear the console buffer, which is clear from context. However, it lacks explicit guidance on when not to use it or alternatives, but given the tool's simplicity, this is acceptable.

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 full burden. 'Retrieve' suggests a read-only operation, but there is no explicit statement about non-destructiveness, message persistence after retrieval, or error conditions. The description does not contradict annotations (none exist), but leaves some behavioral traits implied rather than explicit.

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

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

A single sentence that is front-loaded with the verb and resource, containing no redundant information. Every word earns its place, and the structure is optimal for quick parsing.

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

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

The tool is simple with one optional parameter and an output schema (exists but not shown). The description covers the key behavioral aspect (chronological order with limit) and is complete for the tool's scope. Minor gaps like error handling or empty state behavior are not critical given the output schema likely documents return values.

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

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

Schema coverage is 0% with no parameter descriptions. The description compensates by explaining the 'limit' parameter's role in controlling how many messages are returned and the ordering (oldest first within last limit, newest last). This adds significant meaning beyond the raw 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 verb 'Retrieve' and resource 'captured console messages', specifying chronological ordering. It distinguishes from sibling tools like console_clear (delete) and console_start (start capture), making the tool's purpose unambiguous.

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

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

The description implies this tool is for reading messages, but does not explicitly provide when-to-use guidance or contrast with alternatives like console_clear or console_start. The chronological ordering detail is useful but insufficient for full usage guidelines.

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, and the description does not disclose behavioral traits like whether previous captures are overwritten, if there is a limit, or if it returns a status.

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

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

Single sentence with no wasted words, front-loading the action and resource effectively.

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

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

Given the simplicity of the tool and the presence of an output schema (not shown), the description is adequate but lacks context about how it relates to console_get and console_clear, and whether a stop action is needed.

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

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

There are no parameters, and schema coverage is 100%. The description adds no extra meaning beyond the action, but a baseline of 4 is appropriate for zero-parameter tools.

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 has a specific verb 'Begin capturing' and a clear resource 'console messages of active tab', which distinguishes it from sibling tools like console_clear and console_get.

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

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

No guidance on when to use this tool vs alternatives, such as when to start capturing vs retrieving messages with console_get, or when not to use it.

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

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

The description indicates deletion (a destructive action) but does not disclose details such as whether cookies are deleted permanently, if domain scoping affects behavior, or any side effects like session termination. No annotations provided to supplement.

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

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

Single, well-structured sentence that front-loads the action and resource. No unnecessary words.

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

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

The description covers the basic purpose and optional parameter, but lacks detail on exact behavior, return values, and edge cases (e.g., no matching cookies). An output schema exists, so return format is not needed, but more context would help.

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 description explains the optional domain scoping, adding meaning beyond the schema. However, it does not specify name matching behavior (exact, case-sensitive, wildcard) or the effect of null domain, and the schema has 0% description coverage.

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

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

The description clearly states the verb 'Delete' and the resource 'cookies' with the condition 'matching name (optionally scoped to domain)', effectively distinguishing it from sibling tools like cookie_list, cookie_set, etc.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., cache_clear for all cookies) or when not to use it. The context is implied by the tool name and siblings.

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

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

No annotations provided. Description discloses output format (JSON array), location (~/.mcp-stealth/storage-states/), and compatibility. Does not mention whether it overwrites existing files or requires any particular permissions, but the operation is likely non-destructive. Adequate but could be more detailed about side effects.

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

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

Extremely concise: two sentences. The first sentence states purpose, the second adds key details (format, location, compatibility). No unnecessary words.

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

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

The tool has an output schema (not shown) which likely covers return values. The description covers format, location, and sibling alternative. However, it omits parameter semantics and any preconditions. Simple tool but missing parameter details reduces completeness.

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

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

Schema has 2 parameters (filename, url) with 0% description coverage. The description provides no explanation of these parameters, leaving the agent to infer from names and context. This is a significant gap: the description must compensate for missing schema descriptions but fails to do so.

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 'Export' and resource 'cookies', and distinguishes from the sibling 'storage_state_save' by specifying 'Cookies-only (use storage_state_save for full session)'. It also mentions output format (JSON) and location.

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

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

Provides explicit when-to-use guidance by comparing with storage_state_save for full session. Mentions compatibility with cookie_import/EditThisCookie/Playwright, giving context. Lacks explicit when-not-to-use scenarios but is clear enough.

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

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

The description discloses key behaviors: import modes, auto-parsing of raw_text, the effect of clear_first flag, and domain fallback logic. It does not contradict annotations (none provided). However, it could add details on error handling or side effects like overwriting existing cookies.

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

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

The description is well-organized with a summary, bulleted modes, and args list. It is slightly verbose (e.g., per-cookie field example), but the structure aids readability. Could be trimmed slightly without losing clarity.

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

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

Given the tool's complexity (5 parameters, multiple input modes, auto-parsing, domain handling), the description covers all aspects thoroughly, includes examples, and references the output schema implicitly. It is complete for an agent to invoke correctly.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter in detail, providing examples (inline array, file path, raw text formats), and noting default behavior for domain and clear_first. This goes well beyond the schema's type-only definitions.

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

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

The description clearly states the tool's purpose as 'Bulk-import cookies' and enumerates three distinct input modes, making it specific and actionable. It also differentiates from a sibling tool (storage_state_load) by noting that this tool handles cookies only, not full storage.

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

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

The description provides explicit guidance on when to use each input mode, including fallback domain handling for header/netscape formats, and advises calling after navigate or providing default_domain. It also points to the alternative sibling for full storage restore, giving clear when-to and when-not-to use.

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, and the description only says 'list all cookies' without disclosing return format, scope, or any side effects. It lacks behavioral details beyond the basic function.

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

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

The description is a single concise sentence with no unnecessary words, but sacrifices detail for brevity.

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

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

Given the tool has an output schema and one optional parameter, the description is minimally adequate but does not explain return values or behavior beyond listing.

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

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

With 0% schema description coverage, the description adds minimal value by indicating the URL parameter is for filtering, but does not explain URL matching or format.

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

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

The description clearly states the tool lists cookies and optionally filters by URL, distinguishing it from sibling cookie manipulation tools like cookie_delete or cookie_set.

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

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

The description implies usage for viewing cookies but provides no explicit guidance on when to use vs alternatives 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, the description must disclose behavioral traits. It only states the basic action, omitting details like overwriting behavior, side effects, or dependencies on page state.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded but could benefit from slightly more detail without sacrificing conciseness.

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

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

Given 6 parameters, an output schema exists, and no annotations, the description is too sparse. It lacks essential context for correct invocation and understanding of behavior.

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

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

Schema description coverage is 0%, and the description adds no meaning to the 6 parameters (name, value, domain, path, secure, http_only). It fails to compensate for the lack of parameter documentation.

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

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

The description 'Set a cookie on the browser' clearly states the action (set) and resource (cookie), distinguishing it from sibling tools like cookie_delete, cookie_list, etc.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description is silent on usage context.

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

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

With no annotations, the description bears the burden of behavioral disclosure. It mentions wrapping CDP methods but does not state whether re-invocation restarts tracking, if it is safe to call multiple times, or what side effects occur (e.g., clearing previous data). The behavioral context is minimal.

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

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

The description is two concise sentences, front-loaded with the primary purpose, followed by implementation detail and usage guidance. Every word adds value, and there is no redundancy.

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

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

Given the tool's simplicity (2 booleans, no required params, output schema exists), the description covers the essential workflow. It could mention behavior on repeated calls or whether prior coverage data is discarded, but overall it is sufficient for an agent to use 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 0%, but the two Boolean parameters (js, css) are self-explanatory from the tool name and description. The description adds no further detail about their meaning beyond indicating that they enable collection for respective types. Baseline score of 3 is appropriate given simplicity and context.

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

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

The description clearly states the action ('Start collecting') and the resource ('JS/CSS code coverage'). It also references underlying CDP methods, distinguishing it from sibling 'coverage_stop'. The tool's purpose is unambiguous.

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

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

The description explicitly tells the user to call 'coverage_stop()' to retrieve the report, providing a clear usage pattern. While it doesn't exclude other uses, this is sufficient guidance for the paired workflow.

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, the description must fully explain behavior. It describes the action and return value but lacks details on side effects (e.g., whether coverage data is reset, if the tool can be called multiple times, or if it requires prior state). The description is functional but not comprehensive.

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

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

Two sentences with front-loaded action and result. Every sentence adds value: first states the purpose, second details output format and sorting. No fluff 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 no parameters and presence of an output schema, the description provides key output details (per-file summary, sorting). However, it omits prerequisite context (e.g., coverage must be started first) and any state implications. Could be slightly more complete.

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

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

Input schema has zero parameters, so baseline is 4. The description adds no parameter information, which is appropriate since there are none. Schema coverage is 100%, so the description does not need to compensate.

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 stops coverage collection and returns a used/unused breakdown. It specifies the output format (per-file summary with bytes used, total, and unused percentage) and sorting order (by largest unused byte count). This distinguishes it from sibling tools like coverage_start.

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

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

No guidance on when to use this tool vs. alternatives. It does not mention that coverage must be started first (via coverage_start) or any prerequisites. Sibling tools include many other actions, but the description offers no context for appropriate usage.

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?

Despite no annotations, the description explains the wait_stable behavior with MutationObserver, default values, and output shape, but omits details about error handling or performance implications.

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

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

The description is well-structured with separate sections for args and output shape, front-loaded with purpose, and every sentence adds value.

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

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

Given the tool's complexity (3 parameters, one conditional behavior), the description covers parameter details, output format, and usage context (before smart_fill), making it fully complete.

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

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

With 0% schema description coverage, the description fully explains all three parameters, including their purpose, defaults, and behavioral effects.

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 produces a compact AI-friendly page summary, replacing accessibility_snapshot for LLM workflows, and distinguishes itself by being more token-efficient.

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

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

Explicitly says 'Use this BEFORE smart_fill so the LLM knows which labels exist' and mentions it replaces accessibility_snapshot, but does not provide alternative tools for other use cases.

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

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

With no annotations, the description fully discloses behavior: does not close Chrome, is a no-op for spawned browsers, and Chrome continues running. Also specifies that re-attachment 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?

Two clear sentences front-loading the core action and side effects. Every word adds value without repetition.

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

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

Given no parameters and output schema present, the description covers the tool's domain, prerequisites, and alternatives completely.

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

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

No parameters, so baseline is 4. The description adds no param info, but none is needed.

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

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

The description uses specific verb 'Release' and unique resource 'CDP connection to an attached Chrome'. It distinguishes from siblings like attach_to_chrome and browser_close.

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

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

Explicitly states when to use (only for attach_to_chrome connections) and when not to (for spawned browsers, use browser_close). Also mentions re-attach possibility.

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 that some walls receive automatic bypass while others only return recommendations, and notes requirements for session reuse/proxies/paid solvers. However, it lacks details on prerequisites (e.g., attached browser, loaded page), potential side effects, or failure modes.

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

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

The description is concise and front-loaded with the key action ('One-shot: detect anti-bot wall...'). The bullet list for bypass routing is well-structured and adds clarity without unnecessary words. Very minor redundancy (e.g., 'No wall detected → returns ok with empty bypass' could be inferred from 'detection + bypass result').

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 (multiple wall types, different bypass strategies) and the existence of an output schema, the description adequately covers the core behavior. However, it omits important context such as expected page state (e.g., must be navigated to a page with a wall), error handling, and whether the tool is idempotent.

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

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

The tool has zero parameters, so the schema provides complete coverage. The description adds no parameter information, which is acceptable since none are needed. Per guidelines, baseline score is 4 for zero-parameter tools.

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

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

The description clearly states that the tool detects anti-bot walls and applies the best bypass in one shot. It specifies supported walls (Cloudflare Turnstile, DataDome, etc.) and how bypass differs, distinguishing it from sibling tools like 'detect_anti_bot' (likely detection only) and 'verify_cf' (focused solely on Cloudflare).

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

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

The description explains when to use the tool (on a page with an anti-bot wall) and provides routing details for different wall types. It implicitly covers when not to use (no wall returns ok) but does not explicitly mention alternative sibling tools or when to prefer them over this one-shot approach.

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. It states that the tool analyzes the current page and headers, which suggests a non-destructive read operation. However, it does not explicitly confirm no side effects, state changes, or prerequisites, leaving some ambiguity.

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: three sentences, front-loaded with an emoji and clear action. It uses a bullet-like list for detected systems, and every sentence adds value without redundancy.

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

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

Given no parameters and the existence of an output schema, the description covers the tool's purpose and return value (system + recommended bypass strategy) adequately. It provides sufficient context for an agent to understand what the tool does and what it returns.

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 no parameters, and the schema is empty (100% coverage). According to guidelines, with 0 parameters the baseline is 4. No additional parameter info is needed, and the description does not add any, which is appropriate.

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

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

The description clearly states the tool's purpose: analyze current page and HTTP headers to identify anti-bot systems. It lists specific systems (Cloudflare, DataDome, etc.) and mentions returning the identified system plus a recommended bypass strategy. This distinguishes it from sibling tools like detect_and_bypass, which likely also executes bypass.

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 when needing to identify which anti-bot system is present on a page, and mentions a recommended bypass strategy. While it does not explicitly state when not to use or compare to siblings, the context of sibling tools (e.g., detect_and_bypass) makes the use case clear.

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

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

The description discloses that the tool uses heuristics, returns top-3 candidate selectors ranked by child-similarity, and is intended for scraping. However, it does not explicitly state that it is read-only or describe any side effects. Since no annotations are provided, the description carries the full burden, and it partially achieves transparency.

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

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

The description is extremely concise: three sentences covering purpose, use cases, and output format. Every sentence adds value, and the key information is front-loaded in the first sentence.

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

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

Given the tool has no parameters and an output schema exists (though not shown), the description is largely complete. It explains the detection approach, typical uses, and what is returned. It could mention limitations or assumptions (e.g., page must have repeating elements), but the provided information suffices for understanding.

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 no parameters, so the input schema is empty. According to guidelines, 0 parameters yields a baseline score of 4. The description does not need to add parameter semantics as there are none.

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

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

The description clearly states the tool's function: 'Heuristically detect the most likely repeating container on page.' It specifies the resource (page) and the output (CSS selectors). The use cases listed (job listings, product cards, search results) further clarify its purpose. It distinguishes from sibling tools like extract_structured by focusing on detecting repeating containers rather than extracting data.

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

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

The description provides context for when to use it ('Useful for scraping...'), but does not explicitly state when not to use it or mention alternatives among siblings. This implicit guidance is adequate but lacks explicit exclusion criteria.

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

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

No annotations, so description carries full burden. Describes persistence across dialogs, config read at fire time, update without re-arming, and limitation to native dialogs. Missing potential side effects, but behavior is well detailed.

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

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

Front-loaded with key info, uses bullet points and examples. Slightly long but each sentence adds value. Could be trimmed, but structure is clear.

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 4 params, description covers usage patterns, limitations (native only), and parameter details. Output schema exists but not needed per rules. Provides enough for agent to use correctly.

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

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

Schema coverage is 0% so description must explain all 4 params. It does: action (accept/dismiss), enabled (arm/disable), types (scoping list, default all), text (prompt response or basic auth). Adds meaning beyond schema defaults.

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

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

The description clearly states it installs a persistent auto-handler for native browser dialogs, using specific verb 'install' and resource 'auto-handler'. It distinguishes from sibling dialog_handle (one-shot vs persistent).

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

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

Explicitly contrasts with dialog_handle for one-shot use, provides contextual patterns (form unsaved changes, alert spam) and when to disable via enabled=False. Lists alternatives for HTML overlays.

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 full burden. It explains the tool is a pre-arm handler, implying it prepares for a dialog, but does not disclose behaviors like what happens if multiple calls are made, if no dialog appears, or if the action parameter is invalid. The description is adequate but lacks depth.

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

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

The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and usage. Every word earns its place with no redundancy.

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

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

The tool is simple and has an output schema, so return values need not be explained. However, the description omits details about parameter semantics (action values, text usage), which are necessary for correct invocation. It is not fully complete given the lack of parameter documentation.

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 0%. The description does not explain the meaning or valid values for the 'action' parameter (e.g., accept, dismiss) or the 'text' parameter (for prompt dialogs). It adds minimal value beyond what the schema provides, leaving ambiguity for the agent.

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