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

No annotations are provided, so the description carries full burden. It discloses the tool's actions (sending methods, analyzing responses, CORS analysis) and error behavior ('Request failed' on unreachable URLs). Safety implications (non-destructive) are implied but not explicitly stated.

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 sections (purpose, details, output, params, errors, example) and includes both English and Chinese, which may be redundant but not detrimental. It is somewhat verbose but every section adds value.

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

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

With 5 parameters, no output schema, and a complex return object, the description fully explains the output structure (results array, corsAnalysis object), error cases, and provides a concrete example. It is complete for an agent to understand invocation and expected results.

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

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

Schema coverage is 100%, but the description adds meaningful context: default for methods, example header format, body usage notes, and checkCors default. This goes beyond the schema's brief descriptions.

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

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

The description clearly identifies the tool as an API endpoint prober that sends multiple HTTP methods and analyzes response status, content-type, and CORS configuration. It distinguishes itself from sibling tools (e.g., security_scan, security_headers_check) by focusing on method probing and CORS verification.

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

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

The description provides explicit usage contexts: API security testing, CORS configuration validation, endpoint discovery/enumeration, and OPTIONS preflight behavior verification. However, it does not discuss when not to use the tool or compare it to alternatives among 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 are provided, so the description carries full burden. It mentions the prerequisite browser_open but does not disclose error behavior, state side effects, or performance implications. The description does not confirm whether the tool is read-only or destructive.

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 short and front-loaded with version info and mode explanation. It efficiently communicates key 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?

With 9 parameters and no output schema or annotations, the description lacks coverage of return values, error handling, and overall behavior. It is incomplete for a tool of this complexity.

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

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

Schema coverage is 100%, and the description adds marginal context for the mode parameter by listing the three modes. However, it does not significantly enhance understanding beyond what the schema already provides.

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

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

The description clearly states the tool is a merged version of three asset discovery tools and explains each mode (routes, enum, probe) with specific verbs and resources. It distinguishes itself from siblings by being a consolidated tool.

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

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

The description explicitly requires prior browser_open and differentiates the three modes with usage scenarios. However, it does not explicitly mention when not to use or acknowledge that sibling tools like asset_routes_discover may now be redundant.

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. States passive analysis, no unauthorized access, and lists data sources. Lacks detail on output format but adequately describes 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?

Single focused paragraph with key information upfront. Slightly dense but no wasted content; could benefit from structured list of sources.

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

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

Covers main purpose, data sources, passive nature, and prerequisite. No output schema, but agent can infer likelihood. Lacks constraints on environment or timeout behavior.

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

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

Schema coverage is 100% with parameter description in schema. Tool description does not add new meaning beyond schema's explanation of parameter 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?

Specifies verb 'discover' and resource 'front-end routes' with explicit sources (DOM links, hash routes, inline scripts, JS bundles, network logs), differentiating from active probing tools. 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?

States prerequisite 'need to browser_open the page first' and constraint 'passive analysis only, no active probing'. Does not explicitly compare to sibling tools but context of options implies when 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, so the description carries full burden. It describes the tool as running checks, returning a violations summary, and mentions errors (browser not launched, selector not found). It also gives output structure, which is helpful transparency.

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

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

The description is well-structured with English summary followed by Chinese details, front-loaded with key purpose. Though slightly long, 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 4 parameters, no output schema, and no annotations, the description is very complete: purpose, use cases, parameters, output format, errors, and example. No output schema is needed because return values are 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?

Schema coverage is 100%, and the description restates each parameter (selector, excludeSelectors, tags, sessionName) with purpose and optionality. It also adds example usage and error handling, providing clear 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 runs an axe-core accessibility check on the current page, with scan-scope restriction, exclude regions, and rule-tag filtering. This distinguishes it from sibling tools like browser_visual_check (visual regression) and browser_lighthouse_audit (performance/SEO) by specifically focusing on a11y violations.

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 Chinese section explicitly lists when to use: pre-release WCAG compliance, automated regression, debugging missing aria-labels, local component scanning. It does not explicitly mention when not to use, but the specific use cases provide clear guidance.

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

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

Discloses that it automatically clears existing content before input. With no annotations, this adds important behavioral context. Could mention event triggering but still good.

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?

Four concise sentences: purpose, workflow, auto-clear, advantage. No redundancy, 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?

Covers purpose, workflow, behavior, and stability advantage. Lacks error handling details but sufficient for low-complexity tool.

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

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

Schema covers both params. Description adds value by explaining ref originates from aria snapshot and that text is input after clearing. Beyond schema.

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

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

The description clearly states it locates an element via a stable ref from the accessibility tree and inputs text. It specifies the verb '输入文本' and resource '元素', and distinguishes from CSS-based siblings by emphasizing stability.

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

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

Explicitly mentions pairing with browser_aria_snapshot and workflow steps. Provides context for when to use (unstable CSS) but lacks explicit when-not-to-use or 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 bears full burden. It states the tool lists artifacts but does not disclose that it is likely a read-only, non-destructive operation. Behavioral traits such as side effects or access methods are missing.

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

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

