ai-verify-mcp

by validpilot

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.9.5
Disambiguation3/5
Many tools have overlapping purposes, e.g., multiple validation and browser operation tools with similar names. The use of sub-modes (mode parameter) helps but still causes ambiguity, as agents must choose between `browser_flow`, `validation_flow`, `chain_spec_run`, etc.
Naming Consistency4/5
Most tools follow a `browser_xxx` or `validation_xxx` pattern, with some outliers like `contract`, `screenshot_diff`, and `api_probe`. Overall, naming is largely consistent with a predictable verb_noun structure, though a few tools deviate.
Tool Count1/5
With 142 tools, the server is extremely bloated. Many tools are merged versions with sub-modes, but the sheer number far exceeds what is reasonable for a single MCP server. This overwhelms agents and suggests poor modularization.
Completeness3/5
The tool set covers browser testing, visual regression, security scanning, link validation, and internal diagnostics. However, there are numerous redundant tools and gaps in clear separation of concerns. Some areas (e.g., skill management) seem out of scope for a general-purpose testing server.
Average 3.9/5 across 116 of 142 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on July 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It lists capabilities and summarization features (console, page errors, network, state diff, evidence) but omits critical details: whether a new browser session is created, side effects on browser state, resource cleanup, or destructive actions. The mention of 'simplified' and 'future extraction' does not clarify runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, listing capabilities in a single sentence. However, it includes meta comments about implementation ('先做进现有MCP，后续再剥离') that are irrelevant to an agent's use. This adds noise without improving understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, nested objects, no output schema), the description is insufficient. It does not specify the output format (only mentions 'summary' vaguely), nor does it highlight the only required parameter ('steps'). Important behaviors like error handling, timeout defaults, and template usage are left to the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description adds little beyond the schema; it lists high-level actions (e.g., 'open page, click, input') that map to step types already documented in the schema. It does not explain parameter interactions or provide examples for complex nested objects like 'expectations' or 'stateSources'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a simplified business chain validation with specific actions (open, click, input, wait, assert, state capture/compare) and summarizes results. It differentiates from sibling tools like 'browser_chain' by emphasizing 'spec' and a structured approach, though it doesn't explicitly distinguish from closely related tools like 'chain_spec' or 'browser_flow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_chain' or 'browser_step'. It lacks prerequisites, use cases, or exclusions, leaving the agent to infer context from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the tool modifies state, saves data, or has destructive effects. The note about temporary integration is not relevant behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes an implementation detail ('先做进现有 MCP，后续再剥离') that is not helpful for tool selection. The purpose is front-loaded, but the note reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description lacks details on return values, side effects, and how contracts are stored or used. The concept of 'baseline' is mentioned but not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameter names and descriptions. It fails to clarify parameter interactions (e.g., when both endpoints and fromNetwork are set).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: automatically extract field structure from frontend API responses to generate consumer contracts and prevent backend API drift. It specifies the resources (API responses, consumer contracts) and mentions two sources. However, it does not explicitly differentiate from sibling tools like 'contract' or 'contract_baseline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two sources (direct endpoint calls or network logs) but provides no guidance on when to use each, nor does it contrast with alternative contract tools. This leaves the agent without clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It mentions 'close and delete' but does not disclose side effects like resource cleanup, impact on open pages, or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the core action. It is front-loaded and free of redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's destructive nature, the description lacks context about what happens after execution (e.g., return value, confirmation, or persistence). The agent cannot infer the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters have descriptions. The tool description adds no extra meaning beyond 'specified' for the session name, which is already implied by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: close and delete a specified browser session. Among sibling tools like browser_session_create and browser_session_switch, the purpose is distinguishable due to the specific verb 'close and delete'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of preconditions, when not to use, or comparison with related session tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions recording performance data but does not disclose behavioral traits such as whether the trace is destructive, what kind of data is collected, or if it requires a page to be loaded. Lacks details on side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and to the point. No verbose or redundant information. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters and no output schema, the description omits important context such as what the return value is (e.g., trace ID), how to stop the trace, or how the recorded data can be accessed. For a session-starting tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema description coverage is 100%. The description implicitly indicates no parameters are needed. Baseline for 0 parameters is 4; description adds no unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool starts a browser trace session and records performance data. It uses specific verb+resource. However, it does not explicitly differentiate from similar tools like browser_performance_trace or browser_trace_stop, but the name and context imply the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like browser_performance_trace or browser_trace_stop. Does not specify prerequisites or conditions for starting a trace. Agent must infer usage from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It describes what the tool collects and produces (a JSON file) but does not disclose side effects, required permissions, rate limits, or whether the tool modifies browser state or existing data. Key behavioral traits (e.g., if it triggers side effects, if it is safe to call repeatedly) 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence that lists many components. It is front-loaded with the core purpose, but the enumeration of artifacts makes it dense and harder to parse quickly. It could be restructured into bullet points or a clearer summary while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 19 parameters, no output schema, and no annotations. The description explains what the output is (a JSON file) but does not describe its structure, how the parameters interact, typical usage patterns, or prerequisites (e.g., prior browser steps). For a complex data-gathering tool, this level of completeness is insufficient for an agent to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond what the schema already provides for each parameter; it simply summarizes the tool's overall behavior. Parameters like 'har', 'screenshot', 'snapshot' are individually well-documented in the schema, so the description does not need to elaborate, but it also does not provide higher-level context (e.g., typical combinations).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a single-step evidence package (v2.0) that aggregates screenshots, DOM summaries, errors, network requests, API response summaries, data diffs, traceId, console logs, page errors, HAR, and existing artifacts into a JSON file for dual-chain verification review. It uses a specific verb ('生成') and resource ('单步证据包'), and distinguishes itself from sibling tools by focusing on evidence aggregation for review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. Among the many sibling tools (e.g., browser_step, evidence, evidence_index), there is no discussion of trade-offs or context for selection. The usage is only implied through the detailed list of what it aggregates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions creating a session and verifying capabilities but does not state whether the tool is safe (read-only or destructive), what side effects occur, or what permissions are needed. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that efficiently conveys the tool's purpose and scope. No redundant or unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the capabilities being verified but does not explain what the output or return value is (e.g., pass/fail, report). It also references 'data URL' without clarification. Given no output schema, the description leaves gaps in understanding what the tool produces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions covering 100% of the parameters. The tool description does not add additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a self-test of MCP capabilities, listing specific actions like flow, assert, and click. It identifies the tool as a diagnostic/validation tool distinct from sibling browser action tools. However, the Chinese language and lack of an English translation may limit clarity for some AI agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mcp_health_check or browser_smoke_test. The description implies it is for verifying MCP's own capabilities, but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions using browser_eval to intercept responses, but does not clarify whether the tool is read-only, whether it modifies state, or any side effects. Important behavioral traits like permission requirements or destructive potential are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences and a list of modes, front-loading the core purpose. It is efficient though not perfectly structured (no usage example or summary line). The Chinese language may limit accessibility, but conciseness is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no output schema, and no annotations, the description needs to provide more context. It lacks explanation of return values, preconditions (e.g., browser session), error handling, and how results are structured. The tool appears complex but the description leaves many aspects uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description in the schema. The description lists the three validation modes but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate as the description adds minimal extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying CRUD data consistency by intercepting API responses via browser_eval. It lists three specific validation modes. However, it does not explicitly differentiate from sibling validation tools like validation_check or validation_flow, leaving some ambiguity about when to choose this tool over others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage contexts through the three modes (check_create_read, check_update_read, check_delete_read) but does not explicitly state when to use this tool versus alternatives among many sibling validation tools. No exclusion criteria or 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter; description adds no extra meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'inject' and resource 'runtime debugging probes', and lists specific captured events (fetch, errors, clicks, etc.), distinguishing it from sibling tools like browser_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., browser_events, browser_console). The description does not specify prerequisites or post-invocation steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses detected issue categories and return format but does not mention read-only nature, required permissions, performance impact, or safety profile. Significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with the main action ('scan project directory') and then lists specific issues. It is efficient but slightly run-on as a single long sentence. One sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no output schema, so description should explain output format. It mentions a list with severity but omits details like object structure or property names. Parameter descriptions are clear but output remains ambiguous. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema (e.g., severity filter and project path are already clear). Baseline 3 applies as no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it scans a project directory for code quality issues like hardcoded passwords, absolute paths, SQL errors, and CSS variable anomalies. It distinguishes itself from sibling tools (e.g., browser audits, security scans) by focusing on static code analysis of a project directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or compare with sibling tools like 'css_var_check' or 'security_scan'. The description only lists what it checks, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: reading MCP network logs, optionally reading backend logs or using SSH, and outputting scores. However, it omits details about side effects (e.g., SSH network activity), required permissions (e.g., file access, SSH credentials), or performance implications. No annotations are provided, so the description carries the full burden, which it partially meets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one sentence for purpose and behavior. However, the second sentence ('先做进现有 MCP，后续再剥离') is a meta comment that does not aid tool usage and could be removed. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage, no output schema, and 4 optional parameters, the description adequately explains what the tool does and what parameters are available. It mentions the output (trace coverage and correlation score) but lacks details on format or interpretation. No required parameters or enums reduce the need for extensive documentation, so it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description restates the backend parameter options (file vs SSH) but adds no new semantics beyond the schema. Parameters like 'since' and 'urlContains' are not elaborated. The description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying whether browser requests and backend logs share the same traceId/runId. It specifies the action (verify), resource (trace correlation), and output (trace coverage and correlation score). However, it does not explicitly differentiate from sibling tools like 'trace_correlate', though the name and context imply specialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'trace_correlate' or 'trace_chain'. There is no mention of prerequisites, scenarios, or when not to use it. The agent must infer usage from the tool's purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness3/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, what happens on inconsistency (only partially covered by the 'mode' parameter in schema), or any side effects. The description is too terse to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively front-loads the core action. No unnecessary words or redundant information. It is appropriately sized given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters with schema descriptions, no output schema, no annotations), the description is minimally complete. It conveys the primary task but lacks details about return values, error handling, or how it integrates with sibling tools like 'skill_validate'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 about the parameters beyond what the schema already provides. It does not explain the purpose of each parameter or how they affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: automatically verify consistency between Skill-defined tool dependencies and actual MCP server tools. It uses specific verb ('verify') and resource ('tool dependencies'), distinguishing it from siblings like 'skill_validate' which may have a different scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., skill_validate, skill_consistency_check). There is no mention of prerequisites or scenarios where this tool is inappropriate. The agent is left to infer usage from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool captures and compares state but does not disclose side effects (e.g., whether it modifies state, requires specific permissions, or has rate limits). The description also includes a forward-looking statement that adds no operational transparency. Key behavioral traits like return format or error handling are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences. The first sentence delivers the core purpose. The second sentence is slightly tangential, discussing future modularity. It is concise but could be tightened by removing the non-functional note. Structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, nested objects, no output schema), the description is insufficient. It does not explain how to invoke the two actions (capture vs. compare), how to interpret results, or what the snapshot/snapshotId concept means. The lack of output schema and missing behavioral details leave significant gaps for an agent to correctly use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has a meaningful description in the schema. The tool description does not add additional semantics beyond the schema; it only provides a high-level summary. Baseline score of 3 is appropriate as the schema already adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: capturing and comparing state (page/API/storage) before and after operations to verify expected changes. The verb 'capture and compare' and resource 'state' are specific, and it distinguishes from sibling tools which focus on individual browser actions or validation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for verification of state changes but does not explicitly state when to use it versus alternatives. The note '先做进现有 MCP，后续可剥离' provides context on its current integration but not usage guidance. Among many sibling validation tools, no direct comparisons or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose behavioral traits such as whether the flow is asynchronous, whether it modifies state, or what errors may occur. The description only states the action without side effects or guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, including a Chinese translation for clarity. No wasted words; essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description covers the basic purpose and inputs. However, it omits what the tool returns (e.g., a flow ID or result) and whether it is synchronous or asynchronous, which is important for an action that 'starts' something.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with Chinese descriptions that explain targetUrl and testScenarios adequately. The description adds context of 'end-to-end validation flow' but does not enrich 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts an end-to-end validation flow, specifying it performs multi-step verification against a target URL using a given list of scenarios. This differentiates it from sibling tools like validation_check or validation_flow, which likely serve different roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like validation_chain or validation_flow. The description lacks context about prerequisites, post-conditions, or comparison with other validation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions automatic identification and clicking but lacks details on potential side effects (e.g., accidental clicks on interactive elements), what happens if no overlay is found, or safety guarantees. This is a significant gap for a tool that performs automated clicking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and includes relevant examples. It is efficient with no wasted words, though it could benefit from clearer structuring (e.g., separating behavior from parameter details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core function and parameter but does not mention return values, success/failure behavior, or error handling. Since no output schema exists, the description should provide more context on what the tool returns, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, with the parameter 'format' fully described by its enum values in the schema. The description does not add any extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '自动关闭' (automatically dismiss) and the resource '遮挡物' (overlays), with specific examples (Cookie banners, popups, floating layers, masks). It distinguishes this tool from siblings like 'browser_overlay_detect' by including the action of closing, not just detecting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dismissing common overlays automatically, but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'browser_overlay_detect', 'browser_click'). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions persistence to .validpilot/memory/ and multi-dimensional recall, but lacks details on side effects (e.g., forget operations are permanent) or rate limits. It provides some transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is reasonably concise and front-loaded with the core purpose. However, it could be broken into structured points for clarity. Every sentence contributes value, but it remains dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, nested objects, enums) and lack of output schema, the description is moderately complete. It explains memory types and recall dimensions but does not clarify return format, error cases, or the exact behavior of forget operations. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds high-level context (e.g., '支持文本相似度+标签+主机多维度召回') but does not significantly enhance understanding beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 cross-session memory system for retrieving, consolidating, listing, and forgetting historical validation findings and repair patterns. It distinguishes itself from sibling tools by focusing on memory management, not browser actions or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. While it mentions the operations (recall, consolidate, list, forget, stats), it does not specify under what circumstances each operation should be chosen. No 'when to use' or 'when not to use' advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool checks and marks non-compliant functions but does not mention side effects, prerequisites, permissions, or how 'marking' occurs. The behavioral model is partially defined but lacks important details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the purpose, uses clear terminology, and is free of redundancy. Every word serves the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, nested objects, and no output schema. The description explains the compliance check but does not specify the return format or output behavior. Given complexity, the description should at least hint at what the tool returns (e.g., list of non-compliant functions) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds context about the overall purpose (5-step chain, NON-COMPLIANT marking) but does not clarify parameter specifics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates '链路验证合规性' (link verification compliance) for functions in the current session, specifies the 5-step chain, and indicates non-compliant functions are marked. This distinguishes it from sibling validation tools, which focus on specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking full 5-step chain compliance but does not explicitly state when to use it versus alternatives like validation_chain or validation_check. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions independent sessions per role but does not disclose side effects, auth requirements, rate limits, or whether the tool is read-only or mutates state. The behavioral impact is underdescribed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and key details. Every word contributes meaning, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema or annotations, the description is too brief. It does not explain the output report format, prerequisites, or how to interpret results, leaving significant gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description adds no additional semantic value beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: executing a multi-dimensional validation matrix covering functional, visual, performance, and a11y dimensions, and outputting a comprehensive scoring report. It also mentions role×feature permission matrix validation with independent sessions, which clearly differentiates it from sibling tools like browser_matrix_test or validation_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comprehensive multi-dimensional and role-based validation but does not explicitly state when to use this tool over alternatives or provide context on when not to use it. No comparisons or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses that it finds visible elements and generates recommendations, implying read-only behavior. However, it does not explicitly state safety (e.g., no side effects), permissions needed, or rate limits, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently conveys input conditions, action, and output components. No wasted words; front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists output components (recommendations, scores, risks, fallback list) which is good since there is no output schema. However, it fails to clarify the conditional requirement (either selector or target required) implied by the anyOf schema, which is important context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has a clear description. The tool description does not add extra meaning beyond the schema, meeting the baseline expected for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it finds visible elements based on existing selector or target text and generates more stable recommended selectors, scores, risks, and fallback lists. This is specific and distinguishes it from sibling tools like browser_locator (single locator) and browser_locator_validate (validation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like browser_locator, browser_find, or browser_locator_validate. The description implies usage when an existing selector or target is available, but does not state when not to use or mention alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool counts matches and visibility, and outputs scores, risks, warnings, and suggestions by rule type. However, it does not state whether the tool is read-only, if it requires a specific page state, whether it modifies browser state, or any error conditions. Basic behavioral traits are provided but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that covers the essential purpose and output, but it is somewhat dense and could be more structured (e.g., separate sentences for purpose, input, output). It is efficient but not optimally front-loaded for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values in detail. It mentions scores, risks, warnings, and suggestions but does not specify their format, possible values, or how to interpret them. It also lacks information on error handling, prerequisites (e.g., page must be loaded with the element), or side effects. For a validation tool, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond what the schema already provides for the two parameters ('selector' and 'sessionName'). The schema descriptions are already informative ('要验证的 Playwright/CSS/text/role 选择器'). Baseline 3 is appropriate as the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: validating selector stability. It specifies the verb '验证' (validate) and the resource '选择器' (selector), and details what statistics and outputs are computed (counts, scores, risks, warnings, suggestions) with explicit reference to rule types (role, label, etc.). This distinguishes it from sibling tools like browser_locator (find locators) and browser_locator_suggest (suggest locators).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to validate selector stability) but does not explicitly state when to use it over alternatives like browser_locator or browser_locator_suggest. No when-not-to-use or prerequisite information is provided. The usage context is inferred rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists the checks performed but does not mention potential side effects, authentication needs, or whether the tool modifies page state. For a testing tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the tool's purpose and key capabilities without wasted words. It is front-loaded with the key term '一键冒烟测试'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description mentions returning a comprehensive score and detailed results, but does not specify the scoring scale or the structure of detailed results. Given the tool's complexity, more details would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the schema already documents parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a one-click smoke test that performs five specific checks (page load, JS errors, HTTP errors, accessibility, console warnings) and returns a comprehensive score and detailed results. This specificity distinguishes it from sibling tools like browser_errors_aggregate or browser_a11y_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies quick, initial validation but does not explicitly state when to use this tool versus alternatives like browser_errors_aggregate or browser_a11y_check. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the behavioral burden. It explains the tool as a merged entity and describes each mode's action (e.g., generating baselines, diffs, reports). However, it does not disclose side effects like file creation, resource usage, or prerequisites for each mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that efficiently conveys the tool's nature and mode breakdown. Every sentence provides necessary information without redundancy. Slightly longer due to parameter enumeration, but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters and no output schema, the description adequately outlines mode-specific usage. However, it lacks information about return values or output structure, which is needed for an agent to interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage. The description adds value by grouping parameters per mode (e.g., 'mode=diff 时使用'), clarifying context beyond schema. This helps an agent understand parameter applicability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a visual regression and UI checking tool that consolidates multiple modes. It uses specific verbs and resources ('视觉回归', 'UI 检查'). However, it does not explicitly differentiate from sibling tools like browser_screenshot or browser_snapshot, which carry similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a detailed breakdown of each mode and when to use them (e.g., 'baseline（默认，建立视觉基线 PNG）'). It lacks external guidance on when to prefer this tool over siblings 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only describes output content and does not mention side effects, read-only nature, required permissions, or any safety traits. For a reporting tool, it is likely read-only, but this is not stated, leaving behavioral assumptions to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose and dimensions. It avoids redundancy but includes a note about future separation. One sentence could be considered extraneous, but overall it efficiently conveys the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output structure (5 dimensions, weighted total score, grade) without an output schema. It is sufficient for an agent to understand what the tool returns. However, it lacks specifics on scoring methodology or scale, which could be needed for precise invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with brief descriptions for each parameter (runId, result as alias, chainResult). The tool description adds context that the result comes from chain_spec_run, but does not add significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 5-dimensional scoring report for chain_spec_run results, listing each dimension: functionality, technology, consistency, contract, and observability. This specific verb+resource combination distinguishes it from sibling tools like chain_spec_run (which runs the chain) and other reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after obtaining chain_spec_run results, but does not explicitly state when to use this tool versus alternatives. It lacks when-not guidance or alternative suggestions. The phrase '先做进现有 MCP，后续再剥离' provides context but not actionable usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains it extracts DOM data, calls an API, and compares them, detecting several issue types. However, it does not disclose whether the tool is read-only, what permissions it requires, or any side effects on browser state. Since no annotations are provided, the description carries the full burden and is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two sentences clearly stating the purpose, modes, and detection capabilities. It is front-loaded with the key action and adds no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values. It mentions detection capabilities but does not describe the output format (e.g., does it return a diff report?). For a tool with 10 parameters and no output schema, more detail on results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The tool description is a high-level summary that does not add new meaning beyond the schema, but it does not need to because the schema already provides adequate detail. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool compares DOM data with API data to detect inconsistencies, omissions, and format differences. It mentions two modes (list and detail). However, it does not explicitly differentiate from sibling tools like 'browser_data_compare' or 'trace_correlation_check', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need to verify UI-API consistency, but it provides no explicit guidance on when to use it versus alternatives, no prerequisites, and no conditions that would make it inappropriate. The mention of 'list' and 'detail' modes gives some context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states that the tool does not automatically modify code, which is a key behavioral trait. However, it does not mention other aspects like idempotency, side effects, or permission requirements, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose and constraints. No superfluous words. The semicolon separates the action from a key behavioral note, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains that the tool returns up to 3 minimal fix suggestions, but does not specify the format or structure of the output. It also lacks context on how it relates to sibling tools, leaving some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (2 of 4 params have descriptions). The description mentions using errorSummary and contextFiles, and implies a default of 3 suggestions, adding minimal value beyond the schema. It does not explain the 'file' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: based on errorSummary and contextFiles, return up to 3 minimal fix suggestions without automatically modifying code. It uses a specific verb ('return') and resource ('fix suggestions'), and distinguishes itself from sibling tools like error_analyze by being suggestion-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide when-not or prerequisite conditions. It implies usage when errorSummary and contextFiles are available, but lacks guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions returning pass/fail details and evidence screenshots, but does not disclose read-only nature, side effects, error handling, or response format. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently cover core functionality and output. Every word contributes to understanding, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no output schema, and no annotations, the description provides a good overview but lacks details on output structure, error handling, and assertion ordering. It adequately covers what the tool does but leaves gaps for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds an overview of assertion types and evidence collection, but does not elaborate on parameter usage beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'validate' and the resource 'specific DOM element state', listing specific aspects like existence, visibility, text content, etc. It distinguishes itself from sibling tools by emphasizing multi-assertion combination and evidence output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying DOM element states, but does not provide explicit when-to-use or when-not-to-use guidance. It lacks mention of alternatives or prerequisites, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, required permissions, or whether the tool is read-only. For a detection tool, missing information about safety or impact reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently captures the tool's purpose and main modes. It is front-loaded and contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters and no output schema, the description is relatively brief. While the modes are explained, there is no guidance on which parameters to use for each mode or on expected outcomes, leaving the agent to infer from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already provides detailed parameter descriptions. The tool description adds value by contextualizing the action enum and modes, but it does not add meaning beyond what is in the schema for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 permission escalation detection tool and enumerates three specific modes (horizontal privilege, vertical privilege, role menu), which distinguishes it from sibling tools that are mostly browser automation or generic validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the three modes and their use cases, providing context for when to use each mode. However, it does not explicitly state when not to use this tool or mention alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions automatic browser creation/closing, isolation, and the alias relationship between step.action and step.type, but lacks details on destructiveness, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized at 4 sentences, front-loaded with purpose, and contains no redundant or superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multi-browser, multi-step) and the absence of an output schema and annotations, the description is adequate but leaves gaps regarding output format, error handling, and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the description adds limited value beyond clarifying that action and type are aliases and that at least one is required. This is sufficient but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a cross-browser matrix test that executes the same action sequence on multiple browser engines and returns comparison results. It specifies supported browsers and automatic management, making the verb+resource combination distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool (for cross-browser testing) and lists supported browsers, but does not explicitly mention when not to use it or provide alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions navigation behavior, wait conditions, timeout, and error types, but does not clearly state if the tool is read-only or whether it modifies state. The behavioral coverage 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English sentence is front-loaded and clear, but the lengthy Chinese section duplicates schema info and adds redundancy. A more streamlined description would be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description defines the output structure and lists error cases. It covers parameters, usage contexts, and default values, making it fairly complete for a navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 an example and repeats parameter explanations from the schema, providing marginal extra value. No significant new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Navigate the browser' and lists specific actions (forward, back, refresh, reload), making the tool's purpose unambiguous. It does not explicitly contrast with sibling tools, but the distinct set of actions differentiates it adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '何时使用' section that specifies when to use the tool: after browser_open, after form submit, for testing navigation, etc. This provides explicit usage context, though it does not discuss when not to use it or name direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that output is automatically sanitized and lists the included fields. However, it does not explicitly state read-only behavior, rate limits, or whether the tool requires prior network requests. The transparency is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word adds value, listing key outputs and the sanitization feature. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description explains the return fields (headers, body summary, duration, failure reasons). However, it does not clarify the 'round' or 'checkpoint' concept referenced in the parameter schema, nor does it specify the data structure (list vs. single item). Slightly incomplete but largely sufficient for a detail viewer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional meaning beyond the schema; it does not explain parameter interactions, deprecations, or search behavior. It merely rephrases the tool's output without relating to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 details of network requests for the current session. It lists specific elements (headers, body summary, duration, failure reasons) and mentions automatic sanitization, distinguishing it from siblings like 'browser_network' and 'browser_har_export'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not specify prerequisites, exclusions, or scenarios where other tools would be more appropriate. No contextual cues are provided to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that dismiss mode automatically clicks to close overlays (implying mutation), and detect mode identifies elements. However, it does not detail side effects (e.g., page changes), permission needs, or whether the operation is reversible. Given the tool's simplicity, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly stating the purpose and sub-modes. It is front-loaded with the main functionality and avoids unnecessary details, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the tool returns (e.g., detected overlays, success status). The description only mentions actions ('detect' and 'dismiss') but does not describe the output format or expected results, leaving a gap for the agent to infer the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive enum values. The description adds context about the merger version but does not significantly enhance understanding beyond the schema. The parameter descriptions in the schema already cover the meaning of 'mode' and 'format'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting and dismissing overlays like popups and banners. It explicitly mentions that it is a merged tool (v1.9.5) combining two previous tools, which distinguishes it from siblings like browser_overlay_detect and browser_overlay_dismiss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes (detect and dismiss) with defaults, implying when each mode should be used. However, it does not provide explicit guidance on when to use this tool versus alternative approaches (e.g., browser_click for manual closing), nor does it state prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions output format, supported metrics, and error scenarios (browser not launched, duration impact). However, it does not state whether the tool is read-only, whether traces persist, or cleanup behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description includes both English and Chinese sections, causing redundancy. The English part is concise (2 sentences), but the Chinese section repeats and adds details. Could be streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 5 optional parameters, no output schema, no nested objects. Description covers purpose, usage, parameters, output structure, and example. Provides enough context for an agent to understand the tool's function and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds minor context (e.g., using current page if URL omitted) but largely repeats schema info. No new meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool records a complete performance trace and outputs HAR plus structured data. The verb 'Record' and resource 'performance trace' are specific. However, it doesn't differentiate from sibling tools like browser_performance or browser_har_export, which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases in the Chinese section (e.g., deep performance analysis, HAR file forensics). Provides error conditions and an example. However, it doesn't mention when not to use this tool versus alternatives like browser_lighthouse_audit or browser_network_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the effect on subsequent tools but does not disclose behavioral traits like what happens to the previous session, whether the switch is reversible, or if there are any side effects. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loading the core purpose and the consequence of the switch. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description covers the primary action and its impact on future tool calls. It does not explain parameter meanings, but the schema covers that. It is fairly complete but could mention what happens if the session doesn't exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with parameters 'name' (required) and 'sessionName' (optional alias). The description adds no additional meaning beyond the schema, as it does not explain the distinction between the two or provide use-case-specific guidance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it switches the active browser session, and the purpose is distinct from sibling tools like browser_session_create (create) and browser_sessions (list). The verb '切换' (switch) combined with '活跃浏览器会话' (active browser session) precisely defines the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to set the active session for subsequent tools that omit sessionName. However, it does not explicitly state when not to use it or mention alternatives (e.g., creating a new session instead). The guidance is present but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It states the tool 'views' storage, indicating a read-only operation. This is clear, but it could be more explicit about having no side effects or requiring no special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose. It is front-loaded and contains no unnecessary words, though it could be slightly more structured by separating purpose from usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description covers the core purpose. However, it omits details about what the tool returns (e.g., key-value pairs), which would be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is well-documented in the schema. The description adds context about the tool's purpose but does not add meaningful semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool views localStorage, sessionStorage, or cookies, and helps locate login/status issues. While it distinguishes from 'browser_cookies' by covering multiple storage types, it does not explicitly differentiate itself, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking storage related to login/status, but does not provide explicit guidance on when to use this tool versus alternatives like 'browser_cookies' or 'browser_state'. No exclusions or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states the output constraints (within 500 characters, excludes complete logs, duplicate stacks, and response bodies), which gives the agent clear expectations. However, it does not mention whether the tool is read-only or has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core functionality and constraints. Every word earns its place; there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format and constraints, compensating partially for the lack of output schema. However, it does not describe how errors are aggregated or how to use the input parameters, leaving the agent with incomplete guidance for correct invocation. Given the tool's moderate complexity (2 parameters, one nested), more detail would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation for the two parameters ('limit' and 'evidence'). The tool expects a nested object, but the description lacks any guidance on their meaning, format, or relationship to the error aggregation, severely degrading its usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Output the error aggregation results as a Markdown summary within 500 characters, excluding complete logs, duplicate stacks, or complete response bodies.' It includes a specific verb ('output'), resource ('error aggregation results'), and output format ('Markdown summary'), distinguishing it from sibling tools like 'error_analyze' or 'error_fix_suggestion'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get a summary of errors) but does not provide explicit guidance on when not to use it or mention alternative tools. The lack of exclusions or context-specific recommendations limits its helpfulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions low token usage, specific checks, and outputs. However, it does not disclose whether the tool is read-only, has side effects, or requires specific permissions. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose, scope, and outputs. Every part carries weight, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and basic outputs, but lacks parameter details and output format (e.g., structure of errors, artifact path). Without output schema, more detail on return values would be beneficial. Overall adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any parameters. The parameter names (url, timeout, headless) are somewhat self-explanatory, but the description adds no additional meaning or context, such as units or behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs low-token quick validation on a single page, listing specific checks (Console, Network, PageError, DOM/ARIA/text summary, stable selector reachability) and outputs (pass/fail, top errors, artifact path). This differentiates it from sibling tools like validation_run or validation_start which are likely more comprehensive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick, low-resource validation on single pages but does not explicitly state when to use this tool versus alternatives like validation_run or validation_start. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers basic behavior (detection and analysis) but does not disclose side effects, permissions, or limitations. It adequately describes the main function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the tool's purpose. It is appropriately sized with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 sufficiently explains what the tool does and what output options exist. It could mention working on the current page but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (format) having a default and enum. The description does not add meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects occluding elements (popups, cookie banners, overlays) at the DOM level, analyzing properties like z-index and coverage. It distinguishes itself from siblings like browser_overlay_dismiss and browser_visual_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 overlay detection but does not exclude alternatives or mention context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述说明了核心行为（打开URL、截图、返回截图和差异分析），但未披露副作用（如是否修改浏览器状态、是否需要会话、是否关闭标签页）、输出格式细节，且没有注释提供额外信息。对于无注释的工具，描述承担全责，但仍不够全面。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅两句话，第一句点明目的，第二句说明操作和结果，简洁无冗余，信息呈递高效。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具参数完整且有schema描述，但无输出schema，描述未说明差异分析的具体形式（文本还是图像）、是否依赖浏览器会话、以及前置条件。对于多视口对比这类复杂操作，信息不够完整。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema覆盖100%，参数描述已包含各参数含义，描述没有补充超出schema的信息。符合基线3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具用于模拟多视口截图对比以检测响应式布局问题，动词明确（模拟、截图对比、检测），资源明确（响应式布局），与兄弟工具无重复，因为其他工具不提供多视口比较。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述隐含用于响应式测试场景，但未明确说明何时使用此工具而非其他截图工具（如browser_screenshot）或设备模拟工具（browser_emulate_device），也没有提供何时不使用或替代方案。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool tests multiple bypass methods (no cookie, modify user ID, remove auth header, backdoor paths) but does not mention potential side effects, authorization requirements, or state changes. This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences in Chinese) and front-loaded with the core purpose. Every sentence adds information without redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool does and its methods, but it omits important context: there is no output schema, so the agent does not know what the tool returns (e.g., JSON with success/failure details). Given the tool's complexity and security implications, more context about output and safe usage is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The tool description adds value by listing example test cases (e.g., no_cookie, fake_user_id) that correspond to the testCases enum, enhancing the schema meaning. It also clarifies the purpose of authApiPath and userIdToTest beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'authentication bypass detection' using multiple methods. It specifies the verb (检测) and resource (登录验证 bypass), and distinguishes itself from sibling security tools by focusing specifically on bypassing login verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like security_scan or security_sql_injection_scan. It does not mention when not to use it or any prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It lists the possible actions (save, load, etc.) but does not elaborate on side effects (e.g., overwriting behavior of save, irreversibility of delete) or authorization requirements. The description conveys basic operations but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence to list all actions and context. It front-loads the purpose. However, it could be structured with bullet points for clarity, but remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple actions but no output schema, and the description fails to mention what each action returns (e.g., compare returns drift, list returns baselines). It also does not clarify that contracts parameter is only needed for save/compare, which could lead to misuse. Given the complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are well-documented in the schema. The description adds no additional semantic meaning beyond what the schema provides (e.g., action enum values or contracts field usage). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages consumer contract baselines with specific actions (save, load, compare, list, delete) and mentions integration with contract_guard, distinguishing it from sibling tools like contract and contract_guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it should be used with contract_guard for API change versioning, providing context. However, it does not explicitly state when not to use it or provide alternatives, which is acceptable as no direct sibling exists for baseline management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states that the tool analyzes CSS for missing variable definitions and generates suggestedFix, implying it is read-only. However, it does not describe the output format or any potential side effects, but the behavior is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and each sentence adds value. It is appropriately sized with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks details on the return structure. It mentions suggestedFix but does not fully specify output fields. Adequate but could be more complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 some context linking parameters to the tool's analysis purpose, but does not provide additional meaning beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs (分析, 扫描, 检测, 生成) and clearly states the resource (CSS files/variables). It distinguishes itself from sibling tools, none of which are CSS-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when-to-use or when-not-to-use guidance. It merely describes the tool's function without contextualizing its use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's aggregation and analysis behavior but does not mention potential side effects, read-only nature, permission requirements, or whether it modifies state. The context added is helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the key purpose. It is concise but could benefit from structured formatting (e.g., bullet points) for clarity. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately hints at the output (hypotheses, evidence chain, next steps). Parameter count is 8 with full schema coverage. The description is reasonably complete for a debugging aggregation tool, though it could specify the output format in more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a clear description. The tool description adds overall context but does not elaborate on parameter meanings beyond what the schema already provides. Baseline score of 3 is appropriate given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool aggregates debugging information (errors, events, network, DOM, storage, artifacts) based on input symptoms and outputs hypotheses, evidence, and next steps. It distinguishes from sibling tools like browser_errors_aggregate or browser_events which handle only individual data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a problem symptom is known and a comprehensive investigation is needed. However, it does not specify when to prefer this over individual debugging tools (e.g., browser_errors_aggregate, browser_network) or provide exclusions. No explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only or has side effects, what authentication or permissions are needed, or any limitations (e.g., input size, error handling). Only the mode and default are mentioned, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. It is front-loaded with the most important information (tool purpose and merger) and quickly details the mode sub-functions. No unnecessary words or repetitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description provides basic context about modes but lacks details on output formats (beyond mentioning Markdown for summary), error handling, and prerequisites. It is adequate for a simple tool but leaves gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds limited value beyond the schema. It explains the mode parameter's options, which the schema also does. The description does not provide additional meaning for other parameters (limit, errors, format, errorType) beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 an error analysis tool that merges two previous tools (error_fix_suggestion and error_summary_md). It specifies two modes: fix (generating fix suggestions from error logs) and summary (generating error summary Markdown reports). The verb 'analyze' and the resource 'errors' are implicit but clearly communicated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the tool merged error_fix_suggestion and error_summary_md, implying it should be used instead of those. However, it does not provide explicit guidance on when to use this tool versus other sibling tools like browser_errors or other error-related tools. The distinction is implicit through the mode parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It explains that pack mode generates a JSON file summarizing various evidence types, and index mode scans directories. However, it does not mention side effects like file creation, permissions needed, or potential rate limits. The description gives a reasonable overview but omits important implementation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a version note, then explaining the two modes and their outputs. Every sentence adds value. It could be slightly shorter, but it efficiently conveys the essential information for a complex tool with 21 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two modes, many parameters, no output schema), the description provides a reasonably complete overview. It explains what each mode produces (JSON file contents, timeline). It could mention file system interaction or error handling, but overall it covers the key aspects sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, providing adequate per-parameter info. The tool description adds context by grouping parameters under modes and explaining the overall purpose, but it does not add significant extra meaning beyond the schema descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is an evidence management tool that merges evidence_pack and evidence_index since v1.9.5. It clearly defines two sub-modes (pack and index) with distinct responsibilities: generating single-step evidence packages vs. indexing for a timeline. This distinguishes it from sibling tools like browser_* tools and even the deprecated individual evidence tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides indirect usage guidance by defining the mode parameter and explaining what each mode does. However, it does not explicitly state when to use this tool vs. the deprecated evidence_pack/evidence_index siblings, nor does it mention when not to use it. The guidance is adequate for mode selection but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains two key behaviors: consistency check (without relying on external file) and drift detection (with mapDrift as warning). It also implicitly describes mode behavior (strict vs warn). However, it does not disclose potential side effects, authentication needs, or expected output format beyond the mode parameter note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the primary action front-loaded. Every sentence provides essential information without redundancy. It efficiently covers the two main validation aspects and mode behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values. It only hints at pass/fail in the mode parameter description but does not explicitly state output structure for either consistency check or drift detection. The tool is moderately complex with two checks and two modes, so more detail on output would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant meaning beyond what the schema already provides for parameters. The mode parameter's behavior is partially reinforced in the description (mapDrift is warning), but no new semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's two functions: batch validation of skill tool consistency and drift detection. It specifies the scope (all open-source Skills) and key distinguishing detail (independent of external file). This verb+resource with specific scope makes it distinct from sibling tools like skill_validate or skill_tools_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., when to use skill_validate or skill_mcp_validate). No context for when-not to use it or prerequisites are mentioned. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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 describes the tool as a management tool with two modes and lists what each mode returns (headers, body, timing). However, it does not explicitly state whether the tool is read-only, if it modifies state, or any prerequisites (e.g., need for a live session). The behavioral traits are partially disclosed but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the tool's purpose. It efficiently covers the key aspects: merging, mode distinction, and filtering. However, it could be more structured (e.g., bullet points for modes) to improve readability, but overall it is well-sized and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, two modes, no output schema), the description covers the main functionality but lacks details on return format (e.g., pagination, number of entries), behavior of the 'currentOnly' parameter, and any side effects. It is adequate for basic understanding but incomplete for advanced use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 significant value by explaining the mode parameter's sub-modes and providing context on filtering capabilities (URL, method, status code, checkpoint) that maps to multiple parameters. It also clarifies that 'since' is an ISO timestamp and that 'currentOnly' defaults to true. This goes beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool is for network request management, merging the deprecated browser_network_detail. It explicitly describes two modes (list and detail) with distinct purposes, and the context of merging distinguishes it from the deprecated sibling tool. The verb '管理' (manage) and resource '网络请求' (network request) are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode (list for listing requests, detail for viewing details). It mentions that detail mode is equivalent to the deprecated browser_network_detail, implying migration guidance. However, it does not explicitly exclude other tools like browser_errors or browser_har_export, nor does it advise against using this tool for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the iterative fix-and-verify process and return values. However, it omits potential side effects (e.g., page state changes), failure handling, or whether operations are read-only/destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Every sentence adds value. Minor improvement: could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, many sibling browser tools), the description lacks comparison to similar tools (e.g., browser_verify_fix) and doesn't detail return structure. It is adequate but leaves gaps for an AI agent to fully understand when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% - all parameters are already well documented in the input schema. The description adds only high-level context about fix strategies, not specific parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: automatically attempt common fix strategies to resolve browser interaction problems. It specifies actions (wait, scroll, force visible, remove occlusion, inject JS) and return values (logs, status, next action). This distinguishes it from sibling tools like browser_click or browser_find.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when encountering problems (supported by 'problem' parameter enum). It mentions batch support. However, it does not explicitly say when NOT to use it or provide alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions aggregation of request/response bodies and console errors, and implies a read operation. However, it does not explicitly state whether the tool is read-only, requires specific permissions, or has any side effects. The parameter includeBackendLogs hints at SSH requirements, but this is not disclosed in the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. Every part is essential, and there is no wasted text. It is concise yet informative, capturing the core functionality and key capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers the main functionality well: tracing chains and aggregating data. It specifies input methods (trace_id or time point) and data collected (request/response bodies, console errors). However, it does not mention the output format (e.g., list of chains) or any limitations (e.g., time range constraints). A bit more detail on what the output looks like would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% description coverage for all 5 parameters, so the tool description adds minimal value beyond context. It does not detail parameter usage or provide additional semantics beyond what the schema offers. The baseline is 3, and the description meets that without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: tracing the full request chain from frontend to API to backend using trace_id or time point. It specifies the resource ('全链路调用链') and the action ('追溯'). The description differentiates from sibling tools like browser_network_detail (focus on network requests) and browser_flow (step flows) by emphasizing full chain aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tracing chains via trace_id or time point, but it does not explicitly state when to use this tool over alternatives like browser_network_detail or browser_trace_start/stop. No guidance on prerequisites or when not to use is provided. Given the many sibling tools, more explicit usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool identifies 6 node types and checks various aspects (reachability, forms, buttons, network, state transitions). It does not state whether the tool is read-only or modifies state, but the task is validation-oriented, so likely non-destructive. This is fairly transparent for its purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear overview followed by a list of node types. It is well-structured and front-loaded with the core purpose. Minor redundancy could be trimmed but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description lacks details on return values or how to interpret results. It does explain what is checked but not what the agent receives back. Context is adequate for understanding the tool's function but incomplete for full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add parameter-level details beyond the schema. It mentions node types but those are not parameters. The schema already describes each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool validates business loops by identifying 6 specific node types (lead_capture, product_browse, etc.) and checking reachability, form integrity, and flow coherence. This is distinct from sibling tools like browser_flow or validation_flow which are more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for business loop validation but does not explicitly state when to use this tool over alternatives like browser_flow, validation_flow, or browser_smoke_test. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It describes the three modes but fails to mention any side effects, permissions, or potential destructive actions (e.g., browser navigation in run mode). The description is too brief to cover behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the merge context followed by mode breakdown. Every sentence adds value, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, nested objects, no output schema), the description lacks details on return values or expected outputs, especially for 'run' and 'score' modes. It mentions a scoring report but no specifics. The tool also interacts with browsers but no behavioral context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all 20 parameters. The description adds value mainly by explaining the mode parameter and its enums, but does not elaborate on other parameters beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a chain specification tool that integrates three previous tools, and explains the three modes (list, run, score) with specific purposes. It distinguishes from sibling tools like chain_list_templates, chain_spec_run, and chain_score_report by noting the merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each mode: list for listing templates, run for executing chain validation, score for generating scoring reports. It also mentions the merge, implying these were separate alternatives, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description effectively communicates the tool's behavior: it scans a directory, groups data by runId, and returns a timeline with metrics. It also discloses that filtering by runId and including traceIds is optional. The description is transparent about the read-only nature (no mention of side effects), though it could explicitly state that no modifications occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only a few sentences to convey the core purpose, parameters, and output metrics. It is front-loaded with the main action and avoids any extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and no output schema, the description provides a good overview of the output: a timeline with key metrics like traceId, error count, API response count, and data diff count. While it does not detail the exact output structure, it provides enough context for an agent to understand the tool's purpose and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds context by explaining that runId filters the timeline and includeTraceIds controls trace ID inclusion. However, it largely restates the schema descriptions, providing marginal additional value. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans evidence.json files in the reports directory, groups by runId to generate a validation timeline, and aggregates key metrics. It is specific about the verb (index/scan), resource (evidence files), and outcome. However, it does not explicitly differentiate from sibling tools like 'evidence' or 'evidence_pack', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cross-step and cross-runId retrieval, but it does not provide explicit guidance on when to use this tool versus alternatives. Sibling tools like 'evidence' and 'evidence_pack' exist, yet no usage boundaries or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It explains mode behavior and notes that sqli/xss modes support query parameters in URLs, but does not disclose other behavioral traits like rate limits, authentication needs, or side effects (e.g., scanning may trigger alerts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the key information (version merge and mode list). It is reasonably concise for the amount of context conveyed, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema), the description adequately covers the modes and URL parameter hint. However, it lacks information on expected output format, error handling, or how results should be interpreted, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond the schema: it explains the equivalence to deprecated tools, notes that sqli/xss modes can include query parameters in the URL, and clarifies the default mode. This adds value for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a consolidated security scanning tool replacing five older tools. It specifies each mode's function and the equivalent deprecated tool, providing strong purpose clarity and differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (by mentioning deprecated tools) but does not explicitly provide when-to-use or when-not-to-use guidance. It lacks alternatives or exclusion criteria, relying on the agent to infer context from the mode list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It adequately describes the output (HTML report and JSON data), the directory structure (dependent on run-id), and the report sections. However, it does not mention potential side effects (e.g., overwriting files) or access requirements. The level of detail is sufficient for a tool with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence in Chinese that front-loads the core action. It includes all essential details (output format, structure, directory logic) without extraneous information. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides complete context: what it does, the resulting output structure, and where files are saved. It covers all necessary information for a simple export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is effectively 100%. According to guidelines, a baseline of 4 is appropriate. The description adds value by explaining the output behavior (directory fallback, report structure) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary purpose: exporting the latest validation result as a static HTML report with a specific six-section structure. It uses a strong verb 'export' and specifies the output resource (validation results). While it does not explicitly differentiate from sibling tools like 'validation_report', the description is specific enough to convey its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It implies it should be used after a validation run, but does not mention when to avoid it or specify any prerequisites or exclusions. No comparative context with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the two behavioral modes and mentions output for validate (score and risk), but does not describe side effects, destructiveness, permissions, or error handling. It adds some value beyond the schema but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the purpose and merge history, and efficiently presents the mode distinction. It wastes no words, though it could be slightly more structured (e.g., bullet points for modes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two modes, no output schema), the description covers the main behaviors and explains the merge of two sibling tools. It lacks return value details for suggest mode and error handling, but for a selector tool with well-documented schema, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 by explaining the two modes and that suggest can use target text, but it largely restates the schema's parameter descriptions. It provides overall integration but no additional semantics per parameter beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'selector positioning tool' combining suggest and validate modes. It specifies the verb (定位/position) and resource (selector), and distinguishes from sibling tools like browser_locator_suggest and browser_locator_validate by noting the merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use suggest mode (default, for generating stable selectors from existing selector or target text) versus validate mode (for verifying selector stability with match counts and risk scores). It does not explicitly mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It outlines the flow (record, execute, verify, compare, return) and mentions return fields. However, it lacks details on side effects, error handling, or failure scenarios, which is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose, listing return fields. It is efficient but could be slightly more structured with bullet points for readability. No waste sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (1 required, enum, nested object) and no output schema, the description covers the tool's flow and return values well. It compensates for the lack of output schema by listing before/after, fixStatus, etc. Reasonably complete for a repair-verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant meaning beyond the schema, which already describes all parameters well. It mentions the default fixAction but no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'repair verification closed-loop tool' that records pre-state, executes repair actions, verifies post-state, and compares differences. It distinguishes itself from sibling tools like browser_click or browser_quick_fix by integrating repair with verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage, listing supported repair actions (click, type, wait, etc.) and the default action (quick_fix). However, it does not explicitly state when not to use this tool or suggest alternatives, such as directly using browser_click or browser_quick_fix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the two modes and their basic operations, but does not disclose what the tool returns, side effects, permissions, rate limits, or how the output looks. This is adequate but not comprehensive for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and mode differentiation. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema), the description covers the main modes but lacks details on output format, return values, or step-by-step usage guidance. It is minimally complete but could be more helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 12 parameters. The tool description adds overall context about merging and modes, but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an API contract tool merged from contract_guard and contract_baseline, and explains two distinct modes (guard and baseline) with specific actions. This distinguishes it from sibling tools like contract_baseline and contract_guard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode (guard for generating consumer contracts from actual API responses, baseline for managing baselines) and lists baseline actions (list/save/load/compare/delete). However, it does not explicitly state when not to use the tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无 annotations，描述补充了数据源（handlers/skill_map.js）和交叉校验（与 prompts.js），但未明确说明查询是只读操作，也未提及其他行为特性（如错误处理、权限）。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
仅两句话，第一句总述目的和方法，第二句说明数据源和校验。无冗余，信息密度高。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
缺少输出格式说明（如返回列表还是对象），尽管 schema 描述 includeDetails，但无 output schema 的情况下，描述未提供足够信息让 agent 完全理解返回结构。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
input schema 已覆盖 100% 参数描述，描述未对 includeDetails 参数额外解释，但 schema 说明已足够。描述仅重复了 skillName 和 toolName 的主要用途，未增加实质额外语义。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
明确使用动词 '查询' 描述双向映射功能，并具体列出 skillName 和 toolName 两种入口。与 sibling 工具（如 skill_validate、skill_consistency_check）有清晰区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
指明了两种典型使用场景：传入 skillName 返回工具链，传入 toolName 返回引用它的所有 Skill。但未提到何时不适合使用或与其他工具的比较。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It lists error conditions and output structure, but does not explicitly state whether the tool is read-only (e.g., 'Does not modify browser state'). Given the nature of Performance API calls, it is likely safe, but the description misses the opportunity to confirm non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when-to-use, output, parameters, errors, example). It is front-loaded with an English summary followed by Chinese details. The redundancy between languages slightly reduces conciseness, but overall it is efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is remarkably complete. It covers the return value structure, possible errors, and explicit use cases. No additional information is needed for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'sessionName' parameter. The description adds marginal value by repeating the parameter's purpose and noting it is optional with a default, and provides an example. This is sufficient but not above the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Memory leak detection: via Performance API, measures detached DOM node count, event-listener leak risk, JS heap size, and total DOM node count'. It provides a specific verb ('detect') and resource ('memory leak'), and distinguishes itself from sibling tools like browser_performance or browser_performance_check by focusing solely on memory leak diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit usage scenarios in Chinese: 'SPA长时间运行内存增长排查时；路由切换后DOM节点未释放验证时；事件监听器泄漏排查时；上线前内存基线评估时'. This provides clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools, which would improve differentiation from siblings like browser_performance_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that check collects and evaluates metrics, trace records full trace and outputs HAR and structured data. However, it does not mention side effects (e.g., page reload, permissions) or details about how the tool interacts with the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence gives the overall purpose and version note, the second explains the mode parameter. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, nested objects, and no output schema, the description covers the core functionality and mode differentiation. It is complete enough for an agent to understand the main use cases, though it could briefly mention what the output of each mode looks like (e.g., budget evaluation result, HAR file).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 by explaining that the 'mode' parameter differentiates the two sub-modes, but otherwise the parameter descriptions in the schema are already detailed. The description does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a performance analysis tool with two distinct sub-modes (check/trace). It distinguishes itself by mentioning the merge of two previous tools (browser_performance_check/trace), helping differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes and their purposes: check for collecting metrics against budget, trace for full traces. It provides explicit context for usage but does not mention when not to use this tool or alternative tools (e.g., browser_network).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses auto-redaction of sensitive inputs, default redactSelectors, error conditions ('Browser not launched', 'Screenshot failed'), and the output format. It also explains the mode parameter maps to deprecated tools. Missing details on permissions or rate limits, but overall high transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes both English and Chinese sections, which introduces redundancy. The English part is concise (2 sentences), but the Chinese section, while structured, repeats and expands on the same information. This adds length beyond what is necessary for a single-language agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no required, schema coverage 100%, and no output schema, the description compensates by defining the output structure, error cases, and usage scenarios. It also explains the relationship to deprecated browser_screenshot_element. Minor omissions: the conditional requirement of selector when mode='element' is only in the Chinese section, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 defaults (name defaults to timestamp, redactSelectors defaults) and the redaction feature, but these are partially implied by the schema. The Chinese section provides additional context but does not significantly surpass the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Take a screenshot of the current page and save it to the MCP artifacts directory', providing a clear verb and resource. The Chinese section further specifies '对真实浏览器当前页面截图并保存为 PNG 文件', which distinguishes it from visual comparison tools like browser_visual_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section lists explicit when-to-use scenarios: verifying page rendering, recording bug evidence, capturing baselines for visual comparison, and documenting key steps. It also mentions that mode='element' is for element screenshots, guiding the user away from deprecated tools. However, it does not explicitly state when not to use or provide alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that each 'create' session has independent context/cookie/storage and that extensionPath forces headless=false. However, it does not disclose destructive effects (close deletes session), error handling, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct paragraph that covers purpose, modes, and key parameter interactions. However, it could be better structured (e.g., bullet points for modes) for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the modes adequately but does not describe the return value for the 'list' mode or any error scenarios. With 8 parameters and no output schema, more detail on expected outputs and errors would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value. It does clarify the relationship between sessionName/name and extensionPath/loadExtensionPath, and notes that extensionPath forces headless=false. This justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a browser session management tool, enumerates four sub-modes (list, create, switch, close), and mentions it merges previously separate tools. It distinguishes itself from siblings by being the consolidated session manager.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode via the mode parameter and mentions that this tool supersedes browser_session_create, browser_session_switch, browser_session_close, and browser_sessions. However, it doesn't explicitly state when not to use this tool in favor of other browser tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the recorded artifacts (screenshot, DOM snapshot, error summary) but omits behavioral traits like idempotency, side effects, or prerequisites (e.g., active browser session). Adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action verb and key artifacts. No wasted words; every part adds value. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 optional params, no output schema), the description covers core purpose. However, with no annotations and a list of 80+ siblings, more context on evidence storage or chain integration would be beneficial. Still not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are present. The tool description repeats the general idea ('screenshot, DOM, error summary') but adds no additional meaning beyond the schema's per-parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records evidence for verification steps, combining screenshot, DOM snapshot, and error summary. This contrasts with siblings like browser_screenshot (only screenshot) or browser_snapshot (only DOM), providing a unique composite purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use during verification steps ('record current verification step evidence') but does not explicitly state when to use or avoid alternatives. Given the sibling list, it is clear this is for documenting steps, but no exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It states the tool stops the session and returns data, which is sufficient for basic understanding. However, it does not disclose potential side effects (e.g., whether ongoing events are discarded) or behavior when no trace is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is largely complete. It covers the action and result. A minor missing detail is the prerequisite of an active trace, but this is implied. Overall, the agent can select and invoke the tool correctly with this information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). According to guidelines, baseline is 4. The description correctly does not add parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops a browser tracing session and returns collected data. It uses a specific verb ('stop') and identifies the resource ('browser tracing session'), making it unambiguous despite being in Chinese. The sibling tools include 'browser_trace_start' and 'browser_trace_chain', so this complements them clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies it should be used after starting a trace, but does not state prerequisites or when not to use it. The context is implied from the name and description, but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It explains the two modes and what they involve (e.g., health checks tool registration, schema, directory writability; self-test creates sessions and verifies capabilities). While it does not discuss side effects or prerequisites, for a diagnostic tool the transparency is good, though it could be more explicit about potential state modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering the tool's merged nature, the two modes, and their functions. No unnecessary words; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, all documented), the description provides a clear overview of purpose and modes. However, it lacks information about return values or how to interpret results, which would be useful for a diagnostic tool. Overall, it is sufficiently complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 for the mode parameter by explaining the two options, but does not elaborate on trace, headless, or sessionName beyond what the schema already provides. Thus, the description offers marginal added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an MCP self-diagnosis tool that merges two previous tools. It specifies exactly what each mode does: health checks tool registration, schema, directory writability, and checkpoint; self-test creates sessions and verifies basic capabilities. This distinguishes it from siblings like mcp_health_check and mcp_self_test, which are now merged.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the merge of mcp_health_check and mcp_self_test, implying this tool replaces them, but it does not provide explicit guidance on when to use one mode over the other. An AI agent would benefit from recommendations on selecting health vs self_test based on context, but the description leaves that implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the three modes and parameter conditions but does not disclose behavioral traits such as whether the tool is destructive, requires specific permissions, or has rate limits. For a validation/query tool, it likely is read-only, but that is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently conveys purpose, merge history, and mode behavior. It front-loads the core function and uses enumeration. While it could be more structured (e.g., bullet points), it is not verbose and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 or annotations, the description adequately covers input semantics and mode conditions. However, it does not describe the tool's return value or output format, which is important for an agent to understand what to expect after invocation. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds significant value beyond the schema by explaining the purpose of each mode in relation to parameters (e.g., mode=consistency for batch, mode=mcp_validate requires skillName). It clarifies the interplay between mode and parameter requirements, which the schema alone only hints at.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'Skill与MCP工具一致性校验与映射查询' and enumerates three distinct modes (consistency, mcp_validate, tools_map), each with a clear verb+resource. It effectively distinguishes from sibling tools by explicitly noting it merged the older separate tools (skill_consistency_check, skill_mcp_validate, skill_tools_map) as of 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (batch vs single validation vs mapping) and lists required parameters per mode. However, it does not explicitly state when not to use this tool or mention alternative tools (e.g., the deprecated sibling tools). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the tool's modes and their effects but does not mention idempotency, authorization requirements, rate limits, or side effects. The description implies read-like operations but lacks explicit behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph of moderate length. It front-loads the key fact (merged tool) and then systematically explains modes. It is efficient with no filler, though could be slightly more structured (e.g., bullet points for modes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, but it does not. Given the tool's complexity (11 parameters, 3 modes), the description covers usage context well but omits output format and behavior. The relationship with deprecated siblings is clarified, but completeness is partially lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The tool description adds value by explaining the meaning of the 'mode' parameter values and their equivalence to deprecated tools, and provides overall context for parameter usage (e.g., 'since' used in check mode). This enhances understanding beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'traceId 深度关联工具' and explicitly mentions it merges two previous tools (browser_trace_chain and trace_correlation_check), providing a distinct identity. It explains three sub-modes (view/check/chain) with specific use cases, effectively distinguishing itself from siblings like browser_trace_chain and trace_correlation_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly defines when to use each mode (e.g., 'view' for front-end/back-end debugging, 'check' for trace coverage verification, 'chain' for full link tracing). It implies this tool replaces the deprecated browser_trace_chain and trace_correlation_check, providing clear context. However, it does not explicitly state scenarios where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is a read-only decision maker and mentions it avoids wasting tokens, implying safe behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient paragraph that front-loads purpose and lists outputs. No extraneous content, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers inputs and outputs for a 2-param tool with no output schema, but lacks details on decision logic or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond providing context. It mentions the decision output but does not elaborate on parameter structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a fast stop-loss decision system based on initial page error state, distinguishing it from other validation tools among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (based on initial browser errors, within 1 second) but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does explain the sequential execution of steps, the alias relationship between action and type, and the mode-specific failure behavior. However, it does not mention potential side effects (e.g., state changes from clicks/types), authentication requirements, rate limits, or what happens to the browser session. Given the tool's mutating nature, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that covers the core purpose, version context, supported actions, alias relationships, and mode semantics. It is concise but could benefit from better structure (e.g., bullet points or separation of mode descriptions). The most critical information is front-loaded. Every sentence adds value, though the alias explanation could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the two modes and their behavior, but it does not describe the return value or output format. For chain mode, it mentions 'returns failure step details' but for flow mode it is implicit. The tool has no output schema, so the description should compensate. It also omits what happens on success, how errors are reported, and whether the tool produces any artifact (e.g., screenshots). Given the complexity (5 parameters, nested steps), the description is somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter's purpose is already documented. The description adds value by clarifying that step.action and step.type are aliases (both acceptable, at least one required) and that navigate also accepts the alias 'goto' (though 'goto' is not listed in the schema enum, which is a minor inconsistency). The mode parameter's semantics are reinforced. No additional parameter details beyond schema are provided, but the alias clarification is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a multi-step flow validation tool that executes browser operations like navigate/click/type/wait/eval/screenshot. It distinguishes between two modes (flow and chain) and mentions it merged the now-deprecated validation_chain. The verb 'validate' and resource 'flow' are specific, and the description differentiates it from sibling single-step tools like browser_click or browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes: flow (default, with configurable continueOnFailure) and chain (equivalent to deprecated validation_chain, stops on failure). This provides clear context on when to use each mode. However, it does not explicitly state when not to use this tool or mention alternative tools (e.g., for single-step actions use browser_* tools). The context is sufficient but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reports that the tool generates reports based on recent validation data and mentions a six-section structure, but does not disclose potential side effects (e.g., file overwrite on export) or detailed behavior beyond mode selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) while covering purpose, modes, and deprecation notice. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, modes, and relationship to the deprecated tool. However, it lacks details on the six-section structure, return format, or any file export specifics, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The tool description adds context by explaining mode sub-modes and the default view mode, but does not significantly enhance understanding beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates validation reports with two sub-modes (view and export), explicitly linking view to recent validation_check/run/matrix and export to the deprecated validation_report_export. This distinguishes it from siblings like validation_check and validation_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (view for Markdown/JSON report, export for HTML file) and notes that export replaces the deprecated sibling. However, it does not explicitly state when not to use this tool or compare with other report-like tools such as chain_score_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 explains both read-only (storage snapshots) and destructive operations (cookie clear/set), and mentions merging behavior. However, it could detail side effects of clearing cookies or snapshot limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and every sentence provides essential information without redundancy. It efficiently conveys the merged nature, dual modes, and primary use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, nested objects, dual modes) and absence of an output schema, the description is minimally adequate. It covers modes and actions but lacks details on return values, error handling, or browser context limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 summarizes the mode-based behavior but does not add significant new meaning beyond the schema descriptions. It provides general-purpose context but not parameter-specific enhancements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages browser state (Cookies & Web Storage), explicitly mentions merging legacy tools, and explains two modes with specific actions. It effectively distinguishes itself from sibling legacy tools like browser_cookies and browser_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's the preferred tool for debugging login state, tokens, and persistence issues, and explains when to use each mode. However, it lacks explicit exclusions or comparison with other tools like browser_snapshot or browser_har_export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions simulating real keyboard input but does not disclose details like whether it clears existing text, supports special keys, or handles events. It does list errors and output, but overall transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with English summary and Chinese details. It is concise but includes necessary usage guidance, error info, and example. The bilingual approach adds some redundancy but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers purpose, usage, parameters, errors, and output format. It is fairly complete for a two-parameter tool, though behavioral details could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds value by explaining each parameter's purpose (e.g., 'CSS selector, supports Playwright syntax') and providing an example. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Type text into a DOM element matched by CSS selector in a real browser, simulating real keyboard input.' This provides a specific verb, resource, and nuance, distinguishing it from siblings like browser_click or browser_aria_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'when to use' scenarios in Chinese (e.g., filling login forms, search boxes, textarea, testing input limits), providing clear context. It does not explicitly mention when not to use or alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the output structure, automatic issue detection, and errors for missing selectors or unlaunched browsers. Without annotations, it covers essential behavioral aspects, though it could mention that it is a read-only operation (no destructive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, details, output, parameters, errors, example). It is front-loaded with a concise English summary, but includes duplicate information in Chinese and English, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 optional parameters and no output schema, the description covers output shape, parameter details, errors, and provides an example. It is sufficient for an agent to use correctly, though the return format's properties (e.g., issues array) could be elaborated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 like example usage and defaults, but much of the parameter info is already in the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'three-level snapshot' combining screenshot, DOM snapshot, and CSS properties with automatic UI issue detection. This distinguishes it from sibling tools like browser_visual (just screenshot) and browser_snapshot (likely just DOM).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (e.g., debugging invisible elements, regression testing). It also mentions error conditions. However, it does not explicitly state when not to use or name alternative tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately discloses it is a read-only list operation. Lacks details on side effects or authentication, which are minimal for this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and examples, second details template contents. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, description fully covers what the agent needs: that it lists templates and what each contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description cannot add meaning. Baseline 4 is appropriate as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists built-in chain spec templates and provides examples. Distinguishes from sibling tools by focusing on template listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidelines, but implied usage for retrieving templates. No alternatives mentioned despite sibling chain tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: two independent parallel chains, cross-validation, auto-fix, and the goal to break self-verification. No annotations were provided, so the description carries the full burden, and it does so reasonably well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core concept and provides comprehensive detail in a single paragraph. It is concise given the complexity, though a structured list could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and lack of output schema, the description adequately explains the tool's process and what it achieves. It could mention the output format, but the cross-validation and auto-fix behavior is well-explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add significant meaning beyond the schema. It provides context for the overall process but does not elaborate on individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: dual-chain parallel exploration with specific chains (functional and technical), cross-validation, and auto-fix. It distinguishes itself from sibling tools by describing a complex multi-agent system that breaks the self-verification loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (thorough validation that breaks self-verification) but does not explicitly state when not to use or list alternatives. Given the context of sibling tools, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses specific checks including evidence directory writability (implying a write test), giving insight into potential side effects. However, it does not clarify if the tool is read-only or if it modifies any state permanently, such as creating evidence files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all health check categories. Every word earns its place, and it is front-loaded with the core verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is checked but does not describe the return value or expected outcome. For a tool with no output schema, this gap leaves the agent unsure what it will receive (e.g., a report, pass/fail, or structured data).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. According to the rubric, this receives a baseline of 4. The description adds no parameter information, which is acceptable since there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks MCP's health status, listing specific aspects like tool registration completeness, schema legality, evidence directory writability, and session/checkpoint state. This is a specific verb-resource combination and distinguishes it from sibling tools, none of which focus on health checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for health checking but provides no explicit guidance on when or when not to use this tool. It does not mention alternatives or contextual triggers, leaving the agent to infer usage from the tool's purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It specifies the output structure (ok, url, headers, missing, misconfigured, infoLeakage, score, recommendations) and error conditions (Request failed, Invalid url). Although it doesn't explicitly state if it makes HTTP requests, the nature of the tool implies a read-only check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, with a concise English sentence followed by a structured Chinese section detailing purpose, usage, output, parameters, and errors. It is front-loaded and well-organized, though slightly longer due to bilingual duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with no output schema, the description adequately covers input, output fields, and error conditions. However, it does not explain the scoring mechanism or recommendation logic, which could be useful for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'url'. The description repeats the parameter name and requirement (必填) and provides an example, but adds no new semantic information beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks HTTP security response headers for specific headers (CSP, X-Content-Type-Options, etc.) and detects information leakage. This distinguishes it from siblings like security_csp_analyze which focuses only on CSP, and other security scan tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section lists specific use cases (pre-deployment compliance, HTTPS/HSTS verification, clickjacking protection, info leakage). While it doesn't explicitly mention when not to use or name alternatives, the context provides clear guidance for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states basic performs a full browser health check (open URL, wait, assertions, screenshot, error count) and quick is low-token. Missing details on side effects (e.g., clearing errors, evidence saving) and whether it closes the browser session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two dense sentences. It front-loads the tool's name and version, then efficiently explains modes and alternatives. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and no annotations, the description covers the core modes and one special type but omits return values, error behavior, and prerequisites. It mentions 'evidence' but doesn't clarify its impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining the mode enum semantics, naming the deprecated quick tool, and describing the deploy_verify type. It also clarifies the basic mode steps, which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a single validation check with distinct sub-modes (basic/quick) and a deployment verification type. It explicitly states it merges validation_quick_run, distinguishing it from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use basic vs quick mode based on token cost and thoroughness, and mentions the deploy_verify alternative. However, it does not compare this tool to other validation or browser tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 output format { ok, condition, elapsed, timeout, timedOut }, error messages (timeout, no condition), and lists all wait conditions. It does not mention authentication or rate limits, but these are not relevant for a wait tool. Overall, good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an English intro and a Chinese section breaking down into usage, output, parameters, errors, and example. It is somewhat verbose due to duplication, but the organization helps readability. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 optional parameters and no output schema, the description is remarkably complete. It covers all wait conditions, output shape, error messages, and an example. There is no ambiguity about how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's parameter list is largely redundant but adds context like '配合 state 使用' and '当文本匹配多个元素时'. It also provides an example. However, it doesn't add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Wait for the browser to reach a specified condition' and lists all possible conditions (element visible/hidden/detached, text appears, URL contains, load state, fixed duration). It clearly distinguishes the tool's purpose from sibling browser action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section provides explicit when-to-use scenarios: after clicks waiting for loading, async requests, SPA routing, polling delays, animation completion. While it doesn't explicitly mention when not to use or alternatives, the guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint, which the description supports by mentioning a sandbox without backend permissions. It adds behavioral context like automatic upgrade prompting and the 6-stage process. No contradiction. It provides value beyond annotations, though could mention error handling or time estimates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the main purpose, lists stages succinctly, and ends with the upgrade note. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (all documented), no output schema, and safety annotations, the description covers the overall behavior well. It explains the 6 stages and the sandboxed execution. Missing details about output format are compensated by the lack of output schema. Adequate for a quick exploration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have descriptions in the input schema, achieving 100% coverage. The main description does not add significant meaning beyond the schema, such as clarifying the difference between 'url' and 'target' (both are target URLs). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: performing a 6-stage front-end shallow exploration on a target URL, listing specific stages. The name 'exploration_quick' and the description distinguish it from more specific sibling tools like browser_navigate or browser_visual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it operates in a pure browser sandbox without backend permissions and that it prompts for upgrades when high-value clues are found. It implies usage for surface-level exploration, but does not explicitly state when not to use it or compare with alternatives. This is adequate but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses automatic error checking per step, immediate termination on error, alias support for type/action, and the 5-step requirement. However, it does not explicitly state that operations like click and type modify page state (destructive hint), though this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, starting with the purpose and then detailing behavior. It could be slightly more streamlined but effectively communicates the key points without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested object (steps) and 6 parameters, the description provides adequate context for the input behavior but does not describe the output report format. Since there is no output schema, mentioning what the report contains (e.g., step results, errors, screenshots) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that step.type and step.action are aliases, clarifies the purpose of each step type, and notes the refusal behavior when required steps are missing. This helps the agent understand the step structure and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'complete functional chain closed-loop verification tool' that executes navigate/click/type/wait/validate steps in order, checks errors, and produces a report. It distinguishes itself from siblings like browser_chain and validation_flow by specifying the exact step types and error-checking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full 5-step chain validation and states it refuses execution if required steps are missing. However, it does not explicitly contrast with alternative tools like browser_step or validation_flow for simpler cases, or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It details the output structure, error conditions (browser not launched, invalid budget), and the scope (current page). It does not mention side effects, but performance collection is generally safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose due to bilingual content, with some redundancy (Chinese repeats English info). However, it is well-structured with an opening summary, then detailed Chinese bullets. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, nested objects, no output schema), the description covers purpose, usage, output format, parameter details, errors, and an example. This is complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by providing defaults for slowRequestMs and sessionName, a detailed breakdown of budgets fields, and an example. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it collects page performance metrics and evaluates against budgets, listing specific metric types (navigation, paint, resource, long task, CLS/LCP) and Core Web Vitals. This distinguishes it from sibling tools like browser_performance_trace or browser_lighthouse_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists use cases: pre-launch baseline, CWV compliance, slow request/long task localization, budget gate checks. While it doesn't state when not to use, the context is clear and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: random data generation, supported types, error messages for invalid selectors/field types/non-editable elements, and output structure. This exceeds typical transparency requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with separate sections for purpose, usage, output, parameters, errors, and an example. The Chinese section adds redundancy but does not detract significantly; overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all relevant aspects: purpose, parameters with details, errors, output format, and an example. Given no output schema, it compensates fully, making the tool's behavior and usage clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the options sub-object fields and providing context (e.g., domain for email). It clarifies parameter usage beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: auto-generating format-valid test data and filling inputs. It lists supported field types but does not explicitly differentiate from siblings like browser_form_fill, though the generation aspect implies distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific use cases (e.g., registration forms needing valid email/phone) in both English and Chinese, giving clear context for when to use. It lacks explicit exclusions or alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context: it scans (read-only implied), returns structured output, and depends on other tools for some categories. It discloses potential errors and partial results. Could be more explicit about non-destructive nature, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is split into English and Chinese sections. The English is concise; the Chinese adds structured details (use cases, output, parameters, errors). Well-organized but slightly verbose. Could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides output format, error handling, and dependency behavior. The single parameter is well-documented. Covers essential behavioral aspects for a simple scanner tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'url'. The description adds meaning by explaining it is the target URL, required, and provides an example. This adds value beyond the schema's property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an OWASP Top 10 security check on a URL, returning pass/warn/fail per category. It distinguishes from sibling security tools that focus on specific areas like CSP, headers, SQL injection, XSS, etc., by targeting the OWASP Top 10 categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists use cases: pre-launch risk assessment, compliance audits, security gate checks, periodic reviews. It also describes error handling and dependency behavior (e.g., missing header tools cause warn status). However, it does not explicitly exclude alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully describes behavior: injects 26 payloads, checks reflection, includes errors and output structure. Could explicitly state non-destructive nature, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual structure adds redundancy (English summary repeated in Chinese). Well-organized with sections (purpose, when-to-use, output, params, errors), but could be more concise by removing duplicate content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: covers payload count, detection method, full output shape, parameter details, error cases, and example. Sufficient for an agent to use correctly without needing other references.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'url' is documented in both schema and description. Description adds example and required flag, plus Chinese details. Schema coverage is 100%, so description adds marginal but useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'XSS vulnerability scanner' and specifies it injects 26 payload types into target URLs, detecting unescaped reflection. Among sibling tools like security_sql_injection_scan and security_csp_analyze, this one is uniquely identified for XSS scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Chinese section explicitly lists when to use: pre-launch input scanning, reflected XSS validation, template regression, OWASP A03 verification. Does not explicitly state when not to use, but context from siblings (e.g., security_sql_injection_scan) implies it's for XSS only. Good guidance without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions error conditions ('Browser not launched') and performance impact of large maxLinks, and describes output structure. It does not disclose side effects, but the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual with English summary and Chinese details, which is verbose but well-structured with sections for when to use, output, parameters, errors, and example. Some redundancy, but overall clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the exact return structure (object with ok, totalLinks, etc.) and covers errors, parameters, and usage scenarios. It is comprehensive for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: filter supports SPA button text, includeExternal default false, maxLinks default 100. It explains the purpose of each parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it extracts all navigation links and buttons, classifies them by type (nav, login, etc.), and returns counts and visibility info. It also notes SPA button discovery beyond <a> tags, distinguishing it from siblings like browser_find or browser_dom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'when to use' section in Chinese listing scenarios: understanding entry points, enumerating links before testing, verifying menu completeness, and SPA routing. While it lacks explicit exclusions or alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses visibility (visible by default), supported engines, output shape, and error conditions. However, it does not address session management (e.g., whether it closes previous sessions). Overall, it covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual with a structured Chinese section containing bullet points. While efficient, the bilingual nature adds some extra length. Every sentence contributes meaningful information, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a clear output shape, error examples, and a full usage example. The tool is simple (3 params) and the description covers entry, behavior, and outcomes comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by listing default values, providing a usage example, and clarifying error conditions. It also explains the headless parameter's visual verification use case, exceeding schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches a real browser and navigates to a URL, supporting multiple engines. This distinguishes it from sibling tools like browser_navigate (requiring existing session) or browser_session_create (no navigation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '何时使用' section lists specific use cases (new session, visual observation, engine switching, debugging). It does not explicitly state when not to use, but the context is clear. Lacks an explicit alternative mention but provides good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses supported keys/combos, that it presses on current page or focused element, and details the output structure (ok, key, selector, timestamp) and errors ('Key is required', 'element not found'). It does not mention whether it waits for action completion or handles modifiers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured: English summary followed by Chinese details. It is not overly long, but the Chinese section is a duplicate. The core English part is concise and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema in the input definition, the description provides the output structure, error conditions, and usage examples. For a keyboard press tool with 2 parameters, this covers all necessary information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining key parameter with common values (Enter, Escape, etc.) and specifying that selector is optional and focuses first. The Chinese section provides additional examples and error handling details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it presses a keyboard key or combo on the current page or focused element, distinguishing it from sibling tools like browser_click (clicking) and browser_type (typing text). It lists supported keys and combos, making the purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'when to use' scenarios in Chinese (form submission, modal close, dropdown navigation, shortcut testing). It implies not for typing text since browser_type exists, but lacks explicit 'when not to use' or direct comparison with browser_type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers key behaviors: returns path and dimensions, supports padding, and lists specific errors (element not found, not visible). It could mention scrolling into view, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an English summary and detailed Chinese sections, clearly separating purpose, usage, output, parameters, errors, and example. Bilingual content increases length but each section adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, when to use, output format (including fields), error conditions, parameters with defaults, and an example. Without an output schema, the explicit output format makes it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds an example JSON and clarifies defaults for 'name' and 'padding', providing modest additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes a screenshot of a specific page element via CSS selector, returning the artifact path and dimensions. This distinguishes it from sibling tools like `browser_screenshot` (full page) and `browser_visual` (comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'when to use' section listing four scenarios (component-level screenshots, before visual comparison, bug reports, multi-element documentation), providing clear context. However, it does not explicitly exclude alternatives or mention 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.
Behavior4/5
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 describes the tool's behavioral traits: it scans the current page without a baseline, returns a natural-language issue list, and lists error conditions ('Browser not launched', 'Invalid viewport'). It does not explicitly state non-modification or side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an English summary followed by Chinese details in bullet points. It is front-loaded with the core concept. While slightly long, every section adds value and the formatting aids readability. A more concise English-only version could be constructed, but the current structure is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 specifies the output format ({ ok, totalIssues, issues, summary }), issue categories, parameters with defaults, error messages, and an example. This provides complete contextual information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds significant extra meaning beyond the schema, including detailed parameter descriptions in Chinese, conditional logic (e.g., viewports only effective when includeResponsive=true), and an example invocation. This justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 no-baseline automated UI issue scan, listing specific types of problems it detects. The name and description directly convey the verb ('scan') and resource ('current page') and distinguish it from sibling tools like browser_visual_compare and browser_a11y_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'when to use' section covering UI walkthroughs, pre-deploy checks, responsive verification, and accessibility scanning. It provides clear usage context but does not explicitly mention when not to use or alternatives like browser_a11y_check for dedicated accessibility testing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the entire process (capture, compare, generate diff, return artifacts) and documents two error cases (missing baseline, selector not found). It does not mention potential side effects or performance impacts, but the behavioral outline is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with English first then Chinese. The bilingual approach adds length but both parts are necessary for the target audience. Every sentence adds value, though the English and Chinese sections overlap somewhat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description itemizes all return fields. It covers all 6 parameters, lists error conditions, and provides an example. This fully compensates for the missing output schema given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 extra semantics: name without extension, sessionName default, selector consistency requirement, and an example JSON. These additions justify a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it captures a PNG, compares against a baseline, generates a diff, and returns metrics. It uses specific verbs and resources, and the detailed explanation leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists usage scenarios (UI regression, multi-environment consistency, style adjustment detection, CI gates). It does not specify when not to use or mention alternatives, but the given contexts are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses important behaviors: it does not emit long screenshot descriptions, lists error conditions like missing screenshots and file not found. It adds context beyond the schema, though side effects or resource usage are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a bilingual section (English and Chinese) which adds redundancy and length. However, it is well-structured with clear sections for usage, output, parameters, errors, and an example. It earns its place by being comprehensive, but conciseness suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 optional parameters, no output schema, no annotations), the description is remarkably complete. It includes the return structure, error messages, parameter explanations, and an example, enabling an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter's purpose: baselinePath/actualPath for direct comparison, beforePath/afterPath as aliases, selector for element capture, threshold with default 0.01, and name for diff file naming. This provides rich meaning beyond the schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two screenshots or captures a current screenshot, returning a diff summary. It distinguishes itself from sibling tools like browser_screenshot and browser_visual_compare by focusing on diff comparison and not emitting long descriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit scenarios for use, such as comparing baseline vs actual, testing page states, element-level diff, and debugging visual_compare flow. It implies when not to use by stating it does not emit long descriptions, but lacks explicit alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses error handling ('element not found'), priority rules (selector over x/y), and output format with fields like ok, scrollX, scrollY, scrolledTo, timestamp. This adds significant behavioral context beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 clear headers (用途, 何时使用, 输出, 参数, 错误, 示例). It is front-loaded and every section adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters, no output schema, and complex scrolling behavior, the description covers output format, error conditions, parameter interactions, and usage examples, making it fully complete for an AI agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds value by explaining defaults (scrollIntoView default true when selector given), behavior options, and provides an example. This helps an agent understand parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls the page or to a specific element, supporting both scrollIntoView and pixel-based scrolling. This distinguishes it from sibling tools, as no other tool in the list has scrolling as primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: triggering lazy content, scrolling elements into view, testing infinite scroll, ensuring visibility before screenshots. It does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details output fields, error conditions (e.g., 'Not a select element', 'Option not found'), and provides an example. It does not mention side effects like triggering events, but for a selection tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with English summary followed by Chinese details, including sections for purpose, usage, output, parameters, errors, and example. It is front-loaded with the core action and every section adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 documents the output format and error behavior. Parameters are thoroughly explained, and an example is provided. For a selection tool, this is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaning by explaining that three optional parameters (value, label, index) represent different selection methods and implies exactly one should be used. It also clarifies errors for missing criteria, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects an option in a <select> dropdown by value, label text, or index. The verb 'select' and resource 'dropdown' are specific. It distinguishes from sibling browser tools like browser_click or browser_form_fill by focusing solely on dropdown selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists when to use: form dropdown selection, testing select linkage, filter criteria selection, and default value verification. This provides clear context, though it does not mention when not to use or alternative tools such as browser_form_fill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details output structure and error behavior (empty array on no active sessions). It implicitly indicates a read operation, but does not discuss potential side effects, permissions, or rate limits. Annotations are absent, so the description carries the burden, which it mostly satisfies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with English summary followed by Chinese details in bullet points. Generally concise, though some repetition between languages. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by specifying the return structure and error condition. Complete for a parameter-less listing tool, covering purpose, usage, output, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%). The description explicitly states '参数：无' (no parameters), confirming the absence of input. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all current browser sessions with specific details. It is distinct from siblings like browser_session_create or browser_session_close by being a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use scenarios in Chinese, such as before multi-session testing, checking activity, troubleshooting trace status, and debugging concurrent sessions. Also includes output and error case information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral traits: it captures a screenshot, compares to a baseline, auto-creates the baseline if missing, returns diff metrics and flags. It also lists error conditions (no match, multiple matches). It could mention if it modifies browser state, but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: an English summary followed by Chinese details in bullet points. It is front-loaded with the key purpose and output, and every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description fully covers purpose, usage, parameters, output structure (list of fields), errors, and an example. It leaves no significant gaps for an agent to understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds value: it states the default for maxDiffPixelRatio (0.01) and that sessionName defaults to the current active session. It also provides an example JSON, reinforcing parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a component-level visual diff, capturing a screenshot of a CSS-selected component and comparing it against a same-named baseline. The verb 'capture and compare' plus the resource 'component' is specific. It distinguishes from sibling tools like browser_visual (presumably full-page) and browser_visual_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists when to use: component library visual regression, independent component UI verification, multi-theme comparison, and incremental UI changes. It does not explicitly say when not to use, but the guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the output structure (ok, baselines, actuals, diffs, recentResults, total) and error behavior (empty arrays with ok=true). However, it does not explicitly state that the tool is read-only or has no side effects, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English part is a single sentence, and the Chinese part adds structured details. The information is front-loaded, but the bilingual nature may be slightly redundant for an English-speaking agent. Overall, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no output schema, and no annotations, the description adequately covers purpose, output format, error handling, and usage contexts. It is complete for an agent to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty object). The description explicitly states '参数：无' (parameters: none). Since there are no parameters to document, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists visual regression artifacts (baselines, actuals, diffs) and recent comparison results. This distinguishes it from sibling tools like browser_visual_compare or browser_visual_check which perform comparisons or checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists when to use: after visual regression tests to view history, before cleaning baselines, debugging visual_compare results, and report summaries. This provides clear context and implicitly states when not to use (e.g., when you need to perform a comparison).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description details the scanning process (20 payloads, DBMS detection), output format, and error handling. It does not mention authorization needs or potential side effects, but the behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an English summary followed by Chinese bullet points for key aspects (usage, output, parameters, errors, example). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is fairly complete. It covers purpose, when to use, parameter details, output shape, error cases, and an example. It could mention that it only scans query parameters (not POST bodies), but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The url parameter is described in both the schema and the description with examples and error conditions. The description adds context that query parameters are expected and provides a sample input, going beyond the schema's type and required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a SQL injection vulnerability scanner that injects 20 SQLi payloads and detects error leakage. It distinguishes from sibling tools like security_xss_scan and security_headers_check by naming the specific vulnerability type and technique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 scanning, suspicious query parameters, regression testing, OWASP A03 verification. It also mentions error cases (no injectable parameters, unreachable URL).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the full workflow: auto-clear errors, inject probes, trace, per-case browser_flow, assertion, investigation, HAR export, and evidence persistence. It also lists error conditions and handling of failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (bilingual) but well-structured with sections for purpose, usage, output, parameters, errors, and example. It is comprehensive but could be more concise by removing redundant Chinese translations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 9 parameters and orchestration of multiple steps. The description covers output structure, error conditions, and provides an example. Despite no output schema, the output format is explicitly documented. This is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 9 parameters described in schema). The description repeats and adds default values, as well as an example. This adds value beyond the schema, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a complete browser acceptance plan' and enumerates the steps. The verb-resource combination is specific and distinguishable from sibling tools, which are lower-level browser actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '何时使用' section in Chinese, explaining when to use the tool (multiple test cases, CI/CD, regression, end-to-end). While it provides good context, it 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 session creation/reuse, isolated context, extension loading, and lists output fields, parameters, and error conditions. It does not mention required permissions or potential side effects, but the behavior is well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with English summary, organized Chinese details, and clear sections for output, parameters, errors, and example. Each sentence is informative and not redundant. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and no output schema, the description covers behavior, inputs, outputs (listing return fields), errors (with example messages), and an example. For a creation tool, this provides sufficient context for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 grouping parameters, noting aliases, indicating required status, and providing an example. It also explains the effects of extensionPath and the forced headless=false. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or reuse a named browser session with isolated context', specifying the verb (create/reuse) and resource (browser session). It distinguishes from sibling tools by emphasizing isolated context and Chrome extension loading, which is unique among the many browser_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese '何时使用' section explicitly lists four use cases: multi-account/role testing, context isolation, extension loading, and session state verification. This provides clear when-to-use guidance and implicitly excludes other scenarios, though it does not name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description covers default full-page screenshot, auto-masking of sensitive inputs, output object structure, and error cases. No annotations exist, so this is good, but explicit side-effect statements (e.g., file creation) are implied rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The English part is concise, and the Chinese section is well-structured with bullet points. The bilingual nature adds length, but it is still efficient and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides a full output object, error scenarios, and usage guidelines. With 5 parameters and no annotations, it covers all needed context comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds extra context for each parameter (e.g., 'selector: CSS selector; if specified, only that element is captured') and provides an example invocation. This significantly enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a visual regression baseline PNG for the current page or a specific element' with defaults and auto-masking. This clearly distinguishes it from siblings like browser_visual_compare and browser_visual_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists when to use: first-time baseline, reset after UI upgrade, multi-viewport testing, component-level comparison. This provides clear guidance on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully compensates: it discloses isolated headless Chrome instance, no session interference, shutdown after audit, error messages (Audit failed, Lighthouse launch failed), and parameter behavior like throttling only recommended for mobile. This is comprehensive for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: English summary first, then Chinese details breaking into purpose, when-to-use, output format, parameters, errors, and example. Every sentence adds value, no redundancy, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 covers all necessary aspects: function, usage, output structure (scores, metrics, diagnostics, reportPath), parameter details, error handling, and example. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema: it clarifies throttling only useful for mobile, provides example JSON, explains categories as array of specific enum values, and defaults. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs a Google Lighthouse audit, returning specific scores and diagnostic advice. It uses a specific verb 'Run' and identifies the resource 'Lighthouse audit', distinguishing it from other browser tools that may focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit when-to-use scenarios (pre-release quality evaluation, multi-dimension scoring, regression monitoring) in both English and Chinese. It does not explicitly state when not to use or compare with sibling tools like browser_a11y_check, but the context implies it is for comprehensive audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the output structure (ok, url, title, etc.), error cases ('Browser not launched', incomplete snapshot), and implies read-only behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is in two parts (English then Chinese). The Chinese is redundant in purpose but adds usage guidelines and structure. Front-loaded well. Slightly verbose due to duplication, but still clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers output format, error scenarios, and usage context completely. It provides an example and lists return fields. No missing critical information for a snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description explicitly states '参数：无' (parameters: none). No additional semantic value needed beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a structured snapshot of the current page including URL, title, visible text, form fields, and buttons. It distinguishes from sibling tools like browser_screenshot (visual) and browser_dom (raw DOM) by focusing on structured data for AI targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly lists when to use: before interaction to understand page structure, to get clickable list before locating elements, to view fields before form filling, and to record page state at breakpoints. This provides clear context and implies when not to use (e.g., not for visual checks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details auto-detection of nav containers, fallback to full-page link scan, error checking per step, output structure, and timeout handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with English summary, Chinese details, and bullet points. While bilingual, it is efficient and covers all key aspects without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description includes output structure, error handling, parameter details, and fallback behavior. It is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds context beyond schema by explaining default values, behavior (e.g., includeSubMenus default true), and example usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: auto-traverse page navigation menus, clicking each item while checking errors. It distinguishes from siblings like browser_click (single click) and browser_navigate (navigation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios in Chinese (e.g., regression testing, health check, menu traversal verification, stability testing). It also describes fallback behavior and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully discloses behavior: it fetches a URL, parses the CSP header, detects unsafe directives, and returns an ok boolean, directives object, unsafeDirectives array, score, and recommendations. It also describes error cases: URL unreachable throws 'Request failed', missing CSP header returns score=0 with ok=true. This covers all behavioral traits beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections (purpose, usage, output, parameters, errors, example) with both English and Chinese. It is longer than necessary but structured well, and every part adds value. One sentence could be removed (the Chinese title line) without loss, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs complex CSP analysis with no output schema provided. The description fully covers input, output format, error conditions, and usage context, making it complete for an AI agent to invoke correctly. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'url' (type string, required, described in Chinese as 'target URL (required)'). The description adds an example JSON input and explains the parameter context, which adds some value beyond the schema description, justifying a 4 instead of baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Content-Security-Policy, parses directives, detects unsafe configurations (unsafe-inline, unsafe-eval, wildcard), and produces a security score. It uses a specific verb+resource format and distinguishes itself from sibling security tools like 'security_headers_check' and 'security_scan' by focusing exclusively on CSP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Chinese section explicitly provides usage scenarios: before CSP policy deployment, XSS protection verification, third-party script whitelist review, CSP report anomaly investigation. This gives clear when-to-use guidance and implies alternatives are not needed for this specialized task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ai-verify-mcp MCP server](https://glama.ai/mcp/servers/validpilot/ai-verify-mcp/badges/card.svg)](https://glama.ai/mcp/servers/validpilot/ai-verify-mcp)

Score Badge

Copy to your README.md:

[![ai-verify-mcp MCP server](https://glama.ai/mcp/servers/validpilot/ai-verify-mcp/badges/score.svg)](https://glama.ai/mcp/servers/validpilot/ai-verify-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/validpilot/ai-verify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server