DrissionPageMCP

by wxhzhwxhzh

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct actions like navigation, clicking, input, screenshots, and network listening. A few pairs (send_enter/send_key, screenshot/screenshot_as_file) are closely related, but descriptions make them distinguishable.
Naming Consistency3/5
The naming is predominantly snake_case verb phrases, but getInputElementsInfo and getSimplifiedDomTree break the convention, and input_by_xapth contains a typo. Overall it remains readable and mostly predictable.
Tool Count2/5
With 29 tools, the server feels over-scoped, especially with redundant screenshot/listener functions and an unrelated save_dict_to_sqlite. The count exceeds the comfortable range and could be reduced by consolidating similar tools.
Completeness4/5
Core browser automation workflows are covered: navigation, tabs, element interaction, JS/CDP, file transfer, screenshots, and network listening. Gaps like closing tabs or cookie management are workaroundable via run_js or run_cdp.
Average 3.2/5 across 29 of 29 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
Tool has no description.
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?
Tool has no 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?
Tool has no description.
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?
Tool has no 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?
Tool has no description.
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?
Tool has no 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 carries the full burden. It does not disclose whether the wait is blocking, if there is a maximum time, or what happens after the wait. The description adds no behavioral context beyond the bare fact of waiting, leaving the agent to assume the operational semantics.
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, so it is concise and front-loaded. However, the brevity is excessive, bordering on under-specification. It does not waste words, but it also fails to communicate essential information, making the conciseness less of a virtue.
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 wait tool, a description might reasonably be short, but the lack of annotations, output schema, and any behavioral or usage context leaves the description incomplete. It doesn't mention return value, blocking behavior, or typical use cases, which is surprising given the surrounding browser automation 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 coverage is 0% and the description only adds the unit 'seconds' implicitly. It does not explain the meaning of 'a' beyond that, nor does it give range constraints, defaults, or edge cases. The description adds minimal value over the schema, which only declares an integer with no description.
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 '等待a秒' (wait a seconds) states a verb and resource but is essentially a tautology – it repeats the tool name and parameter without explaining what waiting means in this context. It does distinguish from sibling tools (others are actions), but the purpose is vague and under-specified, lacking any clarification of what the wait accomplishes.
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 vs alternatives. The description provides no context such as 'use this to pause between actions' or 'use this after navigation to wait for page load', which would be expected given the sibling tools are browser automation 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?
Without annotations, the description carries the full burden for behavioral disclosure, but it only states the operation ('get version number') without mentioning side effects, return format, or whether permissions are needed. This provides almost no transparency into 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase, but it is so sparse that it borders on under-specification. It is not verbose, but it also doesn't provide enough substance to be considered well-structured.
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, the description should provide more context about what version is returned and what the tool is for. It is too minimal to fully inform an agent, though the tool's simplicity mitigates the issue somewhat.
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 trivially 100%. Baseline 4 is appropriate because there is nothing for the description to add regarding 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 '获取版本号' is a direct translation of the tool name 'get_version', restating it without adding specificity about which version (e.g., browser, library). This is a tautology, providing no new information 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 offers no guidance on when to use this tool, no alternative tools, or context. It is a bare phrase that doesn't explain scenarios, prerequisites, or when it might be preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects like focus requirements, key press/release behavior, or error handling. This lack of detail for a keyboard input tool 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no fluff, but it is under-specified for a tool with a confusing schema. It is concise but not sufficiently informative, earning a middle score.
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, the description is inadequate. It does not explain valid key values, how it differs from send_enter, or what happens when the key is invalid. Given the unusual const schema and lack of annotations, more detail is necessary.
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 required parameter 'key' with a const value that is a comma-separated list of keys, but no description. The description does not clarify that only one key should be chosen from the list, nor does it explain the const constraint. With 0% schema description coverage, the description fails to compensate.
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: send special keys to the current tab, using a specific verb and resource. It is distinct enough from sibling tools like send_enter because it mentions 'special keys' rather than just Enter, though it does not explicitly differentiate 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when send_key is preferred over send_enter or other input methods, 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?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It only mentions 'control browser download' and that it returns a result string. There is no mention of potential side effects (e.g., overwriting existing files), whether the download is blocking, or how the browser handles popups or redirects. This is a significant transparency gap for a browser automation 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 appropriately concise with a clear structure (args and returns in a docstring format). However, it is underwhelming because it omits essential behavioral and usage details, making it feel like an under-specified stub rather than a well-crafted minimal 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 absence of annotations and an output schema, the description should provide enough context for safe and correct invocation. It fails to explain what the return string actually contains, how errors are surfaced, or whether the download completes before returning. The parameter list is bare, leaving the tool incomplete for an agent to use without guessing.
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%, meaning the input schema provides no additional meaning beyond parameter names. The description merely lists the parameters (url, path, rename) without explaining formats, constraints, or edge cases (e.g., what 'rename' expects – a full filename or just a base name). This does not 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '控制浏览器下载文件到指定路径' (control browser to download file to specified path), which is a specific verb+resource action. It distinguishes itself from the sibling tool 'upload_file' by being the inverse operation. However, it lacks detail about what types of files or URLs are supported, preventing 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?
There is no guidance on when to use this tool versus alternatives like 'get' or 'run_js'. No prerequisites are mentioned (e.g., needing to connect or open a browser first via 'connect_or_open_browser'). The description simply states the action without any contextual or exclusionary 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 provided, the description carries the full burden of disclosing behavioral traits. It only says 'get guide' without mentioning return format, safety properties, side effects, or prerequisites. The agent is left without any behavioral context beyond the bare 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 short sentence, which is concise and front-loaded. It avoids unnecessary words. However, it is almost too sparse; while it earns its place as a statement of purpose, it provides no additional detail that would improve the score to 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?
Given the tool's simplicity (0 params, no output schema), the description is the only context available, but it is insufficient. It does not clarify what a 'code guide' is, what content the agent can expect, or how to use the result. This is minimally viable but leaves significant gaps for an agent unfamiliar with DrissionPage.
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. Since there are no parameters to document, the description does not need to add parameter meanings. The description accurately represents the tool's parameterless nature.
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 '获取 DrissionPage 代码指南' clearly states a specific action (get) and resource (DrissionPage code guide). It distinguishes from sibling tools, which are browser automation actions, by indicating an informational/help purpose. However, it does not elaborate on what the guide contains, leaving some ambiguity about the exact scope.
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 specify when to use this tool, what problem it solves, or how it relates to sibling tools. There are no alternative tool mentions or contextual signals to help an agent decide to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only discloses the primary action of stopping the listener. It does not explain the effect of the clear_data parameter, whether data is cleared by default, or any side effects. With no annotations, the description carries the full burden and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without unnecessary words. It is front-loaded with the core action, though it lacks structural detail about parameters or side effects, which is more related to other dimensions.
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 with one optional parameter, no output schema, and no annotations. The description is too brief to be complete; it fails to explain the clear_data parameter and what happens after stopping, leaving the agent without critical 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 has one parameter, clear_data, with no description, and the tool description does not mention it. Schema description coverage is 0%, so the description should compensate, but it fails to add any meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops listening to webpage data packets, using a specific verb and resource. It distinguishes from sibling tools like get_response_listener_data and listen_cdp_event by indicating a stop action.
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, what prerequisites are needed, or how it relates to alternatives. The description only states the action without context, leaving the agent without 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 states the core action but omits important behavioral details like whether the new tab is focused, what the return value is, or whether an already-open browser is required. It does not contradict any annotations.
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 filler. It conveys the essential action efficiently, though it is slightly terse for the necessary information it should include.
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?
There is no output schema and no annotations. The description does not explain return behavior, side effects, or prerequisites. Given that sibling tools include connection and page-management tools, the description is under-specified for an agent to understand the full 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?
The schema has 0% description coverage, and the parameter `url` is only implied by '打开一个网址' (open a URL). The description adds no format, constraints, or additional meaning beyond the schema's property name, so it fails to compensate for the lack of schema descriptions.
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: open a new tab and open a URL using the DrissionPage-controlled browser. It distinguishes itself from sibling tools like `get` or `wait` by specifying the new-tab-and-navigate behavior.
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, such as `get` or `connect_or_open_browser`. There is no mention of prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says the tool gets data collected by a CDP event callback, but does not explain return format, whether reading clears the data, side effects, or what happens if no listener is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is arguably too terse given the lack of output schema and prerequisite context, so it does not fully earn a 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 no parameters, no output schema, and no annotations. The description does not state what the return value looks like, whether the listener must be active, or any dependency on listen_cdp_event. For a retrieval tool, this is insufficiently 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 has zero parameters and the schema is empty (coverage 100% trivially). Since there are no params to explain, the description does not need to add parameter details, and the baseline for 0 params is 4.
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 '获取CDP事件回调函数收集到的数据' clearly states the tool retrieves data collected by CDP event callback functions, providing a specific verb and resource. It is distinct from siblings like 'listen_cdp_event' (which sets up listening) and 'get_response_listener_data' (which targets response listeners), though it does not explicitly name 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 usage guidance is provided. The description does not mention when to use this tool, prerequisites (e.g., needing to call listen_cdp_event first), or situations where an alternative 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that data is retrieved and returned as a list, but says nothing about whether data is consumed/cleared, whether a listener must be active, or any side effects. This leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that directly conveys the action and return type. Every word earns its place, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter details, the description is the sole informational source. It states 'return data list' but lacks critical context about prerequisites (active listener), behavior over time, or how this differs from sibling listener tools. The tool's name provides some context, but the description itself is incomplete for an AI agent to invoke correctly in the right situation.
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 properties, so there are no parameters to explain. Baseline of 4 applies because no parameter documentation is needed.
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 a clear verb 'get' and resource 'listener data' with an explicit return type ('data list'). However, it does not distinguish this from sibling tools like get_cdp_event_data or get_url_with_response_listener, which also retrieve listener-related data.
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 whether it requires an active listener or how it relates to listen_cdp_event or response_listener_stop. There are no exclusions or context clues.
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 disclose behavior, and it only states the basic side-effect of opening a tab and setting a listener. It does not explain what the tool returns, whether it waits for responses, how to retrieve captured data, or that the listener needs to be stopped/read separately. The mention of 'refresh' is also not backed by the schema, leaving behavior ambiguous.
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 compact and front-loaded with an action statement, followed by a scannable parameter list. Each line serves a purpose, except the unsupported 'refresh' entry, which adds noise. The trailing comma and lack of a clear return/result statement are minor structural drawbacks.
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 that sets up a response listener, the description is incomplete. It does not mention the follow-up workflow (retrieving captured data via get_response_listener_data, stopping via response_listener_stop), nor what the call returns. The schema does not have an output schema, and the description mentions a non-existent refresh parameter, making the contract unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's parameter explanations add value for tab_url, mimeType, and url_include. However, it also documents a 'refresh' parameter that does not exist in the input schema, which is misleading. No additional detail is given about URL format, filtering semantics, or mimeType usage beyond the schema's enum.
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 core operation: 'Open a new tab, set listener, visit tab_url'. This is a specific verb+resource sequence that aligns with the tool name and distinguishes it from simple navigation or generic listener tools. However, it does not explicitly differentiate from sibling tools like new_tab or listen_cdp_event.
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?
Usage is implied: use this when you need to open a tab and capture responses matching a mimeType/url filter. No explicit when-to-use or when-not-to-use guidance is given, and no alternatives are mentioned despite sibling tools like get_response_listener_data and response_listener_stop being closely related.
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 disclose side effects. It only mentions running commands and returning results, omitting that CDP commands like Page.navigate can change browser state, and it does not discuss prerequisites or error behavior. The mismatch between the schema (cmd_args as string) and the described **cmd_args also creates confusion.
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 appropriately sized with clear sections (Args, Returns, Note) and front-loaded with a one-line summary. The examples are useful and do not pad the text.
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 low-level CDP runner with no annotations or output schema, the description is incomplete. It lacks guidance on when to use it vs sibling CDP tools, fails to clarify the cmd_args format inconsistency, and doesn't address potential side effects or error conditions.
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 define parameters. It provides 'cmd: CDP命令协议' and '**cmd_args: CDP命令参数' with examples, which adds some meaning. However, the schema declares cmd_args as a string, while the description suggests keyword arguments, leading to ambiguity about the expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs Google CDP protocol commands in the current tab and retrieves results, distinguishing it from JS-execution tools like run_js. The scope ('current tab') and examples solidify 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of how to call the tool but does not explain when to choose CDP over alternatives such as run_js or listen_cdp_event. No explicit when-to-use or exclusions, only implied usage from examples.
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 implies a read operation ('get') but does not specify whether it returns visible text only, includes hidden elements, waits for page load, or what happens if the body is empty. This minimal disclosure is inadequate for a tool with no structured safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and target without any filler. Every word contributes to the meaning, and it is appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool, the description conveys the core function, but it lacks usage guidelines and behavioral details such as the exact format of the returned text ('textContent' vs. 'innerText') and when it should be preferred over sibling tools. Given no output schema and no annotations, this level of completeness is minimally adequate but leaves clear gaps.
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 is 4. The description adds no parameter-level detail, but none is required because the schema already declares an empty properties object. There is no gap for the description to fill.
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 a specific verb 'get' and a specific resource 'the body text content of the current tab', clearly distinguishing it from sibling tools like get_current_tab_info (which retrieves tab metadata) and getSimplifiedDomTree (which retrieves the DOM structure). It is immediately clear what the tool does and how it differs.
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 state use cases, exclusions, or prerequisites. Sibling tools like getSimplifiedDomTree or get_current_tab_info overlap in purpose, but the description offers no comparison or selection 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the file is saved and the return value is the file path, which is useful. However, it does not mention whether existing files are overwritten, what image format is used beyond the default 'screenshot.png', or whether the target directory must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, and the Args/Returns structure is readable. However, the Args section lists only 'path' and omits 'name', which is a structural inconsistency that undermines completeness despite the overall brevity.
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 file-saving tool, the description covers the core purpose and return value, and the schema provides defaults for both parameters. Still, it lacks important context such as file format behavior, overwrite semantics, and any relationship to the similar sibling tool 'get_current_tab_screenshot', leaving moderate gaps.
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 explains 'path' as the save directory with default current directory, but entirely omits the 'name' parameter, which is a required part of the schema for specifying the filename. The description therefore provides incomplete semantics for the tool's parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of the current tab and saves it as a file, with the verb '获取' (get/capture) and resource '当前标签页的屏幕截图' (current tab screenshot). The phrase 'as file' distinguishes it from the sibling tool 'get_current_tab_screenshot', which likely returns image data rather than saving to disk.
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 'get_current_tab_screenshot'. It does not state any exclusions, prerequisites, or scenarios where one approach is preferred over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the main behavior (opening or attaching to a browser) and mentions return type, but it does not explain side effects, what 'take over' means for existing sessions, whether it launches a new process, or any state changes. This is a significant gap for a tool without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. It has separate sections for parameters and return value, which aids scanning. However, there is a typo ('包括、debug_port' with an extra space) and the '必要参数' vs '可选键' wording is internally inconsistent, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connection tool, it covers the core purpose, parameter keys, and return type. But it lacks guidance on when to invoke it (e.g., before page operations), what happens when no browser is open, and the structure of the returned browser info. Given the absence of annotations and output schema, more completeness would be expected.
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 0%, so the description must compensate. It lists the config dict and the optional keys (debug_port, browser_path, headless), which adds meaning beyond the schema's bare object definition. However, it doesn't explain the semantics or types of these keys, and it confusingly labels config as '必要参数' (required) while the schema marks it optional with a default.
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: '打开或接管已打开的浏览器' (open or take over an already open browser) using DrissionPage. This verb+resource pair distinguishes it from sibling tools, which operate on tabs or page content rather than the browser session itself.
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 it is the entry point for browser interaction, but it does not explicitly state when to use it versus alternatives like 'new_tab' or 'get'. There is no 'when not to use' or mention of sibling tools, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses an important behavioral prerequisite (domain activation), which helps the agent avoid errors. However, it does not explain what happens when events are received, whether listening is persistent, or how to stop/retrieve events, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action. Every sentence earns its place, with the second sentence providing a crucial usage hint. It is appropriately sized and well-structured for quick consumption.
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 tool with one parameter and no output schema, the description provides the essential context (listener setup and prerequisite), which is adequate. However, it lacks references to sibling tools like get_cdp_event_data for retrieving events, and does not clarify lifecycle or edge cases, so the completeness is only marginal.
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 one parameter (event_name) with 0% description coverage in the schema itself. The tool description does not mention event_name at all, nor does it relate the parameter to the example 'Network.enable' (which is about domain activation, not event name). The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '设置监听CDP事件' (set up listening for CDP events). This specifies a distinct action (listening) and resource (CDP events), differentiating it from sibling tools like get_cdp_event_data (which retrieves event data) and run_cdp (which executes CDP commands).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: '应该先运行cdp 命令激活对应的域' (should first run the cdp command to activate the corresponding domain), giving a prerequisite and example. This clarifies the expected sequence of operations, though it does not explicitly mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 says 'click' and 'current tab' but does not disclose whether it waits for the element, what happens on failure, potential page changes, or return values. This lack of behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It efficiently communicates the purpose and a key usage tip without unnecessary fluff, though the Chinese phrasing could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core action and a useful precursor step. However, it omits information about return behavior, error conditions, or timing, which are relevant for an agent to invoke and handle 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?
The schema has one required parameter 'xpath' with no description (0% coverage). The description adds value by explaining that XPath should be crafted after inspecting the DOM, which gives some contextual meaning beyond the schema. However, it does not specify the expected format, escaping rules, or examples of the XPath string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a click action on an element in the current tab using an XPath selector. This specific verb+resource+mechanism distinguishes it from siblings like click_by_containing_text and input_by_xapth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a direct usage tip: to get the page DOM information first before deciding how to write the XPath. This offers clear context on how to use the tool effectively, though it does not explicitly name alternative tools 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 must carry the full behavioral burden. It only says data is saved to SQLite, but does not disclose whether tables are overwritten or appended, how list data is inserted, error behavior, or any side effects. This is insufficient for a write 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 concise and well-structured, with a clear parameter list that is easily scannable. Every line earns its place and there is no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description provides essential info: what data can be passed, database path, and table name. It implies table creation via '要创建的表名'. However, it leaves out details about return values or insertion behavior for multiple records, which are minor gaps given 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 description adds meaningful parameter explanations beyond the schema, which only lists types and defaults. It clarifies that 'data' accepts a dict, list of dicts, or JSON string, and explains 'db_path' and 'table_name' clearly. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: saving a dictionary or JSON string to a SQLite database. It specifies the action (save), the resource (dict/JSON to SQLite), and is distinct from all sibling browser automation 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 given on when to use this tool versus alternatives, though there are no similar siblings. It also fails to mention prerequisites, such as the need for a valid database path or how existing tables are handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It only mentions return values (result/error) but does not disclose side effects of clicking (e.g., navigation, form submission), behavior when no element is found, or how multiple matches are handled when index is omitted.
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 appropriately sized with a clear purpose sentence, a compact parameter list, and a return note. It is well-structured and front-loaded without unnecessary verbosity.
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 and lack of annotations/output schema, the description covers the core purpose, parameters, and return type. However, it lacks usage context relative to sibling tools and fails to address edge cases (no match, multiple matches without index), leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for both parameters, including the role of index for multiple matches and its default unspecified state. This compensates for the schema's 0% coverage, though the default behavior when index is omitted remains slightly ambiguous.
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 clicks a web element based on containing text, with a specific verb and resource. It distinguishes from sibling tool click_by_xpath by specifying the text-based targeting method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to click an element by its text content, but it does not explicitly state when to prefer it over alternatives like click_by_xpath. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals some behavior: it returns a dict with offsets and duration, or an error string when the element is not found. It also notes no explicit exception is thrown. However, it does not describe drag mechanics, waiting behavior, or how this differs from a simple move, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear Args, Returns, and Raises sections. It is concise, with no redundant text. Every sentence adds value, and the structure makes parameters and behavior easy to scan.
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 4-parameter drag tool with no annotations and no output schema, the description covers all key aspects: input parameters, units, defaults, and error handling. It lacks some behavioral context like whether the element must be visible or how the drag is performed, but is largely complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining each parameter: xpath (element path), offset_x/offset_y (pixel offsets), and duration (milliseconds, default 1000). It also explains the return format, adding semantic meaning well 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 tool's purpose: '将元素拖动到指定偏移位置' (drag element to specified offset position). It specifies the verb (drag), resource (element), and scope (offset). It does not explicitly distinguish from the sibling 'move_to', but the offset parameters and drag terminology make it clear enough.
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 implies use for dragging elements, but does not mention when not to use it or suggest alternatives like 'move_to'. There is no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the click action and that an error is returned if the element doesn't exist, but does not disclose potential side effects, wait behavior, or handling of multiple file inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The Args/Returns block is structured and not overly verbose, though the parameter description is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the action, parameter, and return value. It is complete enough for basic usage, though it could benefit from notes on prerequisites or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It includes an Args section explaining file_path as 'the file path to upload,' but this adds minimal value beyond the schema's 'File Path' title. No format, restrictions, or examples are given.
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 a specific action: click the webpage's <input type='file'> element to upload the specified file. This clearly distinguishes it from sibling tools like download_file, click_by_xpath, and input_by_xapth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a file input element is present on the page, but does not explicitly state when to use this tool vs alternatives or any exclusions. It lacks direct guidance on scenarios where other upload methods might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that navigation occurs in the current tab, which is a key behavioral trait beyond the tool's name. However, it does not disclose potential side effects like waiting for page load or error handling, though these may be minor 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded and directly states the action, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description covers the essential purpose and the key distinguishing behavior (current tab). However, it lacks details on what happens after navigation, error scenarios, or whether it blocks until the page loads. Given the simplicity of the action, the description is minimally acceptable but not comprehensive.
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 only one parameter 'url' with no description, and the tool description does not add meaningful details about URL format, validation, or required protocol. It merely repeats the word 'URL' in the description, providing minimal additional semantic value over the schema itself.
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 'Open a URL in the current tab' clearly specifies the action (open a URL) and the resource (current tab), which distinguishes it from sibling tools like new_tab that open a new tab. It is specific, concise, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for navigating the current tab but does not explicitly state when to use it versus alternatives like new_tab. There is no mention of exclusions or conditions, leaving the agent to infer from the phrase 'current tab'.
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 mentions return bytes; it does not disclose potential side effects, viewport/full-page scope, or other behavioral nuances.
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?
Extremely concise, with a clear action and return specification in two lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter screenshot tool, the description provides the essential output type, but it omits context about when to use this vs the 'as_file' variant and does not mention capture scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist and schema coverage is 100% (empty); baseline 4 applies since the description need not add parameter 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?
Description clearly states the tool captures a screenshot of the current tab and returns binary byte data, distinguishing it from the similar sibling that outputs a file.
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?
Implied usage from return type but no explicit comparison with the similarly named get_current_tab_screenshot_as_file; no when-to-use or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool inputs content, optionally clears existing content (clear_first default true), and returns an error if the element does not exist. However, it does not mention waiting behavior, event triggering, or other side effects, which limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose sentence, a structured Args section, and a Returns note. Every sentence adds value; the '最好先判断元素是否存在' note is a useful behavioral tip. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers purpose, parameters, return type, and an error case. However, the return type is vague ('Any') and there is no detail on the success return or behaviors like scrolling or focusing. It is adequate but not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It explicitly describes xpath, input_value, and clear_first (including its default value and meaning). This goes beyond the schema, which only provides names and types, fully compensating for the lack of schema descriptions.
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: '通过xpath给当前标签页中某个元素输入内容' (input content to an element in the current tab via XPath). This is a specific verb+resource and distinguishes from sibling tools like click_by_xpath or send_enter, though it does not explicitly name alternatives.
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?
It provides a usage hint: '最好先判断元素是否存在' (preferably check if the element exists first), implying the tool may fail if the element is absent. However, it does not explicitly state when to use this tool versus alternatives or under what conditions to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (move and hover) but does not add context such as whether it triggers events, scrolls into view, or behaves differently from a click. It is minimally transparent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to the meaning, making it concise and well-structured.
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 one-parameter hover tool with no output schema and no annotations, the description covers the essential purpose and parameter role. It does not explain return values or side effects, but none are expected for a hover action, so 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 description explicitly states that xpath identifies the target element, adding meaning beyond the schema's type and title. Given the 0% schema description coverage, this clarification is valuable and helps the agent understand the parameter's role.
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 a specific verb (move/hover) and resource (element at specified xpath), clearly distinguishing it from sibling tools like click_by_xpath and drag. It concisely states what the tool does.
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 only hovers and does not click, nor does it compare to click_by_xpath or drag, leaving the agent to infer the appropriate use case.
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 states the action but does not disclose potential side effects such as triggering a form submission, navigation, or whether it behaves like a discrete key press. However, for a simple key event, the basic behavior is clear, and the description does not mislead. It adds minimal context beyond the title.
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: '向当前页面发送 enter 回车键'. It is front-loaded with the action and target, contains zero filler, and fully communicates the tool's purpose without unnecessary detail. It is an efficient use of description space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is nearly complete. It could optionally mention whether the keypress is a down/up event or if it waits for any resulting navigation, but such details are not critical for a basic Enter key send. The presence of sibling tools like 'send_key' adds context, but the description itself is adequate for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties (0 parameters), so the baseline is 4. The description appropriately does not need to explain parameter semantics since there are none. The schema coverage is 100% (vacuously), and the description provides no additional parameter details, which is acceptable.
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: '向当前页面发送 enter 回车键' (Send Enter key to the current page). The verb 'send' and resource 'current page' are specific, and it explicitly identifies the key (Enter). This distinguishes it from other key-related siblings like 'send_key' because it specifically targets the Enter key.
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 vs alternatives. There is no mention of exclusions or preferred contexts. A sibling tool 'send_key' exists, but the description does not clarify whether 'send_enter' is intended for the common case of pressing Enter or if there are specific scenarios where it should be used instead.
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 tool gets input elements but does not disclose what qualifies as input elements (e.g., text fields, textareas, editable elements), whether it filters hidden/visible elements, or what format the returned information takes. Behavioral traits beyond the basic action are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the action and resource, followed by a clear usage directive. There is no wasted text; every word contributes to understanding the tool's purpose and intended use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameters, the description provides the core purpose and usage but lacks important details such as what 'info' is returned, how the elements are represented, or how to map them to input operations. It is minimally viable but incomplete for an agent needing to invoke the tool effectively.
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 vacuously 100%. The description does not need to explain parameters, and the baseline for 0 params is 4. It could have explicitly noted that no parameters are required, but the empty schema already conveys this.
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 verb and resource: '获取当前标签页的所有可进行输入操作的元素' (get all input-capable elements in the current tab). This distinguishes it from sibling tools like get_body_text or get_current_tab_info, and explicitly ties it to input operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-to-use directive: '对元素进行输入操作前优先使用这个方法' (prioritize using this method before input operations). It does not mention alternatives or exclusions, but the use case is clearly scoped.
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 of behavioral disclosure. It lists the return fields (url, title, id), which is helpful, but it does not mention side effects, permissions, or explicitly confirm it is a read-only operation. For a simple getter, this is a moderate 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, focused sentence that immediately states the action and the key return fields. It contains no filler or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately communicates the core functionality and return fields. It could be slightly more complete by mentioning the return format, but given the low complexity, it is sufficiently informative.
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, and the input schema is empty with 100% coverage. The description lists the return fields, which is not parameter-related but does add context. The baseline for zero-parameter tools is 4, and no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the current tab's information (url, title, id) using a specific verb and resource. It is easily distinguishable from sibling tools like get_current_tab_screenshot or get_body_text, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needing the current tab's metadata, but it does not explicitly state when to use it versus alternatives or provide exclusions. There is no mention of when not to use it, leaving usage context somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explains how to get return values via 'return' and provides an async IIFE pattern for async code, going beyond mere execution. It does not disclose potential side effects, but the core behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Description, Args, Returns, and Note sections. The example is concise and valuable, making every sentence earn its place. Slightly long but not wasteful.
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?
Although there is no output schema, the description provides enough to use the tool effectively, including return value semantics and async handling. It could mention error handling or execution context restrictions, but it is complete for common use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Notes section adds critical semantics beyond the schema: use 'return' for return values and an async IIFE for promises. This compensates well for the bare schema parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run JavaScript code in the current tab and return the execution result', with a specific verb and resource. It also differentiates from siblings by advising to prefer this method for finding, getting info, and operating on web elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to prefer this method for element-related tasks, which distinguishes it from specialized sibling tools. However, it does not mention when not to use it or name specific alternatives.
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:

[![DrissionPageMCP MCP server](https://glama.ai/mcp/servers/wxhzhwxhzh/DrissionPageMCP/badges/card.svg)](https://glama.ai/mcp/servers/wxhzhwxhzh/DrissionPageMCP)

Score Badge

Copy to your README.md:

[![DrissionPageMCP MCP server](https://glama.ai/mcp/servers/wxhzhwxhzh/DrissionPageMCP/badges/score.svg)](https://glama.ai/mcp/servers/wxhzhwxhzh/DrissionPageMCP)

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/wxhzhwxhzh/DrissionPageMCP'

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