The description is a single, well-structured sentence that front-loads the purpose and lists the artifact types efficiently. Every part 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 no output schema, the description adequately explains the function but does not specify the return format (e.g., list of paths or names). It is minimally sufficient but could improve by describing what the user receives.

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 is empty (zero parameters), so baseline is 4. The description does not need to add parameter semantics, and it meets that baseline without repetition.

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 evidence artifacts (screenshots, trace.zip, HAR, HTML reports, visual artifacts, log files, checkpoint) from MCP browser verification. It uses a specific verb and resource, and distinguishes from sibling tools like browser_artifacts_clear.

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

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

The description implies usage after browser verification to view artifacts but does not explicitly state when to use it vs alternatives (e.g., browser_artifacts_clear for clearing). No exclusion criteria are provided.

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

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

No annotations are provided, so the description carries the full burden. It explains the sub-modes but lacks details on prerequisites, side effects, error conditions, or what happens when CAPTCHA is not found. The behavioral disclosure is limited.

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

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

The description is very concise, with three short sentences that front-load the key information (merged tool, mode parameter). 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?

With 9 parameters and no output schema, the description should cover return values per mode and usage flow. It only mentions saving PNG for screenshot and does not describe what detect or read return. The lack of output schema makes this 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 description coverage is 100%, so baseline is 3. The description adds context about mode merging but does not add significant meaning beyond what the schema already provides. The parameter descriptions in the schema are self-sufficient.

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 is a CAPTCHA processing tool that combines three sub-modes (detect, read, screenshot), with specific verbs and resources. It also mentions merging from sibling tools, clearly differentiating from them.

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

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

The description implies usage context by stating the tool merges three previous tools, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is implied, not explicit.

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 discloses key behaviors: supports two recognition methods and falls back to returning image for manual review on failure/low confidence. It does not mention whether it modifies page state or requires specific page conditions, but the read-only nature 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?

Highly concise with three sentences, front-loading the core action. Every sentence adds meaningful detail without redundancy or fluff.

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

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

No output schema exists, so the description should explain return values. It mentions returning image for manual recognition but does not specify format or structure for successful extractions. For a tool with 3 optional parameters, it covers the main flows but lacks precise return details.

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

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

Schema coverage is 100%, so all parameters have descriptions. The tool description provides no additional context beyond what the schema already states. Baseline 3 is appropriate as the description adds no extra semantic value for parameters.

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

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

Specifically states it reads captcha images from a page and supports two recognition methods (direct URL extraction and OCR), clearly distinguishing it from sibling tools like browser_captcha_detect (detection) and browser_captcha_screenshot (screenshot).

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

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

Implies usage for reading captchas and differentiates between simple (direct extraction) and complex (OCR) cases. However, does not explicitly state when to use this tool versus alternatives, nor mentions exclusions or prerequisites.

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

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

No annotations provided; the description adds behavioral context like auto-refresh on small size, but lacks details on side effects, prerequisites, or error behavior. Missing what happens if no captcha 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?

Two concise sentences front-loading the main purpose. No redundancy, but could be slightly more structured with parameter grouping.

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

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

Covers basic usage and output format (PNG), but no explanation of return value (e.g., file path or base64). Missing error conditions and integration with sibling tools.

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

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

All 6 parameters are documented in the schema (100% coverage). The description adds context about auto-detection vs manual selector but does not significantly enhance understanding 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 captures a screenshot of a captcha area and saves it as PNG. It mentions auto-detection vs manual selector, distinguishing it from related tools like browser_captcha_detect and browser_captcha_read.

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 captcha capture with auto or manual selection, but does not explicitly compare to alternatives like browser_screenshot_element or state when not to use this tool.

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

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

No annotations are provided, so the description must carry the burden. It discloses error-checking behavior, stop-on-error, and enforce mode details. However, it does not mention side effects on browser state or session persistence, which are important for a chaining 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 concise (two sentences) and front-loads the main purpose. Every sentence adds value, though it could be more structured with bullet points for 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?

No output schema is provided. The description explains error checking but lacks details about return format or what 'return failed step' means. Given the complexity of chaining and many siblings, more context on output and when to chain vs. step 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 100%, and parameters are well-documented. The description adds minimal value by noting that 'step.type' and 'step.action' are aliases and at least one required, which is already implied by anyOf. No additional semantics beyond schema.

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

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

The description clearly states the tool chains multiple browser operations with automatic error checking after each step. It distinguishes itself from single-step tools like browser_step and similar chaining tools by specifying error-checking and enforce-validation features.

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

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

The description explains the general behavior (error checking, termination on error, enforce mode) but does not explicitly specify when to use this tool over alternatives like browser_flow or browser_step. No guidance on prerequisites or exclusions.

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

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

Discloses key behaviors: returns multi-element hint instead of timeout when multiple matches, uses index to disambiguate. Describes output fields and error conditions. No annotations provided, so description carries full burden. Minor omission: doesn't mention waiting behavior or scrolling.

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 English summary followed by Chinese details in bullet points. Some redundancy between English and Chinese, but clear and front-loaded with key behavior. 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 no output schema, description covers output fields, error conditions, multi-element behavior, and use cases. Completely adequate for a click tool with good contextual detail.

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

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

Schema covers both parameters with descriptions (100% coverage). Description adds value by providing example usage and clarifying supported syntax (Playwright) and index selection behavior, which goes beyond bare 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?

