playwright-browser-skill

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v2.1.0
Disambiguation2/5
Multiple tools have overlapping or unclear boundaries. For example, browser_fill, browser_type, and browser_keyboard_insert_text all handle text input; browser_click, browser_tap, browser_mouse_click, and browser_touchscreen_tap all perform clicks; and browser_get_text, browser_get_input_value, and browser_get_attribute all retrieve element data. An agent would struggle to pick the correct tool without deep context.
Naming Consistency5/5
All tools follow a consistent 'browser_verb_noun' pattern (e.g., browser_launch, browser_get_text, browser_click). Even more complex names like browser_scroll_into_view and browser_wait_for_selector maintain the prefix and verb-first structure. The naming is uniform and predictable throughout.
Tool Count1/5
101 tools is an extreme mismatch for the server's purpose. While browser automation naturally has many operations, this toolset includes highly granular and redundant actions (e.g., separate mouse_down, mouse_up, mouse_move, mouse_click, and mouse_wheel) that inflate the count beyond manageability. Typical MCP servers with 3-15 tools offer far better clarity.
Completeness4/5
The tool surface is remarkably comprehensive, covering the full browser automation lifecycle: launch, page navigation, element interactions, waiting, network interception, cookies, screenshots, performance metrics, and more. Minor gaps exist (e.g., no dedicated frame-switching tool, no direct way to read selected option text), but these can be worked around using browser_evaluate or browser_get_frames.
Average 2.3/5 across 95 of 101 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 6 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/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 only states 'get accessibility snapshot' and does not reveal output format, whether the operation is read-only, or any side effects. This is insufficient for an agent to predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and contains no wasted words, but this is under-specification rather than concise clarity. It offers zero explanatory content beyond the tool's name, so it fails as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single undocumented parameter, the description is wholly inadequate. The agent cannot determine what an accessibility snapshot contains, how the selector influences the result, or what the return value looks like.
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?
The schema defines one optional 'selector' parameter with no description, and schema description coverage is 0%. The tool description does not mention the selector at all, so the agent is left guessing what the parameter does and how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取无障碍快照' is simply the Chinese translation of the tool name 'browser_get_accessibility_snapshot', restating the name without adding any explanatory value. It fails to clarify what an accessibility snapshot is, what it includes, or how it benefits the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 any of the many sibling browser tools. There are no use cases, prerequisites, or exclusions mentioned, leaving the agent without decision-relevant information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that the tool handles browser dialogs (e.g., alert/confirm/prompt), what happens when promptText is provided, or any side effects. Essentially none of the behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single phrase that adds no information does not 'earn its place'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and no annotations. The description is insufficient to understand the tool's purpose, acceptable inputs, or behavior, which is a serious gap for any tool invocation.
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 nothing about the parameters. The action enum (accept/dismiss) and promptText are entirely unexplained, leaving the agent to infer their purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '处理对话框' merely restates the tool's name ('handle dialog') without specifying the action or resource context. It does not explain what handling a dialog involves (accept/dismiss), and fails to distinguish this tool from any other browser sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description gives no context about dialog types or conditions under which accept or dismiss should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention any side effects, permissions, what the tool modifies, or what happens when executed, leaving the agent completely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single tautological phrase does not earn efficiency credit because it conveys no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and only a cryptic parameter. The description contributes essentially nothing beyond restating the tool name, making the tool effectively undocumented and unusable without external knowledge.
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?
The single parameter 'time' is undocumented in the schema (0% coverage) and the description offers no explanation of its meaning, format, or allowed values. The agent has no basis to infer even basic semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '安装时钟控制' is a direct translation of the tool name ('install clock control'), providing no additional functional clarity. It does not specify a clear verb+resource action or distinguish itself from sibling clock-related tools like browser_set_system_time, browser_pause_clock, or browser_resume_clock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites exist, or which alternatives might be more appropriate. The description is completely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, but it reveals nothing about how mocking works, whether it mutates state, persists, or affects other browser operations. There is zero behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. Every word is wasted because it merely echoes the tool name without providing useful structure or content. There is no front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters (one an object) and no output schema, the description provides no guidance on return values, side effects, or expected usage. The description is entirely inadequate for an agent to safely or effectively invoke this tool.
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 does not mention urlPattern or response parameters. The fallback to schema is empty, so the agent cannot infer what values to provide or how they behave. The description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '模拟响应' is a direct translation of the tool name ('mock response'), providing no additional meaning. It does not state what the tool does, what resource it acts on, or how it differs from 83 browser sibling tools. This is a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no context for its typical use case, and no exclusions or prerequisites. An agent has no basis for selecting this tool over siblings like browser_intercept_requests or browser_wait_for_response.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details. It does not disclose what effect the wheel action has, whether it scrolls horizontally/vertically, or any side effects. The burden falls entirely on the description, which is unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two Chinese characters), but this is under-specification rather than conciseness. It is not a complete sentence and conveys no meaningful information. It does not earn its place because it adds no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no output schema, the description must clarify the tool's behavior and parameters. It does neither. The tool is a browser mouse wheel operation amidst many similar browser interaction tools, making the lack of context especially problematic.
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?
The input schema has two parameters (deltaX, deltaY) with 0% schema description coverage. The description does not explain what these deltas mean, how they relate to the wheel action, or expected ranges. It fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is simply '鼠标滚轮' (mouse wheel), a noun phrase that does not state any action or function. It fails to convey that this tool likely scrolls the mouse wheel, and it does not distinguish itself from sibling tools like browser_mouse_move or browser_scroll_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent to guess at the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals nothing about how the tool behaves. It does not mention whether the script tag executes, what happens if both url and content are provided, or any side effects on the page.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than efficient conciseness. It merely repeats the tool's name without earning its place by adding any useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 parameters, potential injection behavior) and the absence of annotations and output schema, the description is wholly inadequate. It lacks essential context about how url and content are used, whether scripts are executed immediately, and any security considerations.
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?
The input schema has zero description coverage, and the description does not explain the meaning or usage of the 'url' and 'content' parameters. The parameter names are self-explanatory to some degree, but the description adds no semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '添加脚本标签' translates directly to 'Add script tag', which merely restates the tool's name in another language. It provides no additional detail about what the tool actually does beyond the name itself, making it a tautology rather than a meaningful explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool or how it relates to alternatives like browser_add_style_tag. There is no mention of use cases, prerequisites, or conditions under which this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to explain side effects, whether the checkbox must be visible, error handling, or if it waits for actionability. The minimal description gives no insight into the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It lacks essential details, and a single phrase does not adequately explain the tool's function or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the description is incomplete. It provides no information about return values, side effects, or interaction with the browser context, making it insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'selector' with no description, and schema description coverage is 0%. The description does not mention the selector or how it is used to locate the checkbox, leaving the parameter's purpose completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '勾选复选框' translates to 'check the checkbox', which provides a specific action and object but does not differentiate from sibling tools like browser_click or browser_tap. It essentially restates the tool's name with minimal elaboration, lacking context about the page or element target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 browser_uncheck, browser_click, or browser_tap. There is no mention of prerequisites, conditions, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to mention side effects such as triggering a browser download, whether it waits for the download to complete, any permission requirements, or how it interacts with the page. The description is a bare label with no operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be seen as concise, but it is under-specified to the point of being a restatement. There is no front-loaded useful detail, and it does not earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent function (triggering a file download via a DOM selector), the description provides no information about return values, download behavior, waiting logic, or error conditions. With no output schema and no annotations, the description is wholly inadequate for an agent to invoke this tool correctly.
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?
The schema has a single parameter 'triggerSelector' with no description, and schema description coverage is 0%. The description does not explain what the selector refers to or how it is used to initiate a download, leaving the agent to guess the parameter's semantics entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '下载文件' (Download file) is essentially a restatement of the tool name, providing no additional detail about what file is downloaded or how. It does not differentiate from sibling tools like browser_upload_file beyond the obvious inverse action, and the 'triggerSelector' parameter suggests it triggers a download via a UI element, which is not mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not explain that it requires a selector to trigger a download, nor does it mention any prerequisites or scenarios where it should be preferred over other browser actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention that a drag-and-drop involves source and target selectors, what events are triggered, or any side effects. The one-word description offers no insights beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is an under-specified fragment rather than a concise explanation. It provides zero information beyond the tool name and is not adequately structured to inform the agent in any meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complete lack of annotations, output schema, and any parameter explanation, this description is entirely inadequate. An agent would have no way to understand how to invoke browser_drag correctly, what the two selectors are for, or what outcome to expect.
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?
The input schema defines sourceSelector and targetSelector as required strings, but the description does not explain their purpose or how they relate to the drag operation. Since schema description coverage is 0%, the description should compensate, but it fails to add any meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '拖拽元素' simply translates to 'drag element', which is a tautology of the tool name 'browser_drag'. It does not specify that this is a drag-and-drop operation between source and target selectors, nor does it distinguish it from other browser interaction tools like browser_mouse_move or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use browser_drag versus other browser_* tools. The description provides no context about the operation's purpose or when it should be preferred, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It does not mention side effects, whether it mutates state, what 'fast forward' actually does (e.g., advances a clock, speeds up animations), or any safety implications. It is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The sole sentence adds no valuable information beyond the tool name and thus does not 'earn its place'. The lack of structure or elaboration makes it insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and one poorly documented parameter, the description should provide comprehensive context. It provides none, leaving the tool's behavior, expected inputs, and return values completely unclear. It is inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'time' is required but the schema description coverage is 0%. The description does not explain what 'time' represents, its units, domain, or effect. Since the description does not compensate for the missing schema documentation, the agent cannot understand how to set this parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '快进时间' simply restates the tool's name ('fast forward time') without clarifying what specific action is performed or what resource is affected. It does not distinguish this tool from sibling browser_go_forward, which is about history navigation, nor does it explain the intended time-related operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or how it differs from alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without any basis for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a two-character description, the tool's behavior is completely undisclosed. The description does not explain any side effects, what 'focus' does in the browser context, or whether it requires element visibility or other conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks any useful structure or elaboration, offering only a tautological phrase that adds no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description still fails to cover essential context: what focusing accomplishes, when to invoke it, or how the selector should be formatted. With dozens of sibling tools, this lack of context makes correct selection and invocation highly ambiguous.
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 provides no additional meaning for the 'selector' parameter. The parameter name alone is insufficient, as the description does not clarify the expected format (e.g., CSS selector) or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '聚焦元素' translates to 'Focus element', which directly restates the tool name 'browser_focus' without adding scope or distinguishing details. It specifies a verb and resource but offers no context about what focusing entails or how it differs from similar tools like browser_click or browser_hover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent entirely without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It discloses only that the tool finds an element by label, omitting critical behaviors: whether it returns a single element or waits for multiple, how 'exact' affects matching, error handling when no element is found, or whether it performs an implicit wait. The description is behaviorally opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is superficially concise, but it is under-specified. It contains no front-loaded meaningful content beyond the name's translation. The lack of essential information makes it more an abridgement than a concise, well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex domain (browser automation with many locator strategies), no annotations, and no output schema, the description is grossly incomplete. It fails to cover return types, selector semantics, parameter effects, or edge cases. It provides barely enough information to infer the tool's basic purpose, let alone use it correctly.
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 does not mention the 'text' or 'exact' parameters or explain their roles. It adds no value beyond the schema's bare parameter names. The description should compensate for the missing parameter documentation, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '通过标签查找元素' (find element by label) essentially restates the tool name 'browser_get_by_label'. It provides no additional specificity about what 'label' means, how it differs from sibling locator tools, or what 'get' implies (returning an element handle). This is a tautology rather than a clarifying statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 instead of alternatives like browser_get_by_text, browser_get_by_placeholder, or browser_get_by_title. There is no mention of label semantics, exact matching behavior, or fallback options. The agent receives no decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool's function and gives no details about whether the operation is read-only, what the logs contain, if it clears logs, or any side effects. This is a complete lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but this is under-specification rather than conciseness. It provides no structural value, no front-loaded key information, and lacks any sentences that earn their place beyond repeating the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is the only source of context. It fails to explain what the return value looks like, how the limit parameter behaves, or how this tool fits into the broader browser automation context. A getter tool that is part of a large sibling set needs more contextual scaffolding, and it has none.
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?
The schema has one optional parameter (limit) with 0% description coverage. The tool description does not mention this parameter at all, adding no meaning beyond the schema's bare type definition. It fails to explain the purpose, format, or effect of 'limit'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取控制台日志' is a direct translation of the tool name 'browser_get_console_logs'. It restates the name without adding any specificity about the resource, scope, or behavior, and does not distinguish it from sibling log-related tools like browser_get_request_logs or browser_get_response_logs.
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. There is no mention of context, prerequisites, or exclusions, leaving the agent without any information about which log retrieval tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only says 'press key' and does not mention what happens when pressing, whether it triggers events, requires focus, or has side effects. This is entirely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is severely under-specified. A single word '按键' does not provide enough context to be considered appropriately concise; it omits critical information and is not front-loaded with useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description must explain context, return behavior, and usage. It does none of this, making it completely inadequate for an 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.
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 meaning to the parameters 'key' and 'selector'. It does not explain what format 'key' should be (e.g., 'Enter', 'a') or what 'selector' targets. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按键' translates to 'press key', which does convey a verb and resource but is extremely vague. It does not specify what is pressed (keyboard key vs mouse) or how this tool differs from siblings like browser_keyboard_down, browser_type, or browser_click. The purpose is minimally discernible but lacks necessary details for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the many sibling tools that also involve keyboard or mouse actions. There is no mention of context, alternatives, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'uncheck' without revealing any behavioral traits such as whether it waits for the element, what happens if the element is already unchecked, or whether it throws errors on missing elements. This is completely opaque for a browser interaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three characters) but this is under-specification rather than effective conciseness. It does not earn its place because it adds no information beyond the tool name. A concise but informative sentence like 'Uncheck a checkbox or radio button identified by CSS selector' would be appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description still needs to explain the behavior, the selector's purpose, and expected outcomes. This description provides none of that, leaving the agent without enough information to invoke the tool correctly or handle errors.
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?
The input schema has one required 'selector' parameter with no description (schema coverage 0%). The tool description does not explain what the selector selects or the expected format (e.g., CSS selector). The parameter semantics are entirely left to the parameter name 'selector', which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '取消勾选' translates to 'Uncheck', which is a direct restatement of the tool name 'browser_uncheck'. It simply repeats the action without specifying the resource (e.g., checkbox/radio button) or the context, failing to add any clarity beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_check, nor any mention of prerequisites, target element types, or conditions that must be met. The description provides zero usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only says 'upload file'. It does not mention that a selector must point to a file input, whether the filePath can be an array, or any side effects. The transparency is critically insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of a single vague phrase that fails to earn its place by conveying necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal description, no annotations, and no output schema, the tool is severely underdocumented. The agent cannot infer return values, error conditions, prerequisites, or how the tool integrates with browser workflows.
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 provides no explanation of 'selector' or 'filePath'. The parameter names are somewhat self-explanatory, but the description adds no semantic value, leaving the agent to guess how these parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '上传文件' (upload file) directly restates the tool name 'browser_upload_file' without adding specificity. It does not describe what kind of file, where it is uploaded, or how it relates to page elements, making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as browser_download_file or browser_fill. The description lacks any contextual or conditional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure, but it only states the action itself. It does not reveal whether the wait blocks, what occurs on timeout, return values, or side effects, providing no insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this reflects under-specification rather than effective conciseness. It consists of a single vague phrase that does not earn its place by adding meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is still incomplete. It lacks context about browser state, return type, error conditions, or relationship to other wait functions, and with no output schema or annotations, this is totally inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'timeout' with no description, and schema coverage is 0%. The description only implies a duration without specifying units, format, or constraints, so it fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '等待指定时间' translates to 'wait for the specified time,' which essentially restates the tool name (browser_wait_for_timeout). It provides no additional scope or differentiation from sibling wait tools like wait_for_selector or wait_for_url, making it tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention context, exclusions, or relationships with other wait operations, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only says 'Get LocalStorage' and does not mention return format, error behavior (e.g., missing key), side effects, or any nuances. This is a significant gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. It provides no useful information beyond the tool name, so it fails to earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no annotations and no output schema, the description still needs to explain basic semantics. 'Get LocalStorage' leaves the agent guessing about the key parameter, return value, and behavior when the key is absent. It is grossly inadequate.
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?
The input schema has a single 'key' parameter with no description, and the description does not explain what 'key' refers to or how it maps to LocalStorage entries. With schema description coverage at 0%, the description must compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取LocalStorage' directly translates to 'Get LocalStorage', which is essentially a restatement of the tool name. It does not clarify whether it retrieves a specific key or all entries, nor does it differentiate from sibling tools beyond the inherent 'get' semantics.
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?
There is no guidance on when to use this tool versus alternatives like browser_set_local_storage or browser_clear_local_storage. The name implies a read operation, but the description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose whether logs are cleared after retrieval, whether the operation is read-only, how logs are ordered, or what the return payload looks like. The description offers zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short, it is under-specified rather than concise. The single phrase restates the tool name and provides no useful details, so it does not 'earn its place' in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being simple (one parameter, no output schema), the description is critically incomplete. It lacks any explanation of behavior, parameter semantics, or relationship to other log-related tools. An agent cannot determine how to invoke it correctly or interpret results from this description alone.
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?
The schema has one parameter 'limit' with no description, and schema description coverage is 0%. The description does not mention or explain the 'limit' parameter, nor does it compensate for the schema gap. The agent receives no semantic information about the parameter's meaning or effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取响应日志' is a direct Chinese translation of the tool name 'browser_get_response_logs', essentially restating the name without adding any new information about scope, behavior, or differentiation from sibling tools like browser_get_request_logs. It is tautological rather than explanatory.
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_get_request_logs or browser_get_console_logs. No context, preconditions, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The description merely says 'grant permissions' without explaining side effects, whether the grant is persistent, what permissions are valid, or the role of the origin parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It consists of a single phrase that conveys no useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and only a minimal schema, the description must provide more context. A single-word description is wholly inadequate for an agent to understand 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the meaning of 'origin' or 'permissions'. It fails to clarify that origin is optional while permissions is required, and does not list accepted permission values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '授予权限' is a direct translation of the tool name 'grant_permissions', making it a tautology. It provides no specific verb-object distinction or differentiation from sibling tools like browser_clear_permissions.
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 prerequisites, typical use cases, or that browser_clear_permissions is the inverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral aspects. It only says 'mouse hover' without explaining what happens: whether it moves to the element center, triggers hover effects, requires visibility, or what occurs if the selector matches nothing. No side effects or limitations are mentioned, leaving the agent entirely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single word, which is under-specification rather than conciseness. While it is short, it does not earn its place because it communicates no more than the tool name itself. It lacks the structural elements (usage, parameters, examples) needed to be minimally viable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description should at least explain what the parameter is and how the hover action is performed. This description provides none of that context, making it impossible for an agent to use the tool correctly without external knowledge. It is completely inadequate.
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?
The schema lists a single parameter 'selector' with no description, and the tool description provides zero explanation of what this selector should represent (CSS selector, XPath, etc.). With schema description coverage at 0%, the description fails to compensate by adding any meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '鼠标悬停' (mouse hover) essentially restates the tool name without adding specificity. It fails to distinguish what this tool does differently from sibling tools like browser_mouse_move or browser_hover itself. The verb is clear but the resource and scope are undefined.
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 given on when to use this tool versus alternatives such as browser_mouse_move or browser_click. There is no mention of prerequisites, typical use cases, or exclusions. The description provides no context to help an agent decide between hovering and other mouse actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It fails to mention that restoring state likely overwrites current storage, requires a previously captured state, or has other side effects. The description is behaviorally opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but this is under-specification rather than conciseness. It omits essential information that would make the tool usable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely side effects, a parameter, and no annotations/output schema, the description is severely incomplete. It should explain what 'restore' means, how to obtain a valid state, and what happens to current browser state.
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?
The schema lists a required 'state' object parameter with no description. The tool description does not compensate; schema coverage is 0% and the description gives no hint about the expected structure or contents of the state object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '恢复存储状态' (restore storage state) is a direct translation of the tool name, providing no additional specificity. It does not distinguish this tool from siblings like browser_storage_state or browser_set_local_storage, nor does it clarify what 'storage state' includes (cookies, localStorage, etc.).
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?
There is no guidance on when to use this tool versus alternatives such as browser_set_local_storage or browser_storage_state. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'set geolocation' without explaining that this overrides the browser's geolocation for subsequent page interactions, whether it persists, or if any permissions are required. The description is purely nominal and fails to disclose any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be considered concise, but it is under-specified. The single phrase '设置地理位置' doesn't earn its place because it merely repeats the tool name in another language. It lacks any structural breakdown or coverage of key aspects like parameters, side effects, or use cases, making it more an omission than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and no annotations. The description is expected to compensate for the lack of structured metadata, but it provides none. There is no mention of how the geolocation is applied, what accuracy means, or how this interacts with the browser's state. The description is completely inadequate for an agent to understand the tool's full context.
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?
The input schema shows three parameters (latitude, longitude, accuracy) with no descriptions, and schema description coverage is 0%. The description does not mention any of these parameters, their meaning, or the expected format (e.g., decimal degrees). Since the schema is uninformative and the description does not compensate, the agent has no semantic guidance for filling the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置地理位置' is a direct translation of the tool name ('set geolocation') and provides no additional information about the tool's purpose. It restates the name rather than elaborating on what setting geolocation entails or how it differs from the sibling tool browser_clear_geolocation. This is a tautology at the definition level.
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, under what circumstances, or how it relates to alternatives such as browser_clear_geolocation or browser_emulate_media. There is no context about prerequisites or side effects, leaving the agent without any basis for selection among related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It fails to disclose what permissions are cleared, whether it clears all permissions or a subset, whether it affects the current page or the entire browser session, or any side effects. The word 'clear' implies mutation, but no specifics are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It consists of just two Chinese characters that add no value beyond the tool name. It is not appropriately sized because it omits essential information that would help an agent understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should fully explain the tool's behavior. 'Clear permissions' is a vague phrase that leaves the agent unsure about scope, side effects, and relationship to other permission-related tools. This is completely inadequate for a tool that could have significant 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?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed because there are no parameters to document. The empty schema fully covers the parameter space, so no gap exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '清除权限' is a direct Chinese translation of the tool name 'browser_clear_permissions', making it a tautology. It restates the name without providing any additional specificity about what 'permissions' means in this context. It does not distinguish itself from sibling tools like browser_clear_geolocation or browser_clear_cookies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention the related browser_grant_permissions sibling or explain under what circumstances clearing permissions is appropriate. There is no hint of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only repeats the basic action and does not disclose behavior such as timeout handling, polling, error conditions, or what happens when the response is not found. This is a significant gap for a wait operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this under-specification is not effective conciseness. It provides almost no value beyond the tool name and fails to convey essential information about the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With many sibling wait tools and no annotations or output schema, the description is far too thin. It does not explain the tool's role in the browser automation workflow or how it differs from similar tools, leaving the agent without enough context to use it reliably.
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 does not explain the parameters 'urlPattern' or 'timeout'. The agent must infer their meanings from names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '等待网络响应' ('Wait for network response') names a verb and resource, so it is not a tautology. However, it lacks specificity about what constitutes a 'response' (e.g., HTTP response matching a URL pattern) and does not differentiate from the sibling tool browser_wait_for_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 or how it differs from the many other wait-for tools (e.g., browser_wait_for_selector, browser_wait_for_request, browser_wait_for_url). The description gives no context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention what the tool returns (e.g., boolean), whether it waits for the checkbox to exist, or any side effects. The phrase 'check state' is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two characters in Chinese), which is under-specification rather than conciseness. It does not earn its place by adding any useful information beyond the tool name.
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 is simple (one param, no output schema), but the description still fails to provide essential context such as return type or typical usage. It is incomplete even for a basic state-check tool.
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?
The schema has one parameter 'selector' with no description, and the tool description does not explain what 'selector' means or how it should be formatted. With 0% schema coverage and no compensatory explanation in the description, the parameter semantics are completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '检查复选框状态' (check checkbox state) directly restates the tool name 'browser_is_checked' without adding specificity about what 'state' means (e.g., checked/unchecked). It provides a verb and resource but does not distinguish this tool from siblings like browser_is_visible or browser_is_enabled.
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 given on when to use this tool versus alternatives. There is no mention of how it relates to browser_check, browser_uncheck, or other state-query tools. The description implies a state check but provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. '鼠标点击坐标' says nothing about which mouse button is used, whether the move is instant, what happens with invalid coordinates, or any return value. It is almost entirely silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which might seem concise but is actually under-specification. It omits critical information and does not earn its place as a useful description; it is too terse to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a visible user interaction and has no annotations or output schema, the description is severely incomplete. It fails to explain the action, parameters, side effects, or interaction with other browser tools, making it inadequate for an AI agent to use reliably.
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?
The input schema has two number parameters with 0% schema description coverage. The description merely labels them as 'coordinates' without explaining the coordinate system (viewport vs page), units, or how to determine the correct values. It adds only minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '鼠标点击坐标' (mouse click coordinates) is a noun fragment that implies clicking at a coordinate but does not explicitly state the action. It does not distinguish the tool from siblings like browser_click or browser_mouse_down/up, which have different semantics.
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?
There is no guidance about when to use this tool vs alternatives such as browser_click for element clicks or browser_mouse_move for hovering. The description provides no context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The phrase '填写表单' merely restates the tool name and does not reveal behaviors like whether it replaces existing values, triggers events, or works on hidden elements. This is a critical gap for an interaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely short (four Chinese characters), it is under-specification rather than conciseness. It omits necessary details and does not earn its place with substantive content. A concise description should still convey key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no annotations, and no output schema, the description needed to explain behavior and parameters. Instead, it provides only a generic verb phrase, leaving the tool's actual operation and usage completely ambiguous. It is inadequate even for a simple tool.
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?
The input schema has two required strings (selector, value) with zero description coverage. The description does not explain what the selector refers to (e.g., CSS selector, XPath) or what value means in context. It adds no meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '填写表单' translates to 'fill out form', which provides a general verb+resource but is vague. It doesn't specify that it sets a value for a specific element via selector, nor does it differentiate from sibling tools like browser_type or browser_select which also interact with form elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It simply states 'fill out form' with no context, exclusions, or mention of sibling tools. There is no information about prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Generate PDF' without disclosing any behavioral details such as side effects, outcome, output location, or dependencies on the current page state. The description carries the full burden and fails to expose any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase with no elaboration does not serve the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, no output schema, and 0% schema coverage, this description is completely inadequate. It lacks any context about return values, effects, or proper invocation, making it nearly impossible 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the tool description does not explain any of the three parameters (path, format, printBackground). The parameter names offer some hint, but the description adds no meaning beyond the raw schema, leaving the agent without crucial semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '生成PDF' clearly indicates the tool generates a PDF, which is a specific action. However, it does not specify the resource or context (e.g., current page) or differentiate it from sibling tools like browser_screenshot or browser_emulate_media, so it lacks full clarity.
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 among the many browser_* siblings. There is no mention of prerequisites, typical scenarios, or conditions where another tool would be preferable.
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 the full burden. It discloses the key behavior of character-by-character typing, but lacks any context about whether existing text is replaced, how the delay parameter works, or whether the element is focused first. This is minimal 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it under-specifies the tool. It is not a sentence and lacks structured content. This is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain expected behavior, return values, error conditions, or any usage context. This is inadequate 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description '逐字符输入' provides no meaning for the parameters 'selector', 'text', or 'delay'. The schema itself has bare types with no docstrings, leaving parameters completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '逐字符输入' translates to 'type character by character', which clearly indicates a typing operation. However, it does not explicitly state the target resource (e.g., an element identified by selector), and it does not distinguish from sibling tools like browser_fill or browser_press. The purpose is somewhat clear but under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios (e.g., when you need to simulate typing with delays) or exclusions. Sibling tools like browser_fill and browser_press exist, but no comparison or recommendation 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?
With no annotations provided, the description is the sole source of behavioral disclosure. It only states that the tool waits for a network request but does not explain timeout behavior, resolution conditions, return value, or what happens if no matching request occurs. This lack of detail is a significant gap for a wait tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is technically concise, but it is under-specified rather than appropriately concise. It offers no value beyond the tool's name and does not earn its place as a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter documentation, the description is severely incomplete. It does not explain the tool's behavior, parameters, or use cases, making it inadequate for an agent to use effectively. A minimally complete description would need to cover URL pattern matching semantics and timeout behavior.
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?
The input schema has two parameters (urlPattern and timeout) with no descriptions, and the description provides no explanation of either parameter. Since schema description coverage is 0%, the description fails to compensate, leaving the agent with insufficient information to correctly construct the required urlPattern or set an appropriate timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '等待网络请求' literally translates to 'wait for network request', which is a direct restatement of the tool name 'browser_wait_for_request' in Chinese. It does not add any new information or differentiate the tool from siblings like browser_wait_for_response or browser_wait_for_url, making it effectively a tautology.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusion scenarios, leaving the agent without clear direction on selecting it over other wait-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers no behavioral details beyond the verb. It does not disclose what 'blocking' entails (e.g., permanent cancellation, matching rules, reversibility, side effects on navigation). The description fails to convey any operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two characters), but this is under-specification rather than conciseness. It lacks any structural detail, such as parameter explanation or usage context, so the brevity is not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one complex parameter, no annotations, no output schema, and limited sibling differentiation, the description is grossly inadequate. An agent would have to guess the behavior and parameter format, risking incorrect invocation.
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?
The schema has one parameter 'patterns' with no description, and the tool description adds no meaning. It is unclear whether patterns are URL globs, regex, or exact strings. With 0% schema coverage, this is a critical gap.
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 '拦截请求' (block requests) names a specific action and resource, making the core purpose clear. However, it does not distinguish this from sibling tools like browser_mock_response or browser_wait_for_request, which could overlap in intent. The brevity makes it unambiguous but not differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description gives no context about typical use cases, prerequisites, or scenarios where blocking requests is appropriate. Sibling tools with related functionality (e.g., mock_response) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavior. It says only 'go to next page' and does not disclose what happens when there is no forward history, whether navigation is synchronous, how it interacts with browser back/forward stack, or any potential side effects. This is minimal even for a simple navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single phrase adds no value beyond the tool name and leaves out critical operational context. A concise description should be informative, not just a translation.
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?
For a tool with no annotations, no output schema, and no parameters, the description still needs to convey the operation's meaning and nuances. It fails to mention history-based navigation, limitations, or related tools. The description is essentially a label and not a complete explanation of the tool's context.
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 baseline score is 4. There is nothing to explain about parameters; the description's lack of parameter information is not a deficiency because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '前进到下一页' is a direct translation of the tool name 'browser_go_forward' (go to next page). It restates the name in another language without adding any clarifying detail, making it essentially a tautology. It does distinguish from go_back by implying forward navigation, but that inference comes entirely from the name, not from the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_go_back, browser_goto, or browser_reload. No context, prerequisites, or example scenarios are provided. The description consists only of a phrase and gives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It merely states the action without explaining what resuming the clock does, any side effects, or whether it affects page timers or other time-related features.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, consisting of a single phrase. While brief, it is under-specified rather than concise, as it omits essential context and does not earn its place as a useful explanation.
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 simple structure (no parameters, no output schema), the description still fails to provide adequate context. It does not explain the purpose relative to sibling clock tools, the expected state of the browser, or any behavioral consequences.
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?
This tool has zero parameters, and the schema coverage is 100% vacuously. The description adds no parameter information, but with no parameters to document, the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '恢复时钟' is a direct Chinese translation of the tool name 'browser_resume_clock', restating it without adding any distinguishing information. It does not clarify what 'resume clock' means in the browser context or how it differs from sibling tools like browser_pause_clock or browser_fast_forward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a paused clock, or typical scenarios, leaving the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description merely states the action without any detail about return format, scope, side effects (none expected for a getter), or whether it requires a browser context. This is a total lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single phrase), but this is under-specification rather than conciseness. The phrase '获取Cookie' does not earn its place because it merely restates the tool name. It lacks any explanatory structure or helpful detail, falling into the 'Process' trap where brevity replaces substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), the description still fails to provide essential context. It does not state what cookies will be returned, whether they are for the current page or all cookies, or what the output format is (since there is no output schema). The description is completely inadequate for an agent to understand the tool's behavior without additional inference.
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. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to explain. The description does not need to add parameter details, though it could have used the space to explain what 'cookies' refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取Cookie' translates directly to 'Get Cookie', which is essentially a restatement of the tool name 'browser_get_cookies'. It does not add any specificity about what cookies are retrieved (e.g., all cookies, current page, domain), nor does it distinguish from sibling tools. This is a tautology rather than a purposeful description.
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 about when to use this tool versus alternatives. It does not mention that it complements browser_set_cookies and browser_clear_cookies, nor does it explain prerequisites (e.g., needing an active page). The absence of any usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'start collecting' but doesn't disclose side effects, whether it clears previous coverage, what the return value is, or how it interacts with browser_stop_coverage. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but conciseness should not come at the expense of essential information. It is under-specified and fails to explain the tool's actual behavior or output, making it more of an underspecified placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a misleading description, the tool is incompletely specified. The description doesn't state what the tool returns, what side effects it has, or how it fits into the coverage lifecycle, so the agent cannot reliably invoke or interpret the result.
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 covers 100% of them trivially. The description adds no parameter semantics, but none are needed, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '开始收集代码覆盖率' (start collecting code coverage) states an action but conflicts with the tool name 'get_coverage', which implies retrieval. It doesn't clarify whether this tool starts coverage collection or returns collected data, and it doesn't distinguish it from sibling tools like browser_stop_coverage.
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. It doesn't mention prerequisites, expected sequence (e.g., start before stop), or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries no behavioral information. It does not disclose whether this creates a new tab, a new browser context, whether it returns a page reference, or whether it navigates to a default URL. The agent is left completely uninformed about side effects or required state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It contains only a single phrase with no additional context, structure, or details, offering minimal value to an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely side effects (creating a new page) and the absence of any output schema or annotations, the description is completely inadequate. It does not explain what constitutes a 'page', what state the browser must be in, what the tool returns, or how it interacts with other browser tools.
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 schema coverage trivially 100% and no parameters to describe, the baseline score is 4. The description adds no additional parameter context, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建新页面' directly translates to 'create new page', which is essentially a restatement of the tool name 'browser_new_page'. While it adds a verb, it fails to specify what kind of page is created, whether it opens a blank tab, a new window, or triggers a navigation. It does not distinguish this tool from browser_goto or browser_launch beyond the name.
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 browser_goto or browser_switch_page. There is no mention of typical scenarios, prerequisites, or exclusions.
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 of behavioral disclosure. It fails to explain side effects (e.g., triggers change events), whether multiple selection is supported (despite value accepting an array), or any prerequisites like the element being a native <select>. This is a significant transparency gap for a tool that interacts with page elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words in Chinese), but brevity is not conciseness when it omits essential information. It offers no structure or detail, making it closer to under-specification than efficient communication.
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 and its many sibling tools, this description is incomplete. It does not mention return values, error conditions, or typical usage flow. Without annotations or an output schema, the description leaves the agent to guess how the tool behaves in practice.
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?
The input schema lists only 'selector' and 'value' with no descriptions, and the tool description provides no additional meaning. The description does not explain that 'value' can be a string or array, nor does it clarify the expected format of 'selector' (CSS selector vs. XPath). With 0% schema description coverage, the lack of parameter explanation is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '选择下拉框' ('select dropdown') is a near-restatement of the tool name and gives only a vague sense of operating on a dropdown. It does not specify that it selects an option within a dropdown element, nor does it distinguish this from browser_click or browser_fill. A more specific phrase like 'select an option in a <select> element' would clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as browser_click, browser_fill, or browser_check. The description does not mention the typical use case for a dropdown selection or exclude cases where other actions are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not mention the effect of the tap (e.g., whether it dispatches touch events, whether it requires a mobile emulation context, or whether it scrolls the page), any side effects, or prerequisites. The description '触摸屏点击坐标' merely restates the basic action without adding any behavioral context beyond what the name implies, making it nearly useless for understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one noun phrase), which could be seen as concise, but it is under-specified rather than efficiently informative. There is no structure with key information front-loaded; it reads more like a label than a description. Every word should earn its place, but here the words provide only vague meaning and omit critical details. This is not concise in a useful sense but rather a deficiency in specification, so it scores low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is still far from complete. There is no output schema, no annotations, and no behavioral details. A user/agent cannot determine when to use this tool, how the coordinates are interpreted, or what the expected outcome is. The tool has many siblings, and the description fails to position it within the broader automation context. This is a significant gap, leaving the description essentially inadequate for reliable selection and invocation.
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?
The input schema defines x and y as required numbers, but has 0% schema description coverage, so the description must compensate. The description says '坐标' (coordinates), which indicates that x and y are coordinate values, but it does not specify units, coordinate system origin (viewport vs. page), or whether they are integers vs. floats. This adds minimal meaning over the bare schema, leaving the agent to guess the exact semantics. Since the description does not fully compensate for the lack of schema descriptions, a score of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '触摸屏点击坐标' translates to 'touchscreen tap coordinates', which conveys that the tool taps on a touchscreen at specified coordinates. This gives a general sense of the action and resource, but it is terse and ambiguous (could be interpreted as a noun phrase rather than an instruction). It does not explicitly state the verb 'tap' or 'click', and while it differentiates from mouse-based actions like browser_click, it does not clearly contrast with sibling tools like browser_tap, which may also involve tapping. Thus it is a vague but not entirely unhelpful description.
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. There are many sibling tools such as browser_click, browser_tap, and browser_mouse_click, but the description does not mention any context like 'use for touch-enabled devices' or 'when a tap event is needed'. The tool name implies touchscreen usage, but the description itself offers no explicit or even clearly implied usage conditions, leaving the agent without sufficient direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description offers no behavioral details such as whether the style tag is injected into the current page or the URL specified, whether it overrides existing styles, or any side effects. This is a significant 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (five characters), but this is under-specification rather than efficient conciseness. It lacks essential information while being brief, which fails the tool's usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain the role of url versus content, whether content is required, or what happens on execution. This is insufficient for an agent to invoke the tool correctly.
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?
The input schema has two parameters (url and content) with 0% description coverage, and the tool description does not explain what these parameters mean. The description fails to compensate for the lack of schema context, leaving the agent guessing about required fields and formats.
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 '添加样式标签' (Add style tag) clearly states the operation (adding a style tag) and the resource (style tag). It is specific enough to understand the general purpose, though it does not distinguish from its sibling browser_add_script_tag beyond the style/script difference.
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, whether it requires a loaded page, or how it differs from alternatives like browser_add_script_tag. The description merely states the action without any contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description only states the action without disclosing behavioral traits such as whether the tool waits for the element to be actionable, whether it moves the mouse, what the default button is, or how it handles hidden elements. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it is under-specified rather than concise. It omits critical information about parameter usage and behavior, so it does not earn a higher score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 parameters, no annotations, no output schema), the description is severely incomplete. It fails to explain return values, default behaviors, or usage context, making it nearly impossible for an agent to use the tool correctly based on the description alone.
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?
The schema has no descriptions (0% coverage), and the description does not compensate by explaining any parameters. The four parameters (selector, button, timeout, clickCount) are not mentioned at all, leaving the agent to infer their meaning solely from names and enums.
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 '点击元素' (Click element) clearly states the primary action: clicking an element. It is a specific verb+resource pairing, but it does not differentiate from closely related sibling tools such as browser_mouse_click, browser_dblclick, or browser_tap, all of which involve clicking.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context regarding prerequisites, typical scenarios, or distinctions from sibling tools like browser_mouse_click or browser_tap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says '获取请求日志' without addressing pagination, limits, ordering, whether logs are cleared, or what the output structure is. The description is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might be seen as concise, but it is under-specified. It lacks essential information about the tool's behavior and usage, making it closer to a tautology than a helpful, well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple log retrieval operation, but the description is inadequate. It fails to explain what 'request logs' means, how the limit parameter works, whether output is returned, or any relevant details that would make the tool usable. The absence of an output schema and annotations makes this incompleteness critical.
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?
The input schema has a single 'limit' parameter with 0% schema description coverage. The description does not mention 'limit' or explain its meaning, default value, or effect, providing no additional value beyond the bare 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 '获取请求日志' translates to 'Get request logs', which clearly states the tool's verb and resource. However, it does not distinguish from sibling tools like browser_get_response_logs or browser_get_console_logs, as it lacks specificity about the log type or source.
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?
There is no guidance on when to use this tool versus alternatives. The description provides no context, prerequisites, or examples, leaving the agent without criteria for selecting it over other logging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is just the action phrase with no behavioral disclosure. It does not mention that the tool operates on the current page, what happens if no page is loaded, or the return format. Since no annotations are provided, the description carries the full burden and fails to provide any transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no structure, but it is concise. However, it is under-specified and provides little value beyond the tool name, so it does not earn a higher score for appropriate sizing and front-loading.
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?
Even for a simple getter, the description lacks essential context such as return value, current page assumption, and error behavior. Without an output schema or annotations, this is insufficient for an agent to use the tool confidently, making the description 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 zero parameters, so there is nothing to document. The baseline for zero-parameter tools is 4, and the description does not need to add parameter semantics because no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取页面标题' directly restates the tool name (browser_get_title) in Chinese, offering no additional specificity or differentiation from sibling getter tools. It is essentially a tautology, not a clear purpose statement that distinguishes the tool from others like browser_get_text or browser_get_current_url.
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 about when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusion conditions, leaving the agent without direction on when to select this tool over similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the literal action. It does not disclose behavior when there is no previous page, whether the page state is preserved, or any error conditions.
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 extremely short, consisting of a single phrase. It is concise but lacks substantive detail; however, for a simple navigation action, this size is acceptable.
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 description is minimal and does not address important context like what happens if there is no browsing history. For a browser control tool, more detail is expected to avoid misuse.
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 description's lack of parameter information is not a deficiency. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '返回上一页' translates to 'go back to previous page,' which directly restates the tool's name 'browser_go_back.' It provides no additional specificity beyond the name, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool instead of alternatives like browser_go_forward, browser_reload, or browser_goto. There is no mention of history navigation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it merely states 'clear geolocation' without explaining effects, side effects, or the fact that it resets geolocation to system default or removes a mock override. This provides no transparency beyond the name.
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 short phrase, which is structurally simple and concise. However, the brevity is a form of under-specification rather than effective conciseness, as it omits all contextual information. It is not verbose, but it does not earn its place by adding 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?
For a tool with no parameters and no output schema, the description still fails to explain what 'clearing geolocation' means in the browser automation context. It does not mention the relationship to browser_set_geolocation or the resulting state, leaving the agent to infer behavior. This is incomplete even for a simple 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 schema coverage is 100% (empty schema). There is nothing to add about parameters, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '清除地理位置' is a direct Chinese translation of the tool name 'browser_clear_geolocation', restating the action without adding any new detail. It is essentially a tautology and does not distinguish itself from other browser-related tools beyond the name itself.
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, when not to, or any alternatives. It lacks context about clearing geolocation overrides set by browser_set_geolocation or any usage prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It provides none: no explanation of what pausing the clock does to timers, whether a clock must have been installed first, or whether this affects other browser operations. The description is completely opaque.
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 extremely concise, consisting of a single phrase. However, it is under-specified rather than appropriately sized; a few words clarifying the effect or usage context would be more valuable. It earns a middle score for brevity but not for informative structure.
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 lack of annotations, output schema, and parameter details, the description must compensate by providing operational context. It fails to do so, leaving the agent without sufficient understanding of the tool's role in clock management or its side effects.
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 provides no information to supplement. The baseline for 0-parameter tools is 4, and the description does not detract from this, even though it offers no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '暂停时钟' is a direct translation of the tool name 'browser_pause_clock', essentially restating the title without additional context. It does convey the action (pause) and resource (clock), but it is a tautology, offering no new information beyond the name itself.
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?
There is no guidance on when to use this tool versus alternatives such as browser_fast_forward or browser_resume_clock. The description simply states the action, with no mention of prerequisites, typical use cases, or relationship to sibling clock-management 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?
There are no annotations, so the description carries the full burden. It gives no details about return behavior, error handling, waiting for elements, or whether the element must exist. This is a minimal factual statement without 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than appropriate conciseness. It essentially restates the tool name and lacks necessary details, so the brevity does not improve understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, no output schema, and no annotations, the description is inadequate. It does not explain expected return value, behavior with multiple matches, or how 'exact' affects matching. This is insufficient for an agent to invoke the tool confidently.
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%. The description mentions 'alt text' which loosely maps to the 'text' parameter, but does not explain the 'exact' parameter at all. It adds no meaningful insight beyond what the param names already imply.
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 states the tool finds elements by alt text, which is a specific action and resource. It distinguishes itself from sibling tools like get_by_text or get_by_label by mentioning 'alt text'. However, it does not clarify whether it returns a single element, list, or locator.
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 usage guidance is provided. The description does not indicate when to prefer this tool over alternative locator strategies (e.g., get_by_role, get_by_text) or any edge cases for the 'exact' parameter. It only states the basic action.
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 must carry the full burden. '按下' implies a key-down event, but it does not state that the key is held down until a corresponding keyboard_up call, nor does it mention focus requirements or modifier key behavior. The minimal wording provides only vague 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 a single short phrase with no wasted words. It is front-loaded and appropriately sized for a tool with one parameter, but it is so minimal that conciseness comes at the expense of clarity.
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 a simple schema and no output schema, but the description still needs to clarify the key format, the relationship with keyboard_up, and when to use it instead of browser_press. All of this is missing, making the description insufficient for reliable invocation.
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?
The schema defines only 'key' as a required string, but neither the schema nor the description explains the expected format (e.g., 'Enter', 'a', or 'Control'). Schema description coverage is 0%, and the description adds no meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按下键盘按键' translates to 'Press keyboard key'. It uses a specific verb and resource, but does not explicitly distinguish the 'down' action from a full key press, especially given the sibling tool browser_press. The language mismatch (Chinese vs English tool name) may also reduce clarity for some 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 like browser_keyboard_up, browser_press, or browser_keyboard_insert_text. There are no exclusions or context cues.
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 present, so the description carries the full burden. It only says 'Set Cookie' and does not disclose behavioral details such as whether existing cookies are overwritten, whether a page must be active, or any side effects. For a mutation 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two characters in Chinese), which is under-specification rather than efficient conciseness. It conveys the basic idea but lacks structure and necessary detail, making it unhelpful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no output schema, no annotations, and a single parameter. The description is too sparse to provide complete context. It does not explain the format of cookies, expected behavior, or any prerequisites, making it inadequate for reliable invocation.
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?
The input schema lists a single 'cookies' array with no description. The tool description does not explain the expected structure of array elements (e.g., name, value, domain, path). With 0% schema coverage, the description fails to compensate, leaving the parameters entirely ambiguous.
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 states '设置Cookie' (Set Cookie), which is a specific verb and resource, clearly indicating that the tool sets cookies. This distinguishes it from sibling tools like browser_get_cookies and browser_clear_cookies. However, it does not elaborate on the exact scope (e.g., for the current page, all pages), so it slightly lacks precision.
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. The description does not mention any context, prerequisites, or exclusions. It is a bare statement without any usage direction.
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 only says 'Set LocalStorage' without disclosing whether it overwrites existing values, whether it requires a page context, or any other behavioral traits. It implies a write operation but adds no detail beyond what is already obvious from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it under-specifies the tool's behavior and parameters. It does not earn its place as a helpful description; it's more of a label than a functional description, so the brevity is not a positive trait here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description still omits essential context: no return value, no prerequisites, no side effects, and no cross-references to related storage operations. With no annotations and no output schema, the description is the only source of context, and it is insufficient.
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?
The schema has two parameters (key, value) with 0% description coverage. The description does not explain the meaning, format, or constraints of these parameters, so it fails to compensate for the schema's lack of descriptions. The parameter names are somewhat self-explanatory, but the description adds no explicit semantics.
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 uses a specific verb '设置' (set) with the resource 'LocalStorage', clearly indicating an action to set a local storage value. It differentiates from sibling tools like browser_get_local_storage and browser_clear_local_storage by the action performed. However, it does not explicitly mention the key-value pair structure, though the schema provides that.
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 offers no guidance on when to use this tool versus alternatives, no prerequisites (like needing a page loaded), and no exclusions. It simply states the action without any context, leaving the agent to infer usage.
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 the full burden of disclosing behavior, but it merely states 'close specified page'. It does not mention consequences such as whether closing the current page switches to another, whether the index is zero-based, or any irreversible effects. This is a destructive operation with minimal safety disclosure.
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 concise sentence with no fluff, but it is under-specified. It earns its place minimally, yet it sacrifices clarity for brevity. The structure is clean but misses crucial details about the parameter and behavior.
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 is simple (one parameter, no output schema), but the description is too thin for reliable use. It lacks essential context about how to identify the page, what happens after closing, and any side effects. Given the destructive nature, more detail is required for safe operation.
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?
The input schema has a single parameter `index` of type number, but neither the schema nor the description explains its meaning (e.g., zero-based page index, tab order, or internal identifier). With 0% schema description coverage, the description should have compensated, but it stays silent. The agent cannot determine what value to supply.
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 identifies the action (close) and resource (specified page), and the parameter `index` in the schema indicates which page. It distinguishes from `browser_close` which likely closes the entire browser. However, it could be more explicit about the page being identified by index.
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 like `browser_close`, `browser_new_page`, or `browser_switch_page`. The description does not mention any prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the 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?
With no annotations, the description carries the full burden for behavioral disclosure. It does not mention return format (e.g., a number), edge cases like zero matches, selector validity, or any side effects. '统计元素数量' is too terse to convey meaningful behavioral traits beyond the basic action.
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 extremely concise with zero wasted words, but it is under-specified to the point of bordering on a tautology. It lacks structure that would help an agent understand scope or expected behavior, so it is not appropriately sized for effective use.
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 has one parameter, no output schema, and no annotations, the description should provide at least basic usage context. It does not mention return value, selector type (CSS vs other), or any exceptions. For a simple count tool, this is incomplete though not completely useless.
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 does not compensate. The 'selector' parameter is not explained in the description, leaving its format or semantics entirely to inference. The description adds no meaning beyond the schema's bare type declaration.
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 '统计元素数量' (Count the number of elements) clearly states the core action and resource. It distinguishes from sibling tools like browser_get_text or browser_click, but it does not explicitly mention the selector parameter or that the count applies to matching elements, so it lacks full specificity.
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, nor any mention of prerequisites or context. It merely states what the tool does without any usage notes.
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 the full burden of behavioral disclosure. It only states 'emulate media type' without explaining side effects, persistence, or how it affects rendering. It also omits the colorScheme functionality entirely.
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 extremely brief (single phrase), which is concise but under-specified. It earns its place by stating the core action, but lacks the structure to convey additional context expected for a tool with two parameters.
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 two parameters, no annotations, and no output schema, so the description should provide adequate context. It only covers the 'media type' aspect and omits 'colorScheme', and gives no hint about when or why to use this tool in browser automation workflows.
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%, so the description must compensate for parameter meaning. It doesn't mention either 'media' or 'colorScheme', leaving the enums to self-explain. The schema is somewhat clear, but the description adds no value in explaining parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '模拟媒体类型' (emulate media type) uses a specific verb and resource, indicating the tool's general purpose. However, it doesn't differentiate from other browser tools or mention the colorScheme parameter, leaving the full scope unclear.
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, nor are any exclusions or prerequisites mentioned. The description simply states the action without contextualizing it among sibling browser 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?
With no annotations, the description carries the full burden. It only states 'move mouse' with no details about absolute/relative movement, whether hover events are triggered, or how the 'steps' parameter affects behavior. The description is not misleading but omits critical 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity here results from under-specification rather than economy. It lacks any structure and leaves out essential details, making it less useful than a concise but complete description.
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 has 3 parameters, no annotations, and no output schema, the description is inadequate. It should at least mention coordinates and the role of 'steps' to be minimally complete. As provided, it only conveys the basic action.
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?
The schema has 0% description coverage and the tool description does not explain any of the parameters. 'Move mouse' does not clarify that x and y are coordinates or how 'steps' influences the action. The description adds no value beyond the raw 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: move the mouse. It distinguishes from mouse-specific siblings like click, down, up, and wheel, though it does not mention coordinates explicitly. The verb+resource is specific enough for basic understanding.
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 usage guidance is provided. The description does not indicate when to use this tool versus other mouse-related tools, nor does it mention any context or prerequisites. There is no support for decision-making.
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 the full burden, but it only restates the action without disclosing behavior such as output format, file handling, save path, or whether fullPage affects output. It is minimally informative but not misleading.
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 extremely concise with no wasted words, but it is under-specified for an AI agent. It lacks structure and context, making it less helpful than a well-organized description of similar length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations. The description fails to explain parameter meaning, return values, or any operational context, making it inadequate for correct invocation.
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 information about the four parameters (path, type, quality, fullPage). For a tool with multiple parameters, this is a critical gap.
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 '截取页面截图' (capture page screenshot) clearly states the action and resource. It distinguishes from the sibling tool browser_screenshot_element by specifying 'page' rather than element, though it doesn't elaborate on scope or options.
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 given on when to use this tool versus alternatives like browser_screenshot_element or browser_pdf. The description and sibling list imply a page-level screenshot, but there is no explicit context or exclusion.
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 the burden of disclosing behavior. It merely states a literal action without explaining effects like whether existing connections are dropped, whether all contexts are affected, or how to revert. The boolean parameter's true/false meaning is not clarified.
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 extremely concise with no fluff, which is positive. However, it is under-specified for an agent to act reliably; a few additional words about the parameter or effect would greatly improve it without adding sizeable length.
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?
For a simple boolean toggle, the description is insufficient. There is no output schema, no annotations, no context about when to use it, and the parameter meaning is ambiguous. The tool could be misused because the agent lacks essential information about the offline flag.
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 does not explain the single 'offline' boolean parameter. The agent cannot infer whether true means offline or online, nor the default behavior. This is a critical gap for a one-parameter tool.
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 means 'Set offline mode', which is a specific action on the browser's network state. It identifies the tool's purpose unambiguously, but doesn't fully distinguish it from other browser settings tools beyond the unique 'offline' concept.
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 usage guidance is provided. The description doesn't mention when to use this tool instead of other browser settings tools, nor does it explain the implications of enabling offline mode (e.g., network requests will fail).
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 of behavioral disclosure. It only states the action without detailing side effects, scope, persistence, or dependencies. The agent cannot infer what setting the system time actually changes or whether it interacts with clock-related tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might be considered concise, but it under-specifies the tool to the point of being insufficient. This is under-specification rather than effective conciseness, as it omits critical 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?
For a mutation tool with no annotations, no output schema, and a poorly described parameter, the description is incomplete. An agent cannot understand the full context, including whether setting the time requires any special setup or affects other browser operations.
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?
The schema defines a single 'time' parameter with type number|string, but the description gives no explanation of the expected format, units, timezone, or meaning. With 0% schema description coverage, the description fails to compensate, leaving the parameter semantics entirely unexplained.
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 '设置系统时间' (set system time) clearly states a specific verb and resource, making the tool's primary function obvious. However, it does not explain how this relates to similar sibling tools like browser_install_clock or browser_fast_forward, limiting differentiation.
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. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent without any contextual usage direction.
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 the full burden. It only states the action without disclosing side effects (e.g., resize event, affecting current page), requirements (e.g., must have a page), or reversibility.
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 concise and front-loaded, but it essentially restates the tool name without adding contextual value. It is under-specified rather than efficiently informative.
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?
For a simple two-parameter setter, the description is incomplete. With no output schema or annotations, it should at minimum specify the effect scope (e.g., current page) and units. The current description leaves these gaps.
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 does not elaborate on width/height meanings, units (pixels?), or constraints. The agent must rely on parameter names alone.
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 '设置视口大小' (Set viewport size) clearly states the action and resource, distinguishing it from the sibling getter browser_get_viewport_size. However, it lacks explicit context about the scope (e.g., current page) but remains unambiguous.
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. No mention of prerequisites such as a page being open, nor any exclusions compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden. It only states 'save storage state' but gives no details on what is saved (cookies, localStorage, etc.), whether a file is written, overwrite behavior, or any side effects. This is insufficient for an agent to understand the tool's effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single minimal phrase, which is short but under-specified. It lacks necessary context and explanation, so this is not effective conciseness but rather under-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 the presence of a 'path' parameter, no output schema, and a sibling 'browser_restore_storage_state', the description is far too minimal. It doesn't explain how the path is used or how this tool relates to state restoration, leaving the agent with insufficient context.
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?
The schema has a single 'path' parameter with 0% description coverage in the schema, and the tool description does not mention 'path' at all. The agent cannot infer what the path parameter is for, making parameter semantics extremely poor.
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 '保存存储状态' (save storage state) clearly states a save operation on browser storage, distinguishing it from read/clear operations. However, it does not differentiate from its counterpart 'browser_restore_storage_state' or other storage-related tools.
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. It doesn't mention pairing with browser_restore_storage_state, nor any prerequisites or typical scenarios for saving storage state.
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 the full burden of behavioral disclosure, but it only says 'touch click (mobile)' without explaining side effects, visibility requirements, or how the tap is performed. No contradictory information exists, but the transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (3 words in Chinese), which is under-specification rather than genuine conciseness. It lacks essential context that would fit in a few more sentences, such as usage compared to siblings.
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 low complexity (1 param) and no output schema, the description is still incomplete because it fails to distinguish this tool from browser_touchscreen_tap and browser_click, and does not explain when mobile tap is appropriate. No annotations or parameter details compensate.
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?
The sole parameter 'selector' has no description in the schema (0% coverage), and the description does not mention it at all. The tool name and generic phrasing imply a selector, but the description adds no meaning beyond the raw 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 a tap/touch click action for mobile devices, using a specific verb ('tap') and resource (browser UI). It differentiates from regular clicks by noting mobile context, though it does not explicitly contrast with sibling tools like browser_click or browser_touchscreen_tap.
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 given on when to use this tool versus alternatives such as browser_click or browser_touchscreen_tap. The only hint is '移动端' (mobile), but there is no explicit context, prerequisites, or exclusions.
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 responsibility for behavioral disclosure. It only states the core condition (function returns true), but fails to mention critical details such as polling behavior, timeout handling, error outcomes, execution context, or whether the function is evaluated in the page or Node.js environment.
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 short sentence, which is concise, but it is under-specified. While it is front-loaded with the core purpose, the extreme brevity leaves out essential behavioral and parameter information, making it less useful than a slightly longer but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, no output schema, no annotations), the description is grossly incomplete. An agent cannot infer how to construct the function, what polling/timeout mean, or what happens on success or failure. This is insufficient for reliable tool invocation.
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 provides no explanations for the parameters. The meaning of 'fn', 'arg', 'polling', and 'timeout' (units, required format, semantics) is entirely omitted, leaving the agent to guess.
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 action: wait for a function to return true. This distinguishes it from sibling wait tools that wait for selectors, URLs, or network events, though it could be more explicit about the custom JavaScript function evaluation context.
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 like browser_evaluate or browser_wait_for_selector. The description does not mention use cases, prerequisites, or fallback options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the action without explaining side effects, output format (e.g., base64 vs. saved file), or any special conditions. The description adds no meaningful behavioral context beyond the tool name.
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 short phrase with no redundancy or unnecessary words, making it highly concise. However, it is under-specified, but that is penalized in other dimensions rather than here.
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 no annotations and no output schema, the description must provide enough context to invoke the tool correctly. It fails to mention the path parameter's role, return value, or any nuances about element selection, leaving significant gaps in an agent's ability to use it properly.
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%, and the description does not mention either 'selector' or 'path'. While 'selector' is implied by the tool name, the purpose of 'path' is completely unexplained, leaving a critical gap for the agent to know whether it is for saving to a file or something else.
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 '截取元素截图' translates to 'capture element screenshot', clearly identifying the action of taking a screenshot of a specific element. It names a specific verb and resource, and the tool name itself distinguishes it from the full-page browser_screenshot sibling, though the description does not explicitly draw that 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?
The description provides no guidance on when to use this tool versus browser_screenshot or other element-based tools. It lacks any mention of prerequisites, alternatives, or typical use cases, leaving the agent without context for selection.
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 merely states the action without revealing any behavioral traits such as coordinate system (viewport vs page), units (pixels), scroll behavior (smooth vs instant), or side effects (e.g., whether it triggers scroll events). This is a minimal restatement of the tool's name and provides little transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse (a single short clause). While there is no wasted text, the brevity crosses into under-specification, failing to provide even the most basic contextual structure. It is not a model of conciseness but rather a placeholder that leaves the agent with too little 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 the minimal description, no annotations, no output schema, and a sibling list containing browser_scroll_into_view, the tool context is incomplete. The description does not clarify the relationship to sibling tools, the coordinate system, or the expected behavior, leaving significant ambiguity for an agent to resolve.
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?
The input schema has two numeric parameters (x, y) with no descriptions (0% coverage). The description adds only a vague reference to 'specified position' but does not explicitly explain that x and y represent horizontal and vertical offsets, nor does it define units or coordinate origin. This is insufficient compensation for the schema's lack of detail.
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 '滚动到指定位置' (scroll to specified position) clearly states the action (scrolling) and resource (position on page), making the core purpose understandable. However, it does not differentiate from the sibling tool browser_scroll_into_view, nor does it specify whether the scroll is to page coordinates or element position, so it lacks explicit sibling differentiation.
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?
There is no guidance on when to use this tool versus alternatives like browser_scroll_into_view or browser_mouse_wheel. The description provides no context about appropriate use cases, prerequisites, or exclusion criteria, leaving the agent without direction on tool selection.
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 responsibility for behavioral disclosure. It only restates the action of waiting for a URL match without explaining whether it polls, throws on timeout, or what the return value is. This is a minimal restatement of the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It omits critical details needed for correct usage, so it fails to be 'appropriately sized'—it's too brief to be useful.
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 only two parameters and no output schema, but the description still leaves major gaps: matching behavior, timeout behavior, return values, and error handling. The description is not complete enough for an agent to invoke this tool reliably.
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%, so the description must compensate. It mentions 'URL' but doesn't clarify the expected format (string, regex, glob) or the 'timeout' parameter semantics. No additional meaning is provided beyond the parameter names.
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 '等待URL匹配' clearly indicates the tool waits for a URL to match, with a specific verb and resource. It distinguishes from siblings like wait_for_selector and wait_for_timeout, though it doesn't specify the matching rule (exact, regex, glob).
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 browser_wait_for_request or browser_wait_for_function. No context is given about typical use cases or exclusions.
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 the full burden of behavioral disclosure, but it only states the core action. It doesn't mention return values, page context access, side effects, or whether the script is executed in the main world, leaving significant behavioral ambiguity.
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 extremely brief and front-loaded, using only five characters to convey the core purpose. It wastes no words, though its brevity leaves out valuable details; this is concise but arguably under-specified.
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 low complexity, minimal description might suffice, but the absence of annotations and output schema means the description should provide more context about return values, execution environment, and relationship to siblings. The current text is too thin for reliable agent selection and invocation.
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 meaning for the 'script' and 'arg' parameters. The agent receives no explanation of what 'arg' is used for or how the script should be formatted, completely failing to compensate for the schema's silence.
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 'Execute JavaScript code' clearly states the verb and resource, establishing what the tool does. It is specific enough to distinguish from most sibling tools, though it doesn't explicitly differentiate from related tools like browser_wait_for_function or browser_add_script_tag.
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 context, prerequisites, or exclusions, leaving the agent to infer usage from the 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?
With no annotations, the description carries the full burden, but it only says 'find element by text'. It does not disclose whether matching is exact or substring, case sensitivity, whether it returns the first match or all, or what happens if no element is found. This is a significant gap for a locator tool.
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 short phrase, which is concise, but it lacks sufficient structure and information. It is under-specified rather than properly concise; a few additional sentences could clarify behavior without bloating.
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 lack of annotations and output schema, and the existence of many sibling locator tools, the description is incomplete. It does not explain the return value, the exact parameter semantics, or how this tool differs from get_by_title or get_by_role. An agent would be uncertain when to select this tool and how to use it correctly.
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%, so the description must explain the parameters. It only reiterates 'by text', leaving the 'exact' boolean parameter completely unexplained. The agent cannot know what 'exact' controls (e.g., case sensitivity, substring matching) without additional context.
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 states the tool finds an element by text, which is a clear verb+resource. However, it does not distinguish from sibling tools like get_by_role, get_by_label, etc., which also locate elements by different criteria.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that it is specifically for text-based lookup or when other locators would be more appropriate. The user must infer usage from the name.
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?
There are no annotations to fall back on, so the description carries the full burden. It only says 'navigate to specified URL' without disclosing side effects such as loading the page in the current tab, changing history, or behavior on navigation failure. This is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no filler or redundancy. It is appropriately front-loaded and gets to the point, though it is somewhat under-specified. This is conciseness without waste, though not richly informative.
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 has 3 parameters and no annotations or output schema, the description is too sparse. It fails to explain the timeout and waitUntil behavior, what triggers a successful navigation, or any consequences. The description is barely more than the tool name.
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 does not compensate. It relates only to the 'url' parameter (specified URL) and completely ignores 'timeout' and 'waitUntil' parameters, leaving their meaning and usage unexplained.
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 ('navigate') and the target ('specified URL'), which is a specific verb+resource combination. It distinguishes from navigation history tools like go_back/go_forward by indicating a direct URL is provided, though it does not explicitly call out those alternatives.
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. The description merely states what it does, with no mention of when it is appropriate (e.g., for initial navigation vs. history traversal) or any exclusions.
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 does not explain what happens if the element does not exist, whether it returns a boolean, or any potential side effects. For a state-check tool, such details are important and 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 a single, front-loaded sentence with no wasted words. It is concise and immediately communicates the core action. However, it is somewhat under-specified, though this is more relevant to other dimensions than to 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?
Given the tool's simple nature, the description is minimal but incomplete. It does not mention the return value (likely boolean), error handling for missing elements, or any interaction with the page state. The absence of an output schema and annotations increases the need for a richer description, which is not provided.
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?
The input schema has one parameter 'selector' with no description, and the schema description coverage is 0%. The description does not compensate for this, as it merely refers to 'element' without explaining how to identify it or what selector format is expected (e.g., CSS selector, XPath). The parameter semantics are essentially undocumented.
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 checks if an element is enabled, using a specific verb and resource. It distinguishes from sibling tools like browser_is_visible and browser_is_checked by focusing on the enabled state. However, it does not explicitly mention the return type or any scope limitations, keeping it slightly below a perfect score.
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 over alternatives. There is no mention of prerequisites, such as the element needing to exist, or when it is appropriate to check enabled state versus visibility or checked state. The description gives no context about typical use cases or exclusions.
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 responsibility for behavioral disclosure. It only says 'scroll element into visible area' but does not explain side effects (e.g., scrolling behavior, effect on page position), whether it fails if the selector is missing, or what it returns. This is insufficient for a mutation-like action.
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 with no wasted words. It is appropriately short for the simple action, but the under-specification is a minor drawback, making it not a full 5.
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 one parameter, no output schema, and no annotations. The description is minimal and does not differentiate among the large sibling set, does not explain return values or failure modes, and lacks usage context. It is not complete enough for an AI agent to use confidently.
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%; the only parameter 'selector' lacks any description in both schema and tool description. The description does not mention the selector format (CSS, XPath, etc.) or provide examples, leaving the parameter ambiguous and the agent unable to construct valid invocations.
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 states '滚动元素到可见区域' (scroll element into visible area), which clearly indicates the action (scroll) and the resource (element). It distinguishes from siblings like browser_scroll_to which likely scrolls the page rather than an element, though it doesn't explicitly call that out.
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 browser_scroll_to or mouse wheel actions. The description does not mention contexts, prerequisites, or exclusions, leaving the agent without sufficient information for tool selection.
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 responsibility for behavioral disclosure. It only states the action without detailing whether it modifies the active page, handles invalid indices, returns a value, or has side effects. This is a minimal behavioral signal, not misleading but far from 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 extremely brief and to the point, consisting of a single clause with no redundant words. It is well-structured for a simple tool, though it sacrifices informative content for brevity.
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 simplicity (one parameter, no output schema), a concise description could suffice, but it must explain what switching a page means and how the index works. The description is too minimal to be considered complete, especially with no annotations or output schema to fill gaps.
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?
The schema describes a single 'index' parameter with no description, and the tool description does not explain what 'index' refers to (e.g., zero-based or one-based, page order). With 0% schema_description_coverage, the description must compensate, but it offers no parameter semantics at all.
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 uses a specific verb ('switch') and identifies the resource ('page'), clearly stating the core action. However, it does not distinguish from sibling tools or clarify what 'page' means (tab vs content), so it misses the highest rating.
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 context is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., having multiple pages open) or how it relates to browser_get_all_pages or browser_new_page. The absence of any usage direction leaves the agent to infer from the 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?
With no annotations, the description bears full responsibility for disclosing behavioral traits, but it only restates that the tool waits for a page load state. It does not explain blocking semantics, timeout behavior, return values, or error conditions. The schema's timeout parameter hints at behavior, but the description itself adds little beyond the obvious.
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 highly concise and front-loaded, containing no filler words. However, it borders on under-specification: a few additional contextual words about the available states or timeout behavior would make it more helpful without sacrificing 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?
For a wait tool with two parameters, no annotations, and no output schema, the description is too thin. It fails to explain what each load state means, what happens on timeout, or how this tool relates to sibling wait tools. The schema provides enum values but not enough context for reliable selection and invocation.
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%, and the description adds no parameter-level meaning beyond what the schema already provides. The enum values (load, domcontentloaded, networkidle) are self-explanatory, and 'timeout' is a standard parameter, but the description does not compensate for the missing schema descriptions or clarify how these values affect the wait.
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 '等待页面加载状态' (wait for page load state) clearly indicates a specific verb and resource: waiting for a page's loading state. It is not a tautology and is easily understood, though it does not explicitly differentiate itself from sibling wait tools such as browser_wait_for_selector or browser_wait_for_url.
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 about when to use this tool versus the many sibling wait tools (browser_wait_for_selector, browser_wait_for_url, browser_wait_for_timeout, etc.). The description gives no context, prerequisites, or exclusion criteria, leaving the agent to infer usage solely from the name.
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 only states the core action and gives no information about matching behavior (exact vs. substring), what happens with multiple matches, error handling, or the return format. The 'exact' parameter hints at a matching mode, but the description does not address it.
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?
A single short sentence that is front-loaded and easy to parse. However, the brevity comes at the cost of omitting essential details, so it is concise but under-specifying.
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 large family of sibling locator tools and the absence of an output schema, the description is insufficiently complete. It does not explain return values, matching behavior, or how to choose among the get_by_* variants. The two parameters are also poorly documented.
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%, and the description does not explicitly describe the parameters. It implies that 'text' is the placeholder value, but the 'exact' parameter's meaning and effect are completely undefined. The description adds minimal semantic value beyond the parameter names.
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 "Find element by placeholder" – a specific verb and resource with the placeholder attribute as the locator. This distinguishes it from sibling locator tools like get_by_role or get_by_text, though it does not explicitly name any alternatives.
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 the many other get_by_* locator tools. There are no prerequisites, exclusions, or alternative suggestions. The intended use case is only implied by the tool name and description.
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 of behavioral disclosure. It does not explain that this tool presses and holds the button until a corresponding mouse_up, nor does it mention any side effects or prerequisites (e.g., need for an active page). This is a notable 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 description is extremely short and to the point, containing no filler. It communicates the core action in a single phrase. However, it may be overly sparse, omitting useful context that could fit without bloating.
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 large set of sibling browser tools and the absence of annotations or output schema, this minimal description is insufficient. It does not explain the tool's relationship to other mouse actions, when a down event is required, or any state changes (like holding the button).
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% and the description adds no information about the button or clickCount parameters. While the parameter names are somewhat self-explanatory, the description does not clarify allowed values, default behavior, or how clickCount affects the event.
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 indicates the action of pressing a mouse button, which is a specific verb+resource. However, it does not explicitly distinguish this from sibling tools like browser_mouse_click or browser_mouse_up, so it lacks some sibling differentiation.
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_click or browser_mouse_up. There is no mention of scenarios where a down press is needed (e.g., drag-and-drop or holding a button).
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 the full burden of behavioral disclosure. It only states 'wait for element to appear' without explaining whether it throws on timeout, how the state parameter alters waiting behavior, or what happens on failure. This is a major gap for a synchronization 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 single sentence is concise and front-loaded, with no redundancy or filler. However, it is so minimal that it omits essential context, placing it below a perfect score.
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 three parameters, no annotations, and no output schema, this one-line description is insufficient. It lacks details on timeout behavior, return values, state semantics, and usage context, especially among numerous sibling wait tools.
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%, and the description adds no parameter details. It does not explain the selector, state, or timeout fields, so the agent must rely on the schema's names and enum values alone.
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 '等待元素出现' (wait for element to appear) clearly identifies the action and resource. It distinguishes from sibling wait tools that target URLs, requests, responses, or functions, but does not explicitly clarify the meaning of 'appear' or mention the state parameter.
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 usage guidance is provided. The description does not specify when to use this tool compared to alternatives like browser_wait_for_url or browser_wait_for_function, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It does not disclose behavior such as whether the element must be visible, what happens on error, or if any side effects occur. The action is straightforward but underspecified.
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 short phrase with zero filler words. It is well-suited for a simple action and wastes no characters.
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 only one parameter, no annotations, and no output schema, the description is too minimal to be complete. It does not mention return values, error behavior, or when a double-click is preferable, leaving the agent to infer critical context.
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%, and the description does not elaborate on the 'selector' parameter. The parameter name suggests a selector, but the format (CSS, XPath, etc.) is not clarified, so the description adds minimal value 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 '双击元素' (double-click element) clearly states the action (double-click) and resource (element). It implicitly distinguishes from siblings like browser_click by specifying the double-click action, though it does not explicitly name an alternative.
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 browser_click or browser_hover. The description only states the action without context or exclusions.
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 merely states 'find element by title attribute' and does not mention whether it returns a locator, waits for the element, handles multiple matches, or errors if not found. No behavioral details are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it largely restates the tool name ('find element by title attribute'), adding little value. It is under-specified rather than appropriately concise, and the brevity wastes the opportunity to provide needed context.
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 has 2 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns, how exact matching works, or any error/edge-case behavior. A single-phrase description is insufficient for a selectable element lookup tool.
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%, so the description should compensate. It hints that 'text' refers to the title value, but the 'exact' boolean parameter is not explained at all. The parameter semantics are only partially clarified.
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 '查找' (find) and the resource '元素' (element) via the 'title' attribute, which distinguishes it from sibling get-by-* tools (e.g., get_by_text, get_by_label). Even though it's brief, the purpose is unambiguous and specific to the title attribute.
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?
There is no guidance on when to use this tool versus alternatives like browser_get_by_text or browser_get_by_label. The only implied usage is 'by title attribute', 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, but it provides no behavioral details. It does not disclose what happens if the element is not an input, whether the value is returned as a string, or error behavior when the selector matches nothing. This is minimal coverage for a tool with no annotation support.
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, short phrase with no wasted words. It is appropriately sized for a simple tool, front-loaded with the essential purpose.
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 no output schema, no annotations, and a single parameter lacking explanation, the description is incomplete. It does not cover return types, element compatibility, or error cases, which are critical for an agent to use the tool correctly in varied scenarios.
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%, and the description adds nothing about the 'selector' parameter. It doesn't explain whether the selector is CSS, XPath, or some other format. The parameter name alone is insufficient for an agent to reliably construct a correct invocation.
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 '获取输入框值' translates to 'Get input field value', which clearly identifies the action (getting a value) and the resource (input element). It distinguishes itself from siblings like browser_get_text or browser_get_attribute by specifying 'input value', though it doesn't explicitly state it's for input/textarea/select elements only.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as browser_get_text or browser_get_attribute, nor does it indicate prerequisites or context for use.
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 the full burden. It only states the action without disclosing side effects, requirements (e.g., whether a button must be already pressed), or response behavior. Nothing is added beyond the tool's name.
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 short, clear phrase with no wasted words. It is front-loaded and easy to parse, though 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?
For a tool with no annotations, no output schema, and 0% parameter coverage, the description is insufficient. It explains the core action but lacks context about parameters, usage, and behavior, leaving the agent to guess for non-trivial invocations.
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 does not explain the 'button' or 'clickCount' parameters. The enum for button is self-explanatory, but clickCount's meaning for a release action is entirely undocumented.
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 '释放鼠标按键' (release mouse button) clearly states the tool's action using a specific verb and resource. It unambiguously distinguishes from sibling tools like mouse_down, mouse_move, and mouse_click.
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 pairing with mouse_down, drag operations, or any exclusion or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no behavioral details, the description is a bare statement of intent. It does not disclose what happens if no element is found, whether it returns a handle or locator, or whether it waits for the element. The phrase adds no insight beyond the tool's name.
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 short phrase with no superfluous words. It is front-loaded and immediately communicates the core purpose, making it highly concise and structurally 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?
The tool is simple but has no annotations or output schema, yet the description does not explain return values, error behavior, or the context of element lookup (e.g., current page or frame). This leaves significant gaps for an AI agent attempting to use the tool correctly.
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?
The schema has one required parameter 'testId' with no type description, and schema description coverage is 0%. The description only repeats that the element is found 'by test ID', adding minimal meaning about what the parameter represents. It does not explain the format, attribute, or matching behavior expected for testId.
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 '通过测试ID查找元素' (Find element by test ID) clearly states a specific action (find) on a specific resource (element) using a specific locator strategy (test ID). This distinguishes it from sibling get_by_* tools like get_by_role or get_by_text, which use different locators.
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. It does not mention any exclusions, prerequisites, or comparative context to sibling locator tools, leaving the agent to infer usage from the tool 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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the operation without explaining what frames are included, the output format, or any side effects. This is a significant gap for a tool that retrieves data.
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 very brief (three words in Chinese), which is concise but arguably under-specified. It does not waste words, but it also fails to include any explanatory context that would help an agent understand the tool's exact function.
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, the description should describe the return value and scope. It does neither, leaving the agent uncertain about what frames are returned and in what format. The description is inadequate for a tool that could have multiple interpretations.
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 baseline of 4 applies. The description adds no parameter information, but none is needed since there are no inputs to document.
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 '获取所有frame' (get all frames) states a clear action and resource, distinguishing it from sibling tools like browser_get_all_pages. However, it does not specify whether frames refers to iframes on the current page or all frames in the browser, leaving slight ambiguity.
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. The description does not mention prerequisites, scope (current page vs entire browser), or any exclusions, leaving the agent to infer usage from the tool 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?
With no annotations supplied, the description must carry the full burden of behavioral disclosure. It only says 'get all links' without explaining what is included (e.g., hidden or dynamic links), how the result is structured, or whether any side effects occur. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words, but it borders on under-specification. It is a single phrase that lacks structure or detail, which is not ideal for a tool in a large sibling group.
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 simplicity (no params, no output schema), the description should still clarify what 'links' refer to and what the return value looks like. The current description leaves too much to interpretation, making it incomplete for an AI agent to use reliably.
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 according to the baseline for 0-param tools, a score of 4 is appropriate. The description adds minimal extra meaning, but since there are no parameters to clarify, it does not need to go further.
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 '获取所有链接' (Get all links) clearly states a specific action of retrieving links, which is distinct from most sibling tools. However, it does not specify the scope (e.g., current page) or the format of the links returned, 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 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. Sibling tools like browser_get_by_text or browser_get_attribute are not referenced, and the description does not mention any context or exclusions.
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 full responsibility for behavioral disclosure. It does not explain what specific metrics are returned, whether a page must be open, potential side effects, or return format. This is a significant gap for a tool that queries browser internals.
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 short phrase with no waste, but it is under-specified. It essentially restates the tool name in Chinese, lacking the detail needed to understand what 'performance metrics' entails. It is concise but not informative enough.
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, no annotations, and a vague description, the tool is not adequately explained. Users cannot infer what metrics are retrieved, how they are formatted, or when this tool should be used relative to browser_get_coverage or other getters. The description is incomplete for a tool that likely returns complex performance 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 input schema has zero parameters, so the baseline is 4. The description does not need to add parameter semantics because there are none to explain.
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 '获取性能指标' (Get performance metrics) clearly states the verb (get/fetch) and resource (performance metrics). It is specific enough to distinguish from sibling tools like browser_get_coverage, though it lacks additional scope details.
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 are no mentions of prerequisites, context, or exclusions. The description is purely functional with no usage context.
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 does not disclose the return format (e.g., boolean), whether it waits for visibility, what happens if the element is not found, or any side effects. The behavioral traits are entirely opaque beyond the basic action.
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 short sentence, highly concise and front-loaded. Every word earns its place, with no extraneous 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?
Although this is a simple tool, the complete absence of behavioral details (return value, exceptions, waiting behavior) and lack of output schema make the description inadequate. The agent cannot fully predict the tool's behavior or interpret results.
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 does not elaborate on the 'selector' parameter. The agent is left with only the parameter name and type, with no explanation of what constitutes a valid selector or how it relates to visibility checking.
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 '检查元素可见性' (Check element visibility) uses a specific verb and resource, clearly indicating the tool checks element visibility. This distinguishes it from sibling tools like browser_is_enabled and browser_is_checked.
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. It simply states the action without context, prerequisites, or exclusions, leaving the agent to infer usage.
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. It only paraphrases the tool name without disclosing any additional behavior, side effects, or requirements (e.g., whether a key must have been pressed first).
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 with no filler, earning every word. However, it is slightly terse and could be enriched with minimal usage hints 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?
The tool is simple, but the description lacks usage context, parameter semantics, and behavioral caveats. Given no annotations or output schema, it is incomplete for an agent to use confidently, especially with many sibling tools.
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?
The schema has one required 'key' parameter with no description and 0% schema coverage. The tool description does not mention the parameter or explain valid values (e.g., keyboard codes vs characters), leaving the agent without 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?
The description '释放键盘按键' clearly states the action (release) and the resource (keyboard key). It is specific and distinguishes this tool from siblings like browser_keyboard_down, which performs the opposite action.
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, such as mentioning that it pairs with browser_keyboard_down or that it is for key combinations. There is no explicit context or alternative mention.
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 does not mention that this is a read-only operation, what the return value contains (e.g., width and height), or any units. Critical information about the output is missing.
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 extremely concise, consisting of a single short phrase with no wasted words. It is appropriately sized for such a simple operation, though it could benefit from a bit more detail.
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 no description of the return value, the tool is incomplete. For a getter, it is essential to know the format and meaning of the result (e.g., an object with width/height). The description also lacks context about how it applies to the current page or browser viewport.
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 takes zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and the schema confirms no parameters exist. Nothing is lacking in this dimension.
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 '获取视口大小' (Get viewport size) clearly states the action (get) and resource (viewport size). It is specific and easily distinguishable from the sibling browser_set_viewport_size, though it does not explicitly mention the alternative.
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 usage guidance is provided. The description does not state when to use this tool, when not to use it, or mention alternatives. The intended context is only implied by the verb and resource.
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 one important behavioral trait (no keyboard events), which adds value beyond the name. However, it does not mention other effects such as whether existing text is replaced, whether focus is required, or what events (if any) are triggered.
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 is front-loaded with the core action and key differentiator. No wasted words.
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 is simple, but the description lacks usage context, return value, and details about its effect beyond 'insert'. Without annotations or an output schema, the agent may not know how to correctly invoke it (e.g., whether focus is needed, whether it appends or replaces). The differentiator is useful, but overall incomplete for a browser automation tool.
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%, and the description does not add any meaning beyond the parameter name 'text' and its string type. The text to insert is obvious, but no extra semantics are provided (e.g., format, length limits, encoding).
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 (insert text) and adds a key differentiator: it does not trigger keyboard events. This distinguishes it from sibling tools like browser_type or browser_fill, though it could be more explicit about the target element (e.g., focused element).
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. It mentions the 'no keyboard events' feature but does not state use cases, prerequisites, or when to prefer it over browser_type, browser_fill, or other input methods.
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 the full burden but only repeats the tool name. It does not disclose whether this clears all cookies in the browser context, whether it affects persistent storage, or any destructive side effects, leaving the agent without important 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?
The description is a single short phrase with no filler or redundant content. It is front-loaded and appropriately minimal for a tool with no parameters, though it could be slightly more informative.
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 description is too minimal for a browser mutation action. It lacks context about the scope of the cookie clearing, relationship to other storage operations, and any caveats. With no annotations and no output schema, the agent is left without essential operational details.
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 complete and the description has no parameter semantics to add. The baseline of 4 applies.
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 (清除Cookie = clear cookies) with a specific verb and resource. It distinguishes from siblings like get_cookies and set_cookies, though the text itself is essentially a restatement of the tool name and provides no additional scope context.
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?
There is no guidance on when to use this tool versus alternatives such as browser_set_cookies, browser_get_cookies, or browser_clear_local_storage. The agent is given no decision-making context.
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 available, the description carries the full burden of behavioral disclosure. It only states the basic action without revealing what the list contains (e.g., page IDs, URLs), whether it includes all windows/tabs, or if there are any side effects. This is insufficient for a tool with no output schema.
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 short, front-loaded phrase with zero wasted words. For a getter with no parameters, this level of conciseness is appropriate and earns a high score.
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 annotations, no output schema, and a very terse description. The description does not specify the return format or any behavioral nuance, leaving the agent to guess what 'all pages' means and how to use the result. This is incomplete for a tool that provides no other structured metadata.
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 is an empty object with 100% coverage. Per the rubric, a 0-parameter tool gets a baseline of 4 since there are no parameter semantics to clarify. The description adds no parameter information because none exists.
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 a verb ('get') and a resource ('all pages list'), making the purpose reasonably specific. However, it does not explicitly differentiate this from sibling getters like browser_get_current_url or browser_get_frames, though the resource is distinct enough to avoid confusion.
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 context, exclusions, or relationships to other page-management tools such as browser_switch_page or browser_new_page.
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 the full burden of behavioral disclosure, but it only states that the tool gets an element attribute. It does not mention return value format, error behavior (e.g., when selector or attribute is invalid), or whether the attribute value is a string or null. This lack of detail is a gap for a read operation.
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, short phrase with no wasted words. It is front-loaded and immediately clear. However, it essentially restates the tool name, so it earns a 4 rather than 5 for adding minimal new structural 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?
Given the simplicity of the tool and the lack of an output schema, the description should explain at least what is returned (the attribute value) and any caveats about selector usage. It does neither, making the description incomplete for an agent that lacks prior knowledge of browser automation conventions.
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 0%, so the description must compensate. It implicitly maps 'element' to the 'selector' parameter and 'attribute' to the 'attribute' parameter, which provides basic semantics. However, it does not specify the selector syntax (CSS/XPath) or attribute name expectations, so the compensation is minimal but not absent.
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 '获取元素属性' ('Get element attribute') clearly states the action (get) and the resource (element attribute), distinguishing it from sibling getters like browser_get_text, browser_get_html, and browser_get_title. The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_get_text or browser_get_html. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the 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 must cover behavioral traits. It only states the basic function, omitting details like whether it returns the first match, what happens if no element is found, whether it waits for the element, or if it returns a locator handle. This is a significant gap for an interactive browser 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, short sentence that is front-loaded and to the point. No wasted words, and it immediately communicates the essential action and criteria.
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?
For a tool with no output schema and no annotations, the description is insufficient for an agent to use it reliably. It lacks usage context, return value expectations, and error behavior. While it names the key parameter, it does not provide enough to distinguish effective use from misuse.
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?
With 0% schema description coverage and only two parameter names ('name' and 'role'), the description adds minimal value. It clarifies that the tool locates by 'role' but does not explain the purpose of the 'name' parameter (e.g., accessible name filter). The description does not compensate for the lack of schema 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 '通过角色查找元素' (Find element by role) clearly states a specific action (find element) and a specific method (by role), distinguishing it from sibling tools like browser_get_by_text or browser_get_by_label. It conveys the core purpose without ambiguity.
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 information about when to use this tool instead of alternatives. There is no mention of ARIA roles, accessibility considerations, or comparison with other get_by_* locators, leaving the agent without 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only states the basic action, but does not mention what happens for missing elements, whether multiple matches are handled, what the return format is, or whether it waits for the element. This leaves significant behavioral ambiguity 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, consisting of a single clear phrase that directly states the purpose. It wastes no words and is appropriately brief for a simple getter tool.
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 lack of annotations, output schema, and parameter explanations, the description is not complete enough. It fails to cover usage trade-offs, edge-case behavior, or selector expectations, leaving the agent under-informed for reliable invocation in nuanced contexts.
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 coverage is 0%, so the description must compensate for parameter meaning, but it does nothing of the sort. The only parameter 'selector' is left undescribed; the agent must infer its format (CSS, XPath, etc.) solely from the name, which is insufficient.
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 a specific action (get) and resource (element text), which distinguishes it from sibling getters like browser_get_html, browser_get_attribute, and browser_get_input_value. The verb+resource structure makes the tool's purpose immediately unambiguous.
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 browser_get_by_text, browser_get_attribute, or browser_get_input_value. There are no exclusions, prerequisites, or context hints to help an agent choose correctly.
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?
There are no annotations provided, so the description must fully describe behavioral traits. It only restates 'check connection status' without adding any detail about side effects, return type, error conditions, or what 'connected' refers to. This is essentially a tautology of the tool name and provides no extra 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, short sentence with no extraneous content. It is front-loaded and each word contributes to meaning. For a tool of this simplicity, the conciseness is ideal.
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 low complexity (no parameters, likely a simple boolean check), the description is minimally adequate. However, it does not explicitly state what the return value represents or what 'connection' means in this context, and there is no output schema. A slightly richer description would remove ambiguity, but the tool is simple enough that this is a minor gap.
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 has 100% coverage (trivially). The description needs to add no parameter-level explanation. According to the baseline for zero parameters, a score of 4 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 action (check) and the resource (browser connection status). It is distinct from siblings like browser_launch or browser_get_version by focusing on connectivity. However, it lacks explicit detail on what 'connection' means or what the result will be, which is only implied by the tool name.
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. It does not mention any preconditions, related tools, or scenarios where this check is appropriate. Without any exclusions or context, the agent receives no help in deciding when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose side effects. It only says 'close browser' without mentioning that it closes all pages, terminates the connection, or may cause data loss. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise phrase '关闭浏览器' communicates the action with zero wasted words. It is appropriately sized for a parameterless, simple operation.
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 simplicity (no params, no output schema), the description is fundamentally adequate but lacks behavioral context such as irreversible effects or what happens to open pages. This leaves some ambiguity 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?
The tool has no parameters and the schema already provides 100% coverage (empty properties). With zero parameters, the description need not add parameter details; baseline 4 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 states '关闭浏览器' (close browser), a specific verb and resource. It clearly distinguishes from sibling 'browser_close_page' by targeting the entire browser rather than a page.
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 browser_close_page. It does not mention end-of-session context or whether this is required after closing all pages.
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 burden of behavioral disclosure. It only lists high-level features (device simulation, video recording, tracking) without explaining side effects, return values, browser instance lifecycle, or prerequisites. '启动' implies action but gives no insight into what actually happens or what the agent should expect.
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 core action. Every word earns its place, and it avoids redundancy with the schema.
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?
This is a complex tool with 7 optional parameters, a nested viewport object, and no output schema or annotations. A launch operation should clarify return values, whether a browser context is created, and how it relates to subsequent sibling tools. The terse description leaves too much unstated for an agent to safely and correctly invoke it.
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 57%, leaving headless, viewport, and browserType undocumented. The description mentions device simulation, video recording, and tracking, which map to deviceName, recordVideo, and recordTrace, but these already have schema descriptions. It adds no meaning for the undocumented parameters and does not compensate for the coverage gap with any new 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 the action and resource: '启动浏览器' (launch browser). It also distinguishes itself from sibling tools by highlighting unique launch-time capabilities like device simulation, video recording, and tracking, making it unmistakable from operations on existing browser contexts.
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 that this is the entry point for browser interaction, but it does not explicitly state when to use it, whether it should be called before other browser_* tools, or mention any alternatives. The sibling list makes it obvious enough, but explicit guidance is missing.
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 the full burden of behavioral disclosure. It only states the action, but does not disclose that clearing localStorage is irreversible, affects the current origin, or could impact page state. The destructive nature is implied but not elaborated.
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 exceptionally concise, using only two words with no wasted text. It earns its place by being direct. However, it is a fragment rather than a sentence, and the use of Chinese may reduce clarity for some agents, so it is not a full 5.
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 (no parameters, no output schema), the description is mostly complete in terms of what it does. However, it lacks behavioral context such as scope (current origin), irreversibility, and potential side effects. For a mutation tool, this is a noticeable gap.
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 trivially 100%. Per the rubric, 0 params warrants a baseline of 4. The description does not need to explain parameters because there are none.
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 '清除LocalStorage' directly translates to 'Clear LocalStorage', which clearly states the specific verb (clear) and resource (LocalStorage). This distinguishes it from sibling tools like browser_get_local_storage or browser_set_local_storage. The 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description only states the action without any context on when to use this tool versus alternatives like browser_clear_cookies or browser_get_local_storage. There are no explicit conditions, prerequisites, or 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 exist, so the description carries the burden. It discloses the destructive nature ('clear') and scope ('all logs'), but does not detail exactly which log types are affected or whether the action is irreversible. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, perfectly sized for a parameterless tool. It is front-loaded and free of superfluous content.
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 no-parameter clear operation, the description is mostly complete, but it could benefit from specifying which log categories (console, network, request/response) are cleared to remove 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?
The tool has no parameters, so the empty schema is fully covered. The description provides all necessary contextual meaning; no parameter descriptions are required.
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 uses a specific verb '清除' (clear) and resource '所有日志' (all logs), clearly distinguishing it from the many get-log sibling tools. It is concise and unambiguous in intent.
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; it simply states the action. There is no mention of prerequisites, conditions, or that it should be used after inspecting logs.
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 present, so the description must carry the full behavioral disclosure burden. It only restates the purpose and does not mention return format, encoding, or side effects, offering minimal transparency for a read 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 a single concise phrase with no filler words. It is appropriately sized for the tool's simplicity and immediately conveys the core purpose.
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 zero parameters and no output schema, the description is minimally viable but lacks return details (e.g., whether it returns full serialized HTML or just body content). Given the rich set of sibling tools, slightly more context 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 tool has zero parameters, earning a baseline of 4. There is no schema coverage gap to compensate for, and the description adds no parameter-related meaning 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 '获取页面HTML' clearly states the action (获取/get) and resource (页面HTML/page HTML). It distinguishes itself from sibling tools like browser_get_text or browser_get_title, which target different content types.
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. Among many sibling getters (get_text, get_links, get_current_url), the description gives no context or exclusions, leaving the agent to infer intended use.
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 is solely responsible for disclosing behavior. It only states '获取浏览器版本' without mentioning the return format, potential errors, or any prerequisites, offering insufficient 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 entire description is a single short phrase, making it extremely concise and front-loaded with the core action. There is 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 is functional for a simple getter, but it does not specify the output type or format, and there is no output schema to supplement this. For a zero-parameter tool, this is a minor but noteworthy gap.
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 an empty object with zero parameters, meaning there is nothing to explain. The baseline score of 4 applies because the description adds no parameter semantics, but none are needed.
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's purpose as retrieving the browser version. This specific verb+resource combination distinguishes it from all sibling tools, none of which target version retrieval.
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 or any exclusions. While the purpose implies use when needing the browser version, no contextual or alternative-specific information is given, resulting in minimal guidance.
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 the full burden of behavioral disclosure. It does not mention side effects, whether collected coverage is retained or discarded, whether it affects future navigation, or whether it is reversible. For a state-changing operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. No filler or redundant information exists, making it highly efficient and 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?
The tool is simple (0 params, no output schema), but the description lacks behavioral context such as when to use it, what happens to existing coverage data, and whether it must be paired with a preceding start action. It is adequate for a minimal stop command but leaves notable gaps in state management expectations.
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, so the baseline is 4. The description adds no parameter details, but none are needed. The action is self-contained.
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 action (stop) and the resource (code coverage collection). It is specific and unambiguous, distinguishing it from sibling tools like browser_get_coverage, which retrieves coverage rather than halting its collection.
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, what conditions prerequisite it, or how it relates to other coverage tools. It simply states the action without context, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without any details about prerequisites, error behavior, return format, or side effects, offering no additional transparency beyond the tool name.
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, highly concise phrase that directly states the tool's purpose. Every word earns its place, and there is no wasted text or repetition.
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 parameterless getter, the description adequately conveys the core function. It does not detail return values or edge cases, but the simplicity of the tool makes this less critical. Given no annotations or output schema, it is reasonably 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?
The tool takes zero parameters, so the input schema is trivially complete. The description does not need to explain parameter semantics, and 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 '获取当前URL' (Get current URL) uses a specific verb 'get' and a clear resource 'current URL', unambiguously distinguishing it from sibling tools that retrieve other page properties like title or HTML.
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 alternative guidance is provided. The purpose is clear enough that an agent can infer it is for retrieving the current URL, but there is no mention of when not to use it or comparison with similar getter 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 are provided, so the description carries the full burden. It simply states the action without disclosing behavioral traits such as whether it reloads from cache, discards page state, or waits for load. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no wasted words. It is front-loaded and appropriately sized for a trivial operation.
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 reload operation with no parameters, the description is adequate to convey the core action. It could optionally mention side effects or return values, but these are not necessary for the tool's simplicity.
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 0 parameters and an empty schema, so the baseline of 4 applies. The description adds no parameter info, but none is needed since the schema is already complete.
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 '刷新页面' (refresh page) clearly states a specific action (refresh) and resource (page). It is unambiguous and distinguishes from sibling navigation tools like browser_go_back and browser_go_forward.
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. It does not mention any context, prerequisites, or exclusions, leaving the agent without decision support.
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:

[![playwright-browser-skill MCP server](https://glama.ai/mcp/servers/91fapiao-cn/playwright-browser-skill/badges/card.svg)](https://glama.ai/mcp/servers/91fapiao-cn/playwright-browser-skill)

Score Badge

Copy to your README.md:

[![playwright-browser-skill MCP server](https://glama.ai/mcp/servers/91fapiao-cn/playwright-browser-skill/badges/score.svg)](https://glama.ai/mcp/servers/91fapiao-cn/playwright-browser-skill)

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/91fapiao-cn/playwright-browser-skill'

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