Browser Pool MCP

by hy-2005

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation3/5
Most tools have distinct purposes, but browser_take_screenshot and browser_screenshot are explicit aliases, causing ambiguity. Additionally, browser_drag and browser_drop could be confused as both relate to drag-and-drop operations.
Naming Consistency3/5
The majority of tools follow a browser_verb pattern (e.g., browser_navigate, browser_click), but there are exceptions like browser_snapshot, browser_console_messages, and browser_network_requests which use nouns. The pair browser_take_screenshot and browser_screenshot also breaks consistency.
Tool Count3/5
At 25 tools, the server is on the heavy side but still plausible for a comprehensive browser automation tool. However, the presence of a duplicate screenshot tool and a test tool (pool_test) suggests some redundancy.
Completeness4/5
The tool set covers a wide range of browser actions: navigation, interaction, screenshots, snapshots, tab management, dialog handling, file upload, and more. Minor gaps exist (e.g., no explicit cookie management or scrolling) but core workflows are well covered.
Average 2.6/5 across 25 of 25 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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, the description carries the full burden, but it reveals nothing about behavior: it does not mention that it moves forward in browser history, what happens when there is no forward history, or any side effects. The description is practically empty.
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—just one word—which may seem concise, but it is under-specified rather than appropriately concise. It fails to convey any useful meaning 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?
Despite the simple tool and one well-documented parameter, the description is insufficient. An agent cannot reliably determine that this tool navigates forward in history, what prerequisites exist, or how it behaves when no forward entry is available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information, but the input schema fully covers the only parameter (_agent_id) with a clear explanation. According to rubric, high schema coverage yields a baseline of 3, and the description does not detract.
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 "前进" simply means "forward" and is essentially a translation of the tool name. It does not state the verb/resource (e.g., navigate browser history forward) nor does it distinguish from siblings like browser_navigate_back or browser_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as browser_navigate_back or browser_navigate. No context 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 full burden for behavior disclosure. It offers no information about waiting semantics, timeouts, polling behavior, or what happens when conditions are not met. The schema parameter descriptions hint at 'wait for text to appear/disappear' but the description itself adds nothing.
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 under-specified rather than concise. '等待条件' is two characters that convey no actionable information, and the structure is a bare phrase rather than a clear explanatory sentence.
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 4 parameters, no output schema, and no annotations. The description fails to explain return values, error handling, or the waiting mechanism. It is inadequate for an agent to select and invoke this tool correctly, especially given sibling tools that require similar context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself provides no parameter information, but the schema descriptions for 'text', 'textGone', and 'time' are present. However, the relationship between these parameters (e.g., time as a timeout vs. fixed wait) is not clarified by the description.
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 vague noun phrase meaning 'wait condition' and does not state the tool's action or resource. It is essentially a restatement of the tool name 'browser_wait_for', providing no distinction from sibling browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives like browser_click or browser_navigate, nor does it mention 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?
With no annotations provided, the description carries the full burden of disclosing behavior. '后退' gives no information about what happens when invoked, such as navigating to the previous page, whether it requires a loaded page, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified: a single word '后退' is not an appropriately sized description. It lacks the minimal phrase 'navigate back in browser history' that would make it useful. This is not concise; it is incomplete.
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, a minimal description like 'Navigate to the previous page in browser history' would suffice. The actual description provides no context about the action, making it inadequate even for a straightforward navigation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter _agent_id is fully documented in the input schema with a clear Chinese description about isolation keys. Since schema coverage is 100%, the description adds no additional meaning but the baseline of 3 is appropriate because the schema already handles the semantics.
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 '后退' ('go back') essentially restates the tool name 'browser_navigate_back'. It does not specify a verb+resource beyond what the name already implies, and it fails to distinguish itself from siblings like browser_navigate_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?
There is no guidance on when to use this tool versus alternatives such as browser_navigate_forward or browser_navigate. No context is provided about browsing history or applicable scenarios.
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, and the description offers no behavioral details. It does not disclose whether the upload is synchronous, whether it waits for completion, supports multiple files (though the schema implies an array), or any side effects on the browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it is under-specified rather than concisely informative. It fails to convey anything beyond the tool's name, making the brevity a deficiency rather than a quality.
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 no output schema and no annotations, the description must carry the full burden of explaining the tool's behavior. It does not mention return values, error conditions, or the role of the '_agent_id' isolation key, leaving the agent without enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'paths' and '_agent_id' having descriptive text. The tool description adds no value beyond the schema, so the baseline score of 3 applies.
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 'upload file', which is a direct restatement of the tool name 'browser_file_upload'. It provides no differentiation from other browser actions like browser_drop or browser_navigate, and lacks any detail about the browser context.
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 guidance on when to use this tool versus alternatives such as browser_drop. There is no mention of prerequisites like an active file input, page state, or how it fits into a browser automation flow.
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 merely says 'test async response' with no information about side effects, return value, errors, or whether it is safe. This is essentially no 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 and front-loaded, but it is under-specified rather than concise. It contains only a vague phrase with no structured information, so it does not earn its place as a useful specification.
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 this tool has one parameter, no output schema, no annotations, and sits among complex browser automation tools, the description is completely inadequate. It provides almost no contextual information about what the tool does, when to use it, or what 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?
Schema description coverage is 0%, and the description does not mention or explain the 'message' parameter. Although the param is named intuitively, the tool description offers no guidance on what to pass or expected format, so it fails to compensate for the schema gap.
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 'test asynchronous response,' which names a verb and object but remains vague about what the tool actually does. It does not clearly distinguish itself from the sibling browser automation tools, though its purpose is not 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?
The description provides no guidance on when to use this tool versus alternatives. There is no context about typical scenarios, prerequisites, or exclusions, leaving the agent without useful selection 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?
With no annotations, the description must disclose behavioral traits, but it does not. It fails to state whether network requests are returned in a list, cleared after retrieval, or how the isolation key (via _agent_id) affects behavior. No side effects or return structure are mentioned.
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 omits essential details, making it insufficiently informative even though it is brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the tool returns or how network request activity is presented. For a simple tool, it still leaves major gaps in agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter _agent_id, which is fully documented in the schema. The description itself adds no additional parameter context, so the baseline of 3 applies.
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 '获取网络请求活动' (get network request activity) provides a verb and resource, clearly indicating the tool fetches network request-related data. However, it lacks specificity about scope (e.g., all requests, filtered) and does not differentiate from sibling tools like browser_console_messages or browser_snapshot.
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 this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent without direction on selecting it among the many browser inspection 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, so the description carries the full burden of disclosure. It only says 'alias' and gives no information about what the tool does beyond the name, any side effects, return values, or limitations. This is essentially no 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 extremely short, which could be considered concise, but it is under-specified rather than efficient. It leaves out essential information about the tool's purpose and usage, so it does not earn its place 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?
Despite the tool's relative simplicity, the description is inadequate. It fails to clarify the alias relationship, specify return behavior, or provide any context about when to use it relative to the many sibling browser tools. The name and schema alone are not enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (fullPage and _agent_id) have meaningful descriptions in the schema. The description adds no additional parameter semantics, but per the baseline for high schema coverage, a score of 3 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 '截图（别名）' means 'Screenshot (alias)', which identifies the tool's basic function (taking a screenshot) but adds only an ambiguous alias qualifier. It does not distinguish this tool from sibling tools like browser_take_screenshot or browser_snapshot, and the alias target is unnamed, leaving the purpose somewhat vague.
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 'alias' label hints that it may be an alternative name for another screenshot tool, but it never explicitly states which tool it aliases or when to prefer it, so the agent receives no actionable 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it offers none. It does not explain that 'accept' determines acceptance/dismissal, that promptText supplies input to prompt dialogs, or that a dialog must be open. The single generic verb 'handle' reveals nothing about side effects or requirements.
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 certainly concise and front-loaded. However, its brevity borders on under-specification rather than efficiency. The phrase contains no waste but also lacks substance needed for a standalone 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?
The tool has 3 parameters, no annotations, and no output schema. The description is minimal and fails to convey essential context such as what happens when a dialog is handled, whether it dismisses the dialog, or what the return behavior is. It is inadequate for an agent to invoke correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a description (accept: accept or reject; promptText: input text for prompt dialog; _agent_id: isolation key). The tool description adds no parameter meaning beyond schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '处理 alert/confirm 弹窗' uses a specific verb (handle) and resource (alert/confirm dialogs), clearly distinguishing it from sibling browser tools like click, type, and navigate. While 'handle' is somewhat generic, the resource is unambiguous and it is the only dialog-handling tool.
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 does not mention that it should be invoked when a dialog is present, nor does it specify any prerequisites or exclusions. The description is purely a purpose statement 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but says nothing about how the tool behaves. It does not mention whether messages are read from the current page, whether the console is cleared, what output format is expected, or any side effects. This is a critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase. It is front-loaded and to the point, but this brevity sacrifices essential detail, making it somewhat under-specified rather than efficiently concise.
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 and no output schema, this description is grossly incomplete. It fails to explain return value structure, filtering semantics, or how the tool interacts with the browser state, leaving the agent without enough information to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters (level and _agent_id) with descriptions, so the tool description does not need to repeat them. However, it also does not add any contextual information about the level filter, such as acceptable values, allowed combinations, or the default behavior when omitted.
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 (获取/retrieve) and resource (控制台消息/console messages), which effectively differentiates it from sibling tools like browser_network_requests. However, it lacks specificity about the exact scope (e.g., current page vs. all tabs) and what types of console messages are included.
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 instead of alternatives such as browser_network_requests or browser_snapshot. The description simply states what it does without any context about use cases, 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 must disclose behavioral traits. It does not state whether the tool waits for the drop, simulates drag events, works with iframes or shadow DOM, or what happens on failure. This is a serious gap for a complex browser interaction.
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 with no redundancy, but it is under-specified rather than concisely rich. While it is not verbose, the extreme brevity leaves out essential information, making it acceptable but not exemplary.
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 is responsible for explaining the tool's complete behavior. It fails to mention return values, side effects, waiting behavior, or error cases. For a moderate-complexity tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes start_selector and end_selector, including _agent_id. The description's 'element A' and 'element B' merely restates the schema's start/end relationship without adding new semantic value, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (drag) and the targets (element A to element B). It distinguishes itself from siblings like browser_drop through the verb 'drag', but it does not elaborate on whether this is a standard HTML5 drag-and-drop or a mouse event sequence.
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_drop. There is no mention of prerequisites, supported element types, or scenarios where drag is appropriate, leaving the agent without 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. It only states 'select an option in a dropdown,' which conveys the purpose but reveals nothing about side effects, return values, error handling, or whether the selection triggers events. There is zero additional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no redundant words. It is front-loaded with the core action and resource. However, it is under-specified in content, which slightly detracts from its value, but from a pure conciseness standpoint, it earns a high score for avoiding fluff.
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 and no annotations, and the description is extremely sparse. It fails to explain how to identify which dropdown to use, how the 'values' array works, whether multi-select is supported, or what happens after selection. Given the tool's complexity (4 parameters, browser-side effects), the description is grossly inadequate for an agent to use it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (element, ref, values, _agent_id) are documented in the input schema. The description adds no parameter-specific meaning, but per the rubric, high schema coverage warrants a baseline of 3. The description does not compensate or enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '在下拉框中选择选项' clearly states the action (select) and the target resource (dropdown box). It is specific enough to understand the tool's basic purpose and distinguishes itself from siblings like browser_click or browser_type by focusing on dropdown selection. However, it doesn't explicitly contrast with sibling tools or mention alternative approaches, so it falls short of 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention conditions for use, prerequisites, or situations where this tool is preferred over other browser interaction tools. There is no explicit or implicit usage guidance beyond the bare action itself.
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 disclose behavioral traits. It only states the click action and parameter meanings, omitting side effects, navigation waits, or error conditions. This leaves the agent without critical safety information for a potentially mutating 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, front-loaded sentence. Every word carries meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool, the description is incomplete; it lacks behavioral context, usage alternatives, and return value expectations. Without annotations or output schema, the agent cannot anticipate side effects like navigation or form submission. However, the parameter clarification is somewhat helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates the schema's parameter meanings ('element = a11y 引用, ref = CSS 选择器') but adds no new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks an element ('点击元素') and distinguishes the two reference types (a11y reference vs CSS selector). This is a specific verb+resource combination that differentiates it from sibling interaction tools like browser_hover or browser_drag.
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 exclusions, prerequisites, or scenarios where browser_type or browser_hover would be 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 present, so the description carries the full burden of disclosing behavior. It only states 'press keyboard key' with no information about focus requirements, key combinations, side effects, or what happens after the key is pressed.
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 redundancy or filler. It is appropriately sized for a simple tool, front-loading the core action.
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, no output schema, and only 2 parameters, the description is incomplete. It lacks behavioral context, usage conditions, and any explanation of the effect of pressing a key, which an agent would need to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'key' and '_agent_id' described in the input schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 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 '按下键盘按键' (press keyboard key) clearly states the tool's action with a specific verb and resource. It is distinct from mouse-based siblings like browser_click, though it does not explicitly differentiate from browser_type (which types text).
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 alternatives like browser_type or browser_click, nor any prerequisites or conditions.
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 'hover' without detailing effects, whether it waits for actionability, failure behavior, or any side effects. This is insufficient for a tool with no prior context.
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 short and free of fluff, which is efficient, but it does not provide any structured information or elaboration. It is concise to the point of being sparse, rather than optimally packaged.
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 action but the presence of many sibling tools and no output schema, the description is too minimal to be complete. It lacks guidance on usage context, behavioral expectations, and how it differs from similar actions, making it inadequate for fully informed tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (ref, element, _agent_id), including a detailed explanation for _agent_id. The tool description adds no extra meaning beyond this, so a baseline score of 3 is appropriate given high schema coverage.
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 (hover) and the target (element), making the tool's purpose immediately understandable. It distinguishes from siblings like browser_click by the specific verb, though it lacks additional scope or 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 such as browser_click or browser_drag. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent without decision-making support.
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?
Annotations are absent, so the description carries the full burden. It only repeats the action enum from the schema and does not disclose side effects (e.g., what closing a tab does, whether selecting is required before interacting, or how _agent_id isolates browser sessions).
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 short and front-loaded, but it is under-specified rather than efficiently complete. It is concise but sacrifices essential behavioral context for a multi-action 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?
With no annotations, no output schema, and three parameters involving multiple action modes and a session isolation key, the description is insufficient. It does not explain return values, per-action index requirements, or the effect of _agent_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters action, index, and _agent_id are already documented in the schema. The description adds no additional meaning; it merely restates the action values already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (tabs) and the operation (manage) while enumerating the four actions list/new/close/select. This distinguishes it from sibling tools like browser_navigate or browser_click, though the verb 'manage' is somewhat generic.
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_navigate, browser_close, or browser_get_url. The action list implies basic usage, 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?
No annotations are provided, so the description bears full responsibility for disclosing safety and side effects. It fails to mention that executing JavaScript can modify the page, trigger network requests, cause navigation, or otherwise disrupt the browser state. The _agent_id isolation mechanism is also not mentioned in the description, leaving agents unaware of potential cross-agent contamination.
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 containing no wasted words. It is appropriately sized for a tool with a straightforward action, though the brevity comes at the cost of explanatory depth. Structure is fine; it's just minimal.
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 two parameters, no output schema, and no annotations, the description must compensate by explaining return values, side effects, and the impact of _agent_id. It does none of this. For a JavaScript execution tool that can arbitrarily affect the page, the lack of behavioral context makes it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (100% coverage), including the function string and _agent_id. The description adds no extra meaning beyond what the schema already provides; it merely repeats '函数字符串' from the function parameter. With full schema coverage, the baseline of 3 applies, and no additional semantic enrichment is present.
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 the verb '执行' (execute) with a clear resource 'JavaScript（函数字符串）' in the page, which unambiguously states the tool's function. It distinguishes itself from sibling tools like browser_navigate or browser_click, but does not explicitly name alternatives or contrast with them, so it stops short of a 5.
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_snapshot. It simply states what it does without any context for selection, making it a bare functionality disclosure with no implicit or explicit 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, so the description carries full responsibility for behavioral disclosure. It only states the primary action and does not mention what happens if no page is open, whether the operation has side effects, or what the return format is. This leaves important behavioral aspects undisclosed.
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 unnecessary words. For a simple getter tool, this level of conciseness is appropriate and efficient. It earns full credit for clarity without being verbose.
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 and the rich schema description for the only parameter, the description is somewhat adequate. However, since there is no output schema, the description could have mentioned return values or edge-case behavior (e.g., empty string if no page). This missing context prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters, with the single _agent_id parameter having a clear description about isolation behavior. The tool description adds no additional parameter details, but per the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前页面 URL' clearly states the specific action (get) and resource (current page URL). It is unambiguous and effectively communicates the tool's purpose, though it does not explicitly distinguish it from sibling tools. Since the tool name itself is already explicit, this description is sufficient.
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 edge cases, prerequisites (like having a page loaded), or exclusions. The usage context is only implied by the tool's obvious purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注释，描述仅说明'导航到 URL'，未披露任何副作用、是否需要等待页面加载、是否影响当前浏览器状态等。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
单一短句，无冗余，信息密度高但过于简洁。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具简单但缺少对返回值、使用场景、与兄弟工具关系等说明；无输出 schema，需描述补充。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema 覆盖率 100%，两个参数都有描述；描述本身未额外解释参数信息。
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?
描述为 '导航到 URL'，明确了动词和资源，但与兄弟工具（如 navigate_back/forward）没有明确区分，只是通过 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?
没有任何关于何时使用此工具、何时使用替代工具的说明；没有提及像 browser_navigate_back 等兄弟工具。
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 'resize browser window size' with no information about side effects (e.g., affecting subsequent screenshots or responsive layout), prerequisites (e.g., browser must be open), or error handling. The description adds no behavioral context beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant or unnecessary information. It is appropriately sized for a straightforward resize operation, front-loaded with the essential meaning.
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 and no output schema, the description should provide more context about how resizing affects the browser session, when to use it, and any limitations. It currently only states the action, leaving the agent without enough information to fully understand the tool's role in the browser workflow. The schema descriptions help for parameters but not for the tool's broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a Chinese description (width, height, and a detailed explanation of _agent_id). The description itself does not add any additional meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
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 (resize) and resource (browser window size). It distinguishes from sibling browser tools like navigate, click, and type, which perform different actions. However, it is essentially a restatement of the tool name with minimal additional detail, so it lacks the specificity of higher-scoring descriptions.
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 such as resizing before taking a screenshot or how it interacts with other browser tools. No exclusions or alternative tool recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight for disclosing behaviors. It only mentions the default of fullPage, which is already in the schema. It does not disclose output format, whether it saves a file, return value, or any side effects, 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 concise with zero wasted words. It is front-loaded and appropriately brief for a simple tool, though it repeats schema information rather than adding new 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 no output schema and no annotations, the description should explain the tool's return value and context of use. It only states the default fullPage setting, leaving critical information missing for a screenshot tool that likely returns an image or path. It also fails to clarify distinction from sibling 'browser_screenshot'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing full parameter details. The description's mention of '默认 fullPage=false' just repeats the schema's own description, adding no additional meaning. Baseline 3 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 tool performs a screenshot ('截图') and notes the default fullPage behavior. However, it does not differentiate from the sibling tool 'browser_screenshot', so it lacks explicit sibling 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 alternatives like 'browser_screenshot' or other browser tools. There is no mention of 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'input text' and does not mention whether the field is cleared first, whether it focuses the element, how the submit parameter behaves, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or repetition. It is efficient, though it lacks structured detail beyond the bare action statement.
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 5 parameters and no output schema or annotations, the one-line description is insufficient. It does not clarify behavior, return values, or how the two element-related parameters are intended to be used, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning and notably leaves the relationship between 'element' and 'ref' unexplained, but the schema already documents each parameter's basic purpose.
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 ('输入文本' / input text) and the target ('元素' / element), giving a specific verb+resource pair. However, it does not distinguish itself from sibling tools like browser_press_key or browser_click, so it misses some 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_press_key, browser_file_upload, or browser_click. There are no exclusions or context clues about the preferred use case.
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 states the action 'close' without disclosing whether it is destructive, irreversible, or how it affects tabs, session state, or other agent activities.
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 direct and front-loaded. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the parameter is documented in the schema, the description lacks behavioral context such as side effects, return behavior, or relationship to sibling tools. It provides barely more than the tool name itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole parameter _agent_id, which already explains its purpose and default behavior. The description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('关闭' = close) and the resource ('该 agent 的浏览器' = this agent's browser), distinguishing it from navigation, inspection, and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_drop or pool_test. The description does not mention prerequisites, typical scenarios, 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 names the action but does not describe side effects, what the 'selector' targets (drop point vs. element), whether DOM changes occur, or what happens on completion. This is too opaque for a browser automation 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 concise sentence that is front-loaded with the action and resource. No filler or redundant content.
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 and no output schema, the description is under-specified. The required 'selector' is ambiguous—does it identify the element to drop or the drop target? There is no mention of pairing with browser_drag or post-condition behavior, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions for 'selector' and '_agent_id'. The tool description itself adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '放下被拖拽的元素' clearly states the action ('drop') and the resource ('the dragged element'), and it contrasts with sibling tool browser_drag. However, it lacks explicit scope or context about the drop target, so it stops short of a fully specified purpose.
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 use case is implied: '被拖拽的元素' (the dragged element) presupposes a prior drag operation, likely with browser_drag. However, there is no explicit guidance on when to use this tool vs. alternatives, nor 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 are provided, so the description carries the full burden of behavioral disclosure. It only states the snapshot is structured and LLM-friendly, without covering potential side effects, permissions, or the exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose and output nature. It is front-loaded and contains no filler.
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 and no output schema, the description is too minimal. It does not explain what 'accessibility snapshot' precisely includes, when it should be used, or any behavioral details, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single optional _agent_id parameter, so the baseline is 3. The description adds no additional semantic detail beyond what the schema documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a page accessibility snapshot and emphasizes it is structured and suitable for LLM reading. This distinguishes it from sibling tools like screenshots or console messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like browser_take_screenshot or browser_console_messages. It lacks any when-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation via the verb 'view', but beyond that, it provides no additional behavioral context—no mention of output contents, side effects, or limitations. Since there are no annotations, the description carries the full burden but only delivers the bare minimum.
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 that is entirely front-loaded and contains no filler words, scoring high on conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with no parameters and no output schema, the description is minimal but adequate for basic understanding; however, it doesn't specify what status information is returned or how it is presented, leaving some 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 input schema has zero parameters, giving a baseline score of 4. The description adds context about 'by agent' which hints at the scope of the result, but since there are no parameters, there is nothing more to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '查看' (view) with clear resource '浏览器池状态' (browser pool status) and scope '按 agent' (by agent), which clearly distinguishes it from the sibling pool_test tool.
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; there is no mention of specific scenarios, prerequisites, or comparisons with pool_test or other browser tools.
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-pool-mcp MCP server](https://glama.ai/mcp/servers/hy-2005/playwright-pool-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hy-2005/playwright-pool-mcp)

Score Badge

Copy to your README.md:

[![playwright-pool-mcp MCP server](https://glama.ai/mcp/servers/hy-2005/playwright-pool-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hy-2005/playwright-pool-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hy-2005/playwright-pool-mcp'

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