Clearly states the tool clicks a DOM element matched by CSS selector in a real browser. Specific verb (click) and resource (DOM element). Distinguishes from siblings like browser_hover and browser_type by focusing on clicking. Also mentions multi-element handling.

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 scenarios in the Chinese section (e.g., triggering navigation, activating UI controls, verifying clickability, after snapshot). Does not explicitly name alternatives or state when not to use, but context is clear.

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

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

With no annotations provided, the description bears full responsibility. It details the sequence: screenshot before, click, wait, screenshot after, image diff, error collection, and return. It also explains the 'autoReturn' parameter's behavior (goBack for URL nav, re-click for SPA toggle) and mentions silentFail errors. However, it does not cover potential side effects like navigation away from the original page or error handling when element is 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?

The description is two sentences: first sentence defines the workflow, second lists return values. It is concise without being overly terse. The structure is front-loaded with the main action. Every part 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 5 parameters and no output schema, the description covers the main flow and return values (navigation status, visual diff ratio, errors, screenshot paths). It also explains key parameter 'autoReturn'. Missing details: what happens if both 'text' and 'selector' are provided or neither, and error handling for element not found. Still, it provides enough context for typical usage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema; it reiterates that 'text' and 'selector' are alternatives and explains 'autoReturn' slightly more. No significant additional context for other parameters.

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

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

The description clearly states the tool's purpose: 'Audit a single click' and describes the full workflow (screenshot→click→wait→screenshot→diff→error collection). The name also reinforces this purpose. It distinguishes itself from siblings by emphasizing it replaces multiple individual tool calls for click-through validation.

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

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

The description explicitly says 'One call replaces 6+ individual tool calls for click-through validation loops,' indicating when to use this tool as an alternative to chaining multiple browser tools. It does not provide explicit when-not-to-use scenarios, but the context is clear enough for agent decision-making.

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

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

Given the absence of annotations, the description thoroughly discloses behavioral traits: what it covers (all console types, window.onerror, unhandledrejection), and critical limitations (cross-origin scripts marked, early inline errors possibly missed, document.write() issues). This provides excellent transparency for an agent.

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 primary purpose, coverage, and boundaries in separate sections. It is informative but somewhat lengthy; a minor simplification could improve conciseness without losing key details.

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

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

The description covers parameters and behavioral limitations well, but it does not describe the output format or structure of the returned logs. Since there is no output schema, the description should hint at the return type or content 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?

All 4 parameters (level, limit, since, urlContains) are fully described in the input schema (100% coverage). The description only mentions level filtering and URL filtering briefly, adding no new semantic information beyond what the schema provides, hence baseline 3.

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

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

The description clearly states the tool reads browser console logs with level filtering, and specifies coverage (console.error/warn/log/debug, window.onerror, unhandledrejection). However, it does not explicitly differentiate from sibling tools like browser_errors, leaving some ambiguity about when to use which.

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_errors or browser_network. It only describes its own functionality and limitations, without any comparative or conditional usage advice.

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 discloses all key behaviors: read (get), write (set), and delete (clear). It notes that clear removes all cookies and set requires name/value. No side effects or permissions are mentioned, but the actions are clearly defined. The description covers the essential traits beyond what the schema provides.

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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, supported actions, output details, and practical use case (debugging auth). No redundant phrases.

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 params, nested object) and no output schema, the description explains return values for 'get' action. For 'clear' and 'set', returns are implicit. The description is sufficient for a cookie management tool among many browser siblings. A complete description would mention return format for all actions, but the current one is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context: e.g., 'name filters when action=get', 'action default is get', 'cookie object required for set'. This provides meaningful usage hints beyond the schema, justifying a 4.

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: viewing and managing browser cookies with actions get, set, clear. It specifies what it does (get all cookies, filter by domain, set, clear) and the output (total count and details). This distinguishes it from sibling browser tools like browser_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?

No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for cookie management but does not differentiate from siblings like browser_storage or other cookie-related tools. The agent must infer context from the sibling list.

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

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

With no annotations, the description bears full responsibility. It discloses that the tool generates root cause hypotheses, ranks them by confidence, and suggests verification tools. It lists the factors analyzed and implies a non-destructive analytical operation. Missing details like required session state but overall transparent.

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

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

The description is a single sentence that efficiently conveys the purpose, but it is somewhat lengthy and could benefit from clearer structure or bullet points for readability. Front-loads the main idea.

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 output schema, and many sibling diagnostic tools, the description adequately explains the core function and output nature (hypotheses with confidence, verification suggestions). It could mention the dependency on an active test failure context or session, but overall it is reasonably complete.

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

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

Schema coverage is 100% with both parameters described. The tool description does not add significant meaning beyond what the schema provides for 'format' and 'failureContext'. Baseline of 3 is appropriate as no extra value is added.

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 'counterfactual root cause analysis' when a test fails, analyzing specific factors (blockers, JS errors, HTTP errors, loading issues) to generate hypotheses sorted by confidence and verification suggestions. This is a specific verb and resource, distinguishing it from sibling tools like browser_diagnose or error_analyze.

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 specifies the context as 'when a test fails', providing clear usage context. However, it does not explicitly mention when not to use the tool or suggest alternative sibling tools for different scenarios. Nonetheless, the counterfactual nature sets it apart.

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 must carry the full burden for behavioral disclosure. It does not mention whether the tool is read-only, destructive, or requires authentication. The absence of such details leaves important behavioral traits unclear.

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 dense paragraph in Chinese. While it covers the essential points, it could be more concise and structured (e.g., bullet points) to improve readability for an AI agent.

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 13 parameters with enums and nested objects, but no output schema. The description explains the comparison modes and data sources but lacks details on the output format, errors, or behavior for edge cases, making it partially incomplete.

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

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

Schema description coverage is 100%, so even without additional param details in the description, a baseline of 3 is appropriate. The description adds overall context but does not enhance individual parameter semantics beyond what the schema already provides.

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

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

The description clearly states that the tool performs data consistency comparison between page data (tables, cards, lists) and expected or baseline data, identifying gaps. It lists multiple data sources and comparison modes, distinguishing it from sibling browser tools like visual or network analysis.

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 enumerates compare modes (dom_vs_api, etc.) and extraction modes, implying usage contexts. However, it does not explicitly state when to prefer this tool over alternatives (e.g., visual comparison or API probes) 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?

With no annotations, the description carries full burden and details what each mode does and what it returns (e.g., rootCause, suggestedFixes, hypothesis chain). It does not mention prerequisites like requiring an active session.

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 dense paragraph that efficiently conveys the tool's purpose and modes without wasted words. It could be improved with bullet points for readability.

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 (13 parameters, 3 modes), the description provides a good overview of modes and outputs. However, it does not explicitly map parameters to modes or detail return values comprehensively since no output schema exists.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for the mode parameter but does not elaborate on each parameter beyond what the schema already provides.

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

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

The description clearly states the tool is a browser debug diagnostic tool with three specific sub-modes (report, diagnose, investigate) and mentions it merges three predecessor tools, distinguishing it from siblings.

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

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

The description explains when to use each sub-mode (e.g., generate report, diagnose errors, investigate symptoms) but does not explicitly exclude alternative sibling tools for more focused operations.

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

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

With no annotations, the description bears full responsibility. It accurately describes the output as a report without side effects. It could mention that it's read-only and does not modify browser state.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and scope without 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?

For a simple tool with two optional boolean parameters and no output schema, the description covers the key aspects. It adequately informs the agent of what the report includes.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, just mentioning optional DOM/storage.

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 generates a comprehensive debug report summarizing page state, errors, network errors, and optionally DOM/storage. It distinguishes itself from sibling tools like browser_errors_aggregate and browser_network_detail.

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

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

The description implies use when a broad debug report is needed, but does not explicitly state when to use or not use this tool versus others. No alternative tools are mentioned.

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

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

No annotations are present, so the description carries full burden. It describes analysis of errors and return of a report, but does not disclose whether the tool is read-only, triggers side effects, or requires specific permissions. The behavioral disclosure is adequate but not exhaustive.

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

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

The description is concise (two sentences) and front-loaded with the main purpose. It efficiently conveys the tool's action and output, though the first sentence is somewhat dense.

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 (diagnostic with 3 parameters, no output schema), the description adequately covers the return structure and analysis scope. It lacks details on edge cases or interpretation of confidence, but is sufficient for agent use.

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

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

All three parameters have schema descriptions (100% coverage). The description adds value by listing the return fields (rootCause, confidence, etc.), which goes beyond schema details and helps the agent understand diagnostic output.

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 diagnoses browser error root causes by analyzing various error types and returns a report with specific fields. It distinguishes from sibling tools like browser_errors_aggregate by focusing on root cause analysis.

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

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

The description implies use for error diagnosis but does not explicitly state when to use this tool versus alternatives like browser_errors_aggregate or browser_network_detail. No when-not-to-use guidance is provided.

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

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

With no annotations, the description fully explains behavior: returns specific fields (exists, visible, text, etc.), error cases (no match returns exists=false, invalid selector throws error), and output structure. This is comprehensive for a read-only query.

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 somewhat lengthy but well-organized with clear sections (English, then Chinese with subheadings). Every sentence adds value, and the structure aids readability. Not overly verbose for the information provided.

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

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

Given no output schema, the description covers output structure, parameter details, error behavior, and provides an example. All necessary context for an agent to use the tool correctly is present.

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

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

Schema description coverage is 100% (CSS 选择器). The description adds context about the selector's purpose (query a single element) but no new technical or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool queries detailed DOM state of a single element by CSS selector, specifying visibility, text, attributes, computed style, and bounding box. It uses specific verbs and resources, and the details help distinguish it from siblings like browser_click or browser_element_status.

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 when-to-use scenarios: before click/input to confirm element existence/visibility, debugging occlusion, verifying attributes, getting coordinates. It does not explicitly mention when not to use or alternative tools, but the guidance is clear and relevant.

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 the tool's behavior: it checks specific states (visibility, interactability, loading, occlusion, event binding) and returns reasons and fix suggestions. It does not mention side effects, but the name and purpose imply a read-only diagnostic operation.

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

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

The description is two sentences with no wasted words: the first states what the tool does, the second states its purpose and output. Front-loaded with key information.

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

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

Given the tool's complexity (multiple diagnostic checks) and lack of output schema, the description adequately explains what the tool checks and what it returns (reasons and fix suggestions). However, it does not detail the output structure, which could help agents parse results.

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

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

All four parameters have schema descriptions (100% coverage). The tool description does not add additional meaning beyond the schema; it briefly summarizes the checks but does not elaborate on parameter semantics or constraints.

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

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

The description clearly states the tool's function: diagnosing element status (visibility, interactability, loading, occlusion, event binding) to determine why an element cannot be clicked or input, and provides specific reasons and fix suggestions. It distinguishes itself from sibling tools like browser_click (clicking) and browser_find_element (finding) by focusing on status diagnosis.

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 an element is not clickable or inputable ('快速判断元素为何无法点击/输入'), but does not explicitly state when to use this tool versus alternatives like browser_diagnose or browser_a11y_check. No exclusions or alternative recommendations are provided.

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

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

No annotations provided, so description carries full burden. It does not disclose whether emulation is persistent, if it modifies browser session, or if it has destructive effects. Minimal behavioral context.

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

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

Two concise sentences that front-load the main purpose. No extraneous information.

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

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

Given the complexity (10 params, nested objects) and no output schema, the description is brief. It omits details like return value, state persistence, and error conditions, leaving gaps for an agent.

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

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

Schema has 100% description coverage, so baseline is 3. The description adds some value by summarizing capabilities (presets, custom config) but does not significantly enhance parameter understanding beyond schema descriptions.

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

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

The description clearly states the tool simulates complete device characteristics (User-Agent, viewport, touch events, etc.) and supports presets and custom configurations. It is distinct from sibling tools like browser_navigate or browser_responsive_test.

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 vs alternatives (e.g., browser_responsive_test). The description does not mention prerequisites, side effects, 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?

No annotations are provided, so the description carries the full burden. It discloses the three modes and mentions that clear mode creates a new checkpoint. However, it does not discuss side effects, prerequisites, or limitations such as what happens to existing errors after clear, or the scope of 'this round' in view mode.

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, consisting of a short paragraph. It front-loads the purpose and version information. However, it could be better structured with bullet points or clearer separation of modes for quicker scanning.

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 9 parameters and no output schema, the description provides the high-level behavior but lacks specifics such as the types of errors included, what 'Top errors' means in aggregate mode, or the checkpoint mechanism. It is adequate but not fully comprehensive for a tool with this many parameters.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the mode parameter's equivalence to deprecated tools, which clarifies its semantics beyond the schema. For other parameters, the description does not add extra detail, but the schema itself is sufficiently descriptive.

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 is a unified error management tool and explicitly mentions it replaces two deprecated tools (browser_errors_aggregate and browser_errors_clear). It specifies three modes: view (default), aggregate, and clear, each with a brief explanation. This distinguishes it from its siblings.

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

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

The description provides clear context on when to use the tool versus the deprecated siblings by stating it is the unified version since v1.9.5. It explains the three modes and their purposes. However, it lacks explicit when-not-to-use scenarios or alternative tool suggestions.

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 deduplication, aggregation, and the default of not returning full logs, which is sufficient for a read-only aggregate operation.

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, front-loaded sentence that efficiently conveys the core functionality without filler. Every word contributes to understanding.

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 three parameters and no output schema, the description provides sufficient context for the aggregate operation. It could elaborate on what 'evidence' entails, but overall it is nearly complete.

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

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

The schema covers all parameters (100%), and the description does not add significant meaning beyond what the schema provides. The term 'Top errors' aligns with the limit parameter, but no new insights.

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 collects browser error summaries, deduplicates, aggregates, and returns top errors. However, it does not explicitly differentiate from the sibling tool 'browser_errors', which likely provides similar functionality.

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 aggregated top errors and notes it does not return full logs, but lacks explicit guidance on when to use this tool versus alternatives like browser_errors for complete logs.

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 discloses the destructive action (clearing logs) and the creation of a checkpoint, though it does not detail side effects like impact on previous checkpoints or browser state beyond errors.

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 concisely conveys the action and purpose, with 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?

For a zero-argument tool, the description is complete enough to understand the action and its purpose. Minor omission: the checkpoint's role in subsequent validation steps could be elaborated, but not essential.

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 (baseline 4). The schema is empty, and the description does not add parameter information, 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 it clears browser error logs (Console/PageError/Network) and creates a verification checkpoint, distinguishing it from sibling tools like browser_errors (reads errors) and browser_errors_aggregate (aggregates errors).

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

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

The phrase 'to isolate this round of verification errors' implies usage after a validation run to reset error state, providing context. No explicit when-not-to-use or alternatives are mentioned, but the sibling list offers differentiation.

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 only mentions auto-masking of sensitive fields. Lacks disclosure of potential destructive side effects from arbitrary JS execution.

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, no redundancy, 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?

Covers basic purpose and return behavior but omits error handling, execution context, and serialization limitations for a simple tool.

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

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

Schema covers 100% of the single parameter; description adds that result is serializable and sensitive fields are masked, but no extra syntax guidance.

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 executes JavaScript expressions on the current browser page and returns serializable results, distinguishing it from sibling browser tools.

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

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

Description implies debugging use case but does not explicitly state when to use versus alternatives like browser_click or browser_find.

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 discloses the destructive nature of clear mode ('清空运行时事件') and creation of a checkpoint, but does not mention authorization, rate limits, or other 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?

Two short sentences, front-loaded with purpose and version note. No redundant information, every sentence earns its place.

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

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

Covers the main use cases (viewing and clearing events) and filtering options. Lacks details on output format or what a checkpoint is, but is mostly complete for a viewing/clearing 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 coverage is 100%, baseline 3. The description adds context by explaining the mode parameter's sub-modes and linking other parameters (type, urlContains, method, statusMin) to filtering capabilities, enhancing understanding beyond schema.

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

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

The description clearly states it is a runtime event management tool with two modes (view and clear), and mentions it merged browser_events_clear since v1.9.5. However, it does not explicitly differentiate from other event-related siblings like browser_errors or browser_network.

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

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

The description explains when to use view vs clear via the mode parameter, but lacks explicit when-not-to-use or alternatives among 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 are provided, so the description bears full responsibility for behavioral disclosure. It states the action (clear and create checkpoint) but does not disclose side effects, such as whether events are permanently deleted, whether ongoing instrumentation is affected, or if the checkpoint overwrites previous ones. This is insufficient for a destructive 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 a single concise sentence with no wasted words. It efficiently communicates the core action.

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

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

Given no parameters and no output schema, the description covers the basic intent. However, as a destructive tool, it lacks important context such as irreversibility, effect on future captures, and definition of 'checkpoint'. More detail 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 input schema has zero parameters, so the description need not add parameter meaning. Baseline is 4 for 0 parameters; the description is clear and requires no further parameter explanation.

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: clearing runtime events captured by browser_instrument and creating a new checkpoint. The verb '清空' (clear) and resource 'runtime events' are specific, and the action distinguishes it from siblings like browser_events (read) and browser_instrument (start capture).

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 after browser_instrument capture to reset state, but provides no explicit when/when-not guidance or mention of alternatives. An agent would infer usage context but lacks clear decision support.

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 disclosure burden. It mentions supporting SPA button navigation discovery for page mode, but lacks details on error handling, return format, or the 'intelligent' aspect. Adequate but not exhaustive.

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

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

Two sentences that front-load the tool's purpose and version, then concisely explain modes. No redundant information. Efficient and well-structured.

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

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

With 9 parameters and no output schema or annotations, the description covers the two modes but omits details on return values, error conditions, or limitations (e.g., visibility, limit behavior). Adequate for basic use but incomplete for complex scenarios.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two modes and noting SPA navigation support beyond the schema descriptions. It clarifies the purpose of each mode and some parameter usage 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 it is a combined find tool for elements and pages, with explicit mode differentiation. It distinguishes itself from sibling tools like browser_find_element and browser_find_page by noting it is a merge since v1.9.5.

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 specifies when to use each mode (element vs page) and mentions SPA button navigation discovery for page mode. However, it does not explicitly state when not to use this tool versus alternatives, though the mode explanation provides clear context.

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

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

Since no annotations are provided, the description carries full burden. It discloses the matching strategy hierarchy (exact text > contains text > placeholder > aria-label > title/alt > fuzzy), error handling (empty array with ok=true for no match, error for empty text), and the return structure with confidence scores and visibility flag. This is comprehensive, though it could mention potential side effects or performance impacts.

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

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

The description is well-structured with sections for matching strategy, usage, output, parameters, errors, and examples. It is concise but includes both English and Chinese text, which may be redundant for an English-only agent. Nevertheless, every part adds useful information, and it is not overly verbose.

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

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

Despite no output schema, the description fully explains the return format ({ ok, results, total }) and the content of each result item. It covers all necessary aspects: purpose, matching strategy, parameter details, error handling, and an example. For a tool with 5 parameters and no annotations, this is complete and well-suited for an AI 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?

The input schema already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by specifying default values for onlyVisible (true) and limit (5), clarifying the role parameter values with examples, and adding error handling info for the text parameter. This extra context justifies a score of 4.

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 a 'Smart element locator' that finds visible DOM elements by text or ARIA role, using a multi-strategy matching approach. It distinguishes itself from sibling tools like browser_click or browser_find by specifying that it returns CSS selectors with confidence scores, and it is intended for cases where the selector is unknown but the text is known.

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 when-to-use scenarios in Chinese: when selector is unknown but button text is known, when UI text changes, for batch automation, and for testing elements without id/name. Although it doesn't explicitly state when not to use it, the given contexts are clear and helpful for the agent to decide.

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

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

No annotations provided, so description carries full burden. Details priority chain order, output fields (matched, matchMethod, score, etc.), error conditions ('Invalid target' for invalid target value), and behavior when navigate=true fails. Fully transparent.

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

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

Front-loaded English summary followed by structured Chinese details. Slightly verbose due to repetition, but justified given the complexity. Every section serves a purpose.

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

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

For a 3-parameter tool with no output schema, description provides output structure, error handling, use cases, and an example. Complete for agent to decide and 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?

Schema coverage is 100%, so baseline is 3. Description adds value beyond schema: explains target enum values, default for navigate (false), derivation of baseUrl from current URL when omitted, and example usage.

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: 'Smart page discovery: locate target page...' with specific verb (locate) and resource (target page). It distinguishes from siblings by specifying the priority chain and supported target types.

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 scenarios in Chinese (e.g., when URL unknown, SPA navigation, regression tests). Lacks explicit alternatives among siblings but covers context well.

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 fully bears the burden. It discloses automatic evidence capture (screenshot+snapshot) per step, the alias between type and action, mode-specific behaviors (chain checks console/network errors, batch limits steps), and the stop-on-error/continue-on-error options. While it does not cover auth requirements or session management, these are likely handled by other tools and the description provides adequate transparency for the core 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 concise (4-5 lines in Chinese), front-loaded with the core purpose, and well-structured: it states the tool function, lists operations, explains aliases, describes modes, and contrasts with a sibling. 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?

For a tool with 9 parameters, nested steps, and no output schema, the description is fairly complete: it covers purpose, mode semantics, step aliases, and sibling differentiation. However, it does not describe the return value or specify the requirement for an active browser session (though implied by the sibling list). A minor gap reduces it from perfect.

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

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

Schema description coverage is 100%, baseline is 3. The description adds value by explaining the overall workflow, the mode parameter's semantics (flow/chain/batch with deprecated tool equivalences), the type/action alias, and the auto-evidence capture. This contextual information goes beyond the schema's field-level descriptions.

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

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

The description clearly states it is a multi-step browser workflow orchestrator, lists supported operations, and explicitly distinguishes it from validation_flow by detailing the different focus and supported actions. The verb '编排' (orchestrate) and resource '浏览器流程' (browser flow) are specific, and the comparison with a sibling provides 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 provides clear context on when to use browser_flow vs validation_flow, explains the mode parameter and its sub-modes (flow/chain/batch) with their equivalences to deprecated tools, and describes the type/action alias. It lacks an explicit 'when not to use' statement but the comparison effectively guides 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 covers behavior well: filling forms, optional submission, mode differences, and output shapes. It does not mention prerequisites or handling of missing fields, but overall is transparent.

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

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

Description is well-structured with English summary followed by detailed Chinese sections. Every sentence adds useful 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?

Comprehensive coverage of all parameters, modes, output shapes, and usage scenarios. Despite no output schema, it describes return values. Sibling context and deprecation note are included.

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

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

Schema coverage is 100%. The description adds value beyond schema by explaining CSS selector vs field name patterns for 'fields' parameter and providing output format examples.

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 is a form filling tool with two modes (basic and smart), and explicitly distinguishes itself from the deprecated browser_smart_fill sibling. Verb 'fill' with resource 'form' is specific.

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 '中文详情' section provides explicit use cases: login/registration forms, multi-field forms, end-to-end submission, mock data filling. It also differentiates when to use basic vs smart mode.

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

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

With no annotations provided, the description carries full burden. It reveals behaviors: detects HTML5 validation attributes, outputs a detailed report with per-field results, and throws specific errors ('No form found', 'Navigation failed'). It also describes the output shape and default behaviors of parameters. More could be said about side effects or permissions, but it 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?

The description is thorough but somewhat lengthy, with repeated information in English and Chinese. The structure is good: English summary followed by detailed Chinese sections. However, it could be more concise by merging the English and Chinese parts or reducing 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?

Despite lacking an output schema, the description fully details the return value shape, errors, and all 6 parameters. It accounts for edge cases (no form, navigation failure). With no output schema, the description compensates well, making the tool's behavior predictable.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing Chinese explanations for each parameter, an example usage, and contextual details like '自动检测页面第一个表单' for formSelector. This goes beyond the schema descriptions, improving clarity.

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

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

The description clearly states the tool auto-detects form field validation rules and runs a complete validation flow. It uses specific verbs ('auto-detect', 'run') and resource ('form field validation rules'). It distinguishes from siblings like browser_form_fill (form filling) and browser_smoke_test (general testing) by focusing on validation detection.

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 Chinese section '何时使用' explicitly lists use cases: testing validation rule implementation, verifying required fields, checking email/url format, and length limits. This provides clear context for when to use. However, it does not explicitly state when NOT to use or mention alternatives.

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

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

No annotations are provided, so the description carries full responsibility. It thoroughly details what the tool returns (nine error categories with diagnostics) and implies it is a read-only audit (no mention of side effects). However, it does not explicitly confirm that it modifies no state, nor does it discuss permissions, rate limits, or destructive potential. The absence of annotations puts more burden on the description, and while it discloses the output structure well, it leaves some behavioral traits unstated.

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 into two paragraphs: the first provides the purpose and error sources, the second lists the return structure as a bullet-like list. It is front-loaded with the key action and scope. While slightly verbose (listing all nine return fields), each sentence adds value by clarifying what the tool captures. No redundancy, but could be trimmed slightly.

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 (aggregating nine error types) and the absence of an output schema, the description provides a comprehensive breakdown of the return structure with clear categories. It also specifies the usage context (after page load or interaction) and the default behavior for `since`. This fully compensates for the missing output schema, making the tool's behavior and results predictable for an agent.

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

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

Input schema coverage is 100% (both parameters have descriptions in the schema). The tool description does not add extra meaning beyond what the schema already provides; it does not elaborate on when to use `since` or `includeWarnings`. Since schema_description_coverage is high, a baseline of 3 is appropriate. The description adds no value beyond the schema for parameter semantics.

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

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

The description begins with a specific verb '执行全量错误审计' (perform full error audit) and clearly identifies the resource as '当前页面' (current page). It then enumerates all aggregated error sources (CDP console, injected scripts, network 4xx/5xx, etc.), which unambiguously defines the tool's scope. This level of specificity distinguishes it from sibling tools like browser_errors_aggregate (likely a lighter aggregation) and browser_click_audit (focus on click interactions).

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 the tool: '在页面加载完成后或交互操作后' (after page load or interaction). It provides clear context for appropriate invocation. However, it does not mention cases where the tool should not be used (e.g., if only specific error types are needed) or explicitly compare against alternatives like browser_errors_aggregate. Nonetheless, the guidance is practical and sufficient for most use cases.

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

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

Given no annotations, the description carries the burden. It describes automatic discovery, clicking, error checks, and cycle verification. It mentions visible mode for real-time monitoring, but lacks disclosure of potential side effects like navigation, state changes, or errors triggered by exhaustive clicking.

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 paragraph with useful detail, but it could be more structured (e.g., bullet points). It front-loads the main purpose and then lists behavior. No wasted sentences.

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 complex tool with 6 parameters and no output schema, the description provides a good overview of what it does but lacks details on return values, error handling, or when it might fail. It is adequate but not fully complete.

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

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

Schema coverage is 100%, so baseline 3 is appropriate. The description adds context for visible (shows browser for monitoring) and default URL, but other parameters like timeout, maxDepth, maxItems, includeSubMenus have meanings that are clear from names and schema descriptions. The description does not significantly enhance understanding 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 performs 'full-feature closed-loop regression testing', automatically discovering and clicking interactive elements, checking for errors, and verifying cycle completeness. It distinguishes itself from sibling tools like browser_smoke_test or browser_chain by specifying a comprehensive regression scope.

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

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

The description implies use for exhaustive regression testing but does not provide explicit guidance on when to use vs alternatives, prerequisites, or when to avoid. The phrase 'forced execution' suggests it may run regardless of state, but no further context is given.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: export format (simplified HAR), content included, and automatic desensitization. However, it does not mention side effects, permissions, file location, or error handling.

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

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

The description is a single efficient sentence that front-loads the main action and key inclusions. It is concise with no wasted words, though a structured list might improve readability.

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

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

Given 8 optional parameters and no output schema, the description provides sufficient context about what the tool produces but lacks detail on parameter interplay, output file naming/location, and how desensitization works. It adequately covers the essential aspects for a simple export 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 documentation covers all 8 parameters with descriptions (100% coverage). The tool description does not add extra parameter meaning beyond the schema, so baseline of 3 is appropriate. It adds value on output format but not on parameter usage.

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

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

Description clearly states the tool exports currently collected network records as a simplified HAR JSON file, listing included elements (headers, body summaries, status codes, time) and mentioning automatic desensitization. It distinguishes from siblings like browser_network (likely real-time view) and browser_network_detail (likely detailed raw 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?

Description implies use when a simplified HAR export is needed, but it does not explicitly state when to use this tool versus alternatives like browser_network or browser_network_detail. No exclusions or alternative recommendations are provided.

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

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

With no annotations provided, the description fully discloses behavior: effect persists until page refresh, error handling for unmatched selector ('element not found') and invalid color (defaults to red), and the output format. This is comprehensive for a simple 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 an English summary followed by a detailed Chinese section using bullet points for usage, output, parameters, errors, and example. Every sentence serves a purpose, and no information is 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?

The description covers purpose, usage guidelines, parameter details, error scenarios, and behavioral traits. Given the simple nature of the tool and no output schema, it provides everything needed for correct 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?

Although schema coverage is 100%, the description adds value by explaining that color supports CSS color values and defaults to red, and provides an example JSON. This goes beyond the schema's minimal descriptions.

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

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

The description clearly states that the tool highlights a specific element with a colored border and shadow for human observation and debugging, with the effect persisting until page refresh. This specific verb+resource combination distinguishes it from siblings like browser_find_element or browser_screenshot_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 Chinese description explicitly lists when to use: debugging element positioning, demo/review emphasis, visual walkthrough marking suspicious elements, and manual review after automation failure. While it doesn't list when not to use, the guidance is clear and provides practical contexts.

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?

Although annotations are absent, the description explains the tool's behavior (hover triggers effects) and discloses output format, error types, and example. It does not specify certain details like whether the hover is persistent, but for a simple hover action, this 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?

The description is very concise with a single English sentence followed by structured bullet points in Chinese. It front-loads the purpose and efficiently uses bullet points for details. No wasted words.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers output format, errors, and an example. It is complete enough for an agent to use correctly. It could optionally mention the type of hover event, but not required.

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 is only one parameter (selector) with 100% schema description coverage. The description adds the same description as the schema for the parameter but provides additional context like errors and output. No extra semantics beyond the schema, so baseline 3.

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

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

The description clearly states the tool is for hovering over a DOM element by CSS selector to trigger hover effects, tooltips, and dropdown menus. It is distinct from sibling tools like browser_click, browser_type, etc., as it performs a hover action.

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 Chinese section explicitly lists four scenarios when to use this tool, such as testing submenu expansion and verifying tooltip content. It provides clear context and appropriate use cases, though it does not list alternatives or 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 provided; description fails to disclose side effects like performance impact, persistence of probes, or whether it modifies page state. Only lists captured events.

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 short sentence, front-loaded with action, lists capabilities efficiently. 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?

Lacks return value description, post-conditions, or linkage to retrieval tools. Incomplete for an agent to understand full workflow.

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