DrissionPageMCPServer_Modified

by HyperClockUp

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: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as take_screenshot for visual capture, get_dom_tree for structural analysis, and click_element for interaction. However, some overlap exists between find_elements and get_dom_tree, as both assist in element location, which could cause minor confusion in selection. The detailed descriptions help mitigate this overlap by clarifying their specific roles.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun combinations, such as take_screenshot, get_dom_tree, and click_element. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming style or convention throughout the list.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a browser automation server, covering essential operations like navigation, interaction, and monitoring. Some tools, like get_screenshot_data and save_page_source, might be redundant or niche, but overall, the set is well-scoped for its domain without being overly bloated.
Completeness5/5
The tool set provides comprehensive coverage for browser automation, including navigation, element interaction, monitoring, and data extraction. It supports a full workflow from setup (connect_browser) to interaction (click_element, input_text) and analysis (get_dom_tree, get_network_logs), with no obvious gaps that would hinder agent operations in this domain.
Average 3.4/5 across 17 of 17 tools scored. Lowest: 1.7/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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe whether this is a read or write operation, what permissions or browser state are required, whether it's destructive, what side effects occur, or how the monitoring persists. The description only states the action and basic input/output without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and structured with Args and Returns sections, which is efficient. However, the purpose statement is overly simplistic, and the parameter explanation lacks depth. While concise, it under-specifies rather than being optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of enabling network monitoring (a likely state-changing operation) with no annotations and an output schema that only indicates a string return, the description is incomplete. It doesn't explain what '启用结果' (enable result) entails, how monitoring interacts with other tools, or what behavioral changes occur, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'filter_types: 需要监听的mimeType类型列表' (filter_types: list of mimeType types to monitor), which adds some meaning about what the parameter controls. However, it doesn't explain what mimeTypes are relevant, provide examples, or clarify the format, leaving significant gaps in understanding.
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 states '启用网络监控' (enable network monitoring), which is a tautology that restates the tool name without specifying what network monitoring entails or what resource it affects. It doesn't distinguish this tool from sibling tools like 'get_network_logs' or clarify what 'network monitoring' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_network_logs' or other browser-related tools. There's no mention of prerequisites, timing considerations, or exclusions that would help an agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does at a surface level ('execute CDP command') without any information about side effects, permissions needed, rate limits, error handling, or what the execution entails. For a tool that likely interacts with browser automation, this lack of transparency is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three Chinese characters ('执行CDP命令'), which is appropriately sized for what it conveys. It's front-loaded with the core action, though it lacks detail. There's no wasted verbiage, making it structurally efficient despite being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing CDP commands (likely involving browser automation), the lack of annotations, 0% schema description coverage, and the presence of an output schema (which isn't described in the description), the description is incomplete. It doesn't explain what CDP is, what commands are available, or how to use the parameters, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning neither parameter has any description in the schema. The description '执行CDP命令' adds no information about what the 'command' and 'params' parameters should contain, their formats, examples, or constraints. For a tool with 2 required parameters, this leaves them completely undocumented.
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 '执行CDP命令' (Execute CDP command) is a tautology that essentially restates the tool name 'run_cdp_command' in Chinese. While it specifies a verb ('执行' - execute) and resource ('CDP命令' - CDP command), it doesn't clarify what CDP is (likely Chrome DevTools Protocol) or what types of commands can be executed, making it vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the sibling tools include browser automation functions like 'execute_javascript', 'click_element', and 'navigate', there's no indication of how this tool differs or when it should be preferred over those alternatives. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't mention whether this is a read or write operation, what permissions or contexts are required, what happens if the JavaScript has errors, whether there are security restrictions, timeouts, or any other behavioral characteristics. For a tool that executes arbitrary code, this is a critical gap in 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 extremely concise - a single phrase in Chinese. While it's arguably too brief for adequate documentation, it's not wordy or repetitive. Every word earns its place, and there's no fluff or unnecessary elaboration. The structure is straightforward, though minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a code execution tool with 2 parameters, no annotations, and 0% schema description coverage, the description is woefully incomplete. While there is an output schema (which might help with understanding return values), the description doesn't provide the essential context needed to use this tool safely and effectively. It doesn't explain the execution environment, security implications, error handling, or any other critical context for running JavaScript code.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (neither parameter has descriptions in the schema), the description provides no information about the two parameters. The description doesn't mention the 'code' parameter that's required, nor the optional 'return_result' boolean parameter. For a tool with 2 parameters that are completely undocumented in the schema, the description fails to compensate by explaining what these parameters mean or how they should be used.
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 '执行JavaScript代码' (Execute JavaScript code) is a tautology that essentially restates the tool name 'execute_javascript' in Chinese. While it does specify the verb ('执行' - execute) and resource ('JavaScript代码' - JavaScript code), it doesn't differentiate this tool from potential alternatives or provide any context about what kind of JavaScript execution this involves. It's minimally informative but doesn't go beyond restating the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple sibling tools related to browser automation (click_element, navigate, get_cookies, etc.), but the description doesn't indicate whether this executes JavaScript in a browser context, server context, or elsewhere. No prerequisites, limitations, or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action ('create new tab') without any information about permissions needed, whether it opens in foreground/background, what happens if a URL is invalid, or how it interacts with existing browser sessions. This is inadequate for a tool that likely interacts with browser state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three Chinese characters. It's front-loaded with the core action and has zero wasted words. While under-specified, it's structurally efficient for what it does convey.
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 likely interacts with browser tabs (inferred from sibling tools), the description is incomplete. With no annotations, 1 undocumented parameter, and an output schema (which might help but isn't described), the description should explain more about the tool's behavior, return values, and context. It fails to provide enough information for safe and effective use.
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 1 parameter ('url') with 0% description coverage in the schema. The tool description doesn't mention parameters at all, failing to compensate for the schema gap. For a tool with an undocumented parameter, the description should explain what the 'url' parameter does (e.g., optional URL to load in the new tab) but provides no such information.
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 '创建新标签页' (Create new tab) is a tautology that restates the tool name 'new_tab' in Chinese. It doesn't specify what kind of tab (browser tab, UI tab, etc.) or provide any distinguishing context from sibling tools like 'navigate' or 'connect_browser'. The purpose is stated but lacks specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit or implied instructions about when to choose 'new_tab' over sibling tools like 'navigate' (which might open URLs in existing tabs) or 'connect_browser' (which might establish browser sessions). No context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the action ('save page source to file') but doesn't disclose behavioral traits such as what file format is used (e.g., .html, .txt), where the file is saved (local path, temporary storage), permissions required, or error handling. It mentions saving but lacks details on the mutation's effects or output behavior beyond the existence of an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese ('保存页面源码到文件'), which is appropriately concise and front-loaded with the core action. There's no wasted text, but it could benefit from slightly more detail without losing conciseness. It's structured well for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter, no annotations, and an output schema exists (which likely describes the return values), the description is somewhat complete but has gaps. It covers the basic action but lacks context on prerequisites (e.g., browser connection), file handling, and differentiation from siblings. The output schema reduces the need to explain returns, but more behavioral details would improve completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage (no schema descriptions). The description doesn't add any meaning about the 'filename' parameter beyond what the schema title implies. It doesn't explain the parameter's role, default behavior, or format (e.g., if null generates a default name). With low schema coverage, the description fails to compensate, but since there's only 1 parameter, the baseline is adjusted to 3 as it's minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '保存页面源码到文件' (Save page source to file) states a clear verb ('save') and resource ('page source'), but it's somewhat vague about what 'page source' specifically means (HTML source code, DOM tree, rendered content?). It doesn't distinguish from sibling tools like 'get_dom_tree' or 'get_page_text' which might retrieve similar content. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a browser session via 'connect_browser'), exclusions, or compare it to siblings like 'get_dom_tree' (which might retrieve structured DOM) or 'get_page_text' (which might extract text). Usage is implied from the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adds valuable behavioral context about timeout control (default 30 seconds), which isn't evident from the schema. However, it doesn't disclose other important behaviors like error handling, performance characteristics, or what happens when timeout is reached.
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 concise with two brief sentences. The first states the core purpose, the second adds timeout information. There's no unnecessary verbiage, though the structure could be slightly improved by front-loading the timeout information more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which presumably describes the binary data return), the description doesn't need to explain return values. However, for a screenshot tool with a sibling alternative and 0% schema description coverage, the description should do more to explain parameter usage and differentiation from 'take_screenshot'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about the 'format' parameter mentioned in the schema. The description doesn't explain what format options are available, default behavior, or how format affects the binary data output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取截图二进制数据' (get screenshot binary data), which is a clear verb+resource combination. However, it doesn't distinguish this tool from its sibling 'take_screenshot' - both appear to capture screenshots, making the purpose somewhat vague in relation to 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?
The description provides no guidance on when to use this tool versus the 'take_screenshot' sibling tool. It mentions timeout control but doesn't explain why one would choose this binary data retrieval over the presumably simpler 'take_screenshot' 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns ('网络日志数据') but doesn't describe format, structure, or content of the logs. It also doesn't mention whether this requires specific permissions, has rate limits, or depends on other tools being called first (like enabling network monitoring).
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 concise with a clear purpose statement followed by structured Args and Returns sections. Every sentence serves a purpose: the title explains what the tool does, and the parameter/return documentation provides essential information without unnecessary elaboration.
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 that there's an output schema (which handles return value documentation), the description doesn't need to explain return values in detail. However, for a tool that fetches network logs with no annotations, the description should ideally mention dependencies (like needing network monitoring enabled) or format expectations. It's minimally adequate but has 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 description explicitly documents the single parameter 'limit' and explains its purpose ('返回日志的最大数量'), which adds meaningful context beyond what the schema provides (schema description coverage is 0%). Since there's only one parameter and it's fully explained in the description, this earns a high score despite the schema's lack of 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 purpose as '获取网络请求日志' (get network request logs), which is a specific verb+resource combination. However, it doesn't differentiate this tool from potential sibling tools like 'enable_network_monitoring' or 'run_cdp_command' that might also interact with network data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no explicit instructions about prerequisites (like needing network monitoring enabled first), timing considerations, or comparisons to sibling tools such as 'enable_network_monitoring' or 'run_cdp_command' that might handle network data differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('navigate to URL') but lacks details on what happens during navigation (e.g., page load waits, error handling for invalid URLs, or whether it follows redirects). For a tool with potential side effects (like changing browser state), this is insufficient 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 extremely concise ('导航到指定URL')—a single phrase that directly states the tool's function without any wasted words. It's front-loaded with the core action, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (navigation with potential side effects), no annotations, and an output schema present (which might describe return values), the description is minimally complete. It states what the tool does but lacks behavioral details and usage context. The output schema might help, but the description itself is inadequate for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 0% description coverage but clearly defines a single required 'url' parameter of type string. The description implies the parameter is a URL to navigate to, but doesn't specify format (e.g., must include protocol like 'http://') or constraints. With one parameter and low schema coverage, this meets the baseline but doesn't compensate fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '导航到指定URL' (Navigate to specified URL) clearly states the verb (navigate) and resource (URL), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'new_tab' or 'connect_browser' which might have overlapping navigation functions, 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?
The description provides no guidance on when to use this tool versus alternatives like 'new_tab' for opening new tabs or 'connect_browser' for browser setup. There's no mention of prerequisites (e.g., requires an active browser session) or exclusions (e.g., not for internal page navigation), leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It adds valuable context about timeout control (default 20 seconds) which isn't in the schema, and implies the tool can either connect to an existing browser or launch a new one. However, it doesn't disclose important behavioral traits like error conditions (what happens if connection fails), whether this establishes a persistent session, or what permissions/requirements are needed.
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 sized with a clear purpose statement followed by parameter explanations. However, it's not optimally front-loaded - the timeout information appears at the end rather than integrated with the purpose. The parameter explanations are clear but could be more efficiently integrated with the main description.
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 this is a browser connection/initialization tool with 4 parameters, 0% schema coverage, no annotations, but with an output schema (which reduces need to describe return values), the description is moderately complete. It covers the basic purpose and parameters but lacks important context about when to use it, error handling, and session management that would be helpful 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?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. It successfully adds semantic meaning for all 4 parameters: explaining what 'port' is for debugging, defining 'headless' as no browser window display, clarifying 'incognito' as private mode, and identifying 'user_data_dir' as user data directory. This provides essential context beyond the bare schema titles.
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 as '连接到浏览器或启动新浏览器' (connect to browser or launch new browser), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'navigate' or 'new_tab' by focusing on browser connection/initialization rather than page navigation or tab management. However, it doesn't explicitly differentiate from all possible alternatives in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a browser must already be running), when to choose connection vs. launch, or when to use this versus other browser-related tools in the sibling list. The agent receives no contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: e.g., whether it returns all cookies or filtered ones, if it requires specific permissions, potential rate limits, or error conditions. For a tool with zero annotation coverage, this is a significant gap, meriting a 2.
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, efficient sentence: '获取当前页面的Cookies'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. This earns a 5 for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and siblings like connect_browser that suggest prerequisites, it lacks context on dependencies or behavioral details. The output schema helps, but the description doesn't fully compensate for missing behavioral transparency, resulting in a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it correctly implies no inputs are required. Given the baseline for 0 parameters is 4, this scores a 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 clearly states the tool's purpose as '获取当前页面的Cookies' (Get the current page's cookies), which is a specific verb+resource combination. It distinguishes itself from siblings like get_element_text or get_page_text by focusing on cookies rather than DOM content. However, it doesn't explicitly differentiate from all siblings (e.g., get_network_logs might also involve cookie data), keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active browser session via connect_browser), nor does it specify scenarios where cookies are relevant over other data sources. With no usage context provided, this scores a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing behavioral traits: it explains the tool is for '精确定位' (precise positioning) based on DOM analysis, mentions '智能匹配' (intelligent matching) with include_similar parameter, describes return format as '匹配元素的详细信息列表' (detailed information list of matched elements), and provides practical constraints like '避免结果过多' (avoid too many results) with limit parameter. It doesn't cover error cases or performance characteristics, keeping it from a perfect score.
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 sized but not optimally structured: it uses emoji sections and has duplicate 'Returns' sections (appearing twice with slightly different wording). While most content is valuable, the repetition and decorative formatting reduce efficiency. The information is front-loaded with purpose and usage, but the structure could be more streamlined.
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 4 parameters with no schema descriptions, no annotations, but with output schema (implied by 'Returns' statements), the description provides good completeness: it covers purpose, usage workflow, parameter semantics, and integration with sibling tools. However, it doesn't explicitly describe error conditions or what happens when no elements match, and the duplicate Returns sections create minor confusion about output format.
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?
With 0% schema description coverage, the description fully compensates by providing rich semantic context for all 4 parameters: it explains selector must be '基于实际DOM结构' (based on actual DOM structure), selector_type has three specific types with usage guidance (CSS recommended, XPath for complex, text as auxiliary), limit prevents '结果过多' (too many results), and include_similar enables '智能匹配' (intelligent matching). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '查找页面元素（智能定位工具）' (find page elements - intelligent positioning tool) and elaborates with specific verbs like '精确定位目标元素' (precisely locate target elements), '验证元素存在性和可访问性' (verify element existence and accessibility), and '获取元素的详细属性信息' (get detailed element attribute information). It distinguishes from siblings like get_dom_tree (which analyzes structure) and click_element/input_text (which perform actions on found elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: '基于DOM分析结果进行元素查找' (based on DOM analysis results for element finding) and '先用get_dom_tree()分析页面结构' (first use get_dom_tree() to analyze page structure). It also specifies when to use alternatives by mentioning selector type priorities (CSS for recommended cases, XPath for complex cases, text matching as auxiliary). The '最佳实践' (best practices) section clearly outlines the workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: returns '页面的完整可见文本内容（去除HTML标签）' (complete visible page text content with HTML tags removed). It mentions the tool helps '确认页面加载完成和内容可用性' (confirm page loading completion and content availability), which adds useful context about its role in validation. However, it doesn't specify potential limitations like performance impact or text encoding issues.
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 well-structured with clear sections (core tool warning, main uses, tool coordination, returns, workflow), but it's somewhat verbose with emojis and formatting that don't add essential information. While informative, it could be more concise by reducing decorative elements and focusing on the core content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, but has an output schema (returns str), the description provides excellent contextual completeness. It thoroughly explains the tool's purpose, when to use it, how it fits with sibling tools, and what it returns. The output schema handles return value documentation, so the description appropriately focuses on usage context rather than repeating output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取页面完整文本内容' (get complete page text content) and distinguishes it from siblings by emphasizing it's a '核心预处理工具' (core preprocessing tool) for standardized workflows. It specifies this is step 2 in the workflow, differentiating from tools like get_element_text (specific elements) or get_dom_tree (structured analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: '在操作元素前' (before operating on elements), '为非多模态LLM提供详细的页面内容描述' (to provide detailed page content descriptions for non-multimodal LLMs), and '帮助构建精确的元素选择器' (to help build precise element selectors). It also lists specific alternative tools for different purposes (take_screenshot, get_dom_tree, find_elements) and outlines a recommended workflow sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains the smart optimization aspect, provides selector priority recommendations, warns against guessing selectors, and includes best practice examples showing correct vs. incorrect usage patterns. The only minor gap is lack of explicit mention about what happens on failure scenarios.
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 front-loaded with the purpose and critical warnings, but contains some organizational inefficiencies. The emoji decorations and formatting with multiple sections (workflow, selector priority, args, returns, best practices) create visual clutter. While all content is valuable, the presentation could be more streamlined for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser automation tool with 4 parameters, no annotations, and an output schema, the description is remarkably complete. It covers purpose, prerequisites, usage workflow, parameter guidance, selector strategies, best practices, and includes return value information. The presence of an output schema means the description doesn't need to detail return values, and it appropriately focuses on usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains all 4 parameters: selector (with strict requirements against guessing), selector_type (with recommended types and priority order), index (explains it's zero-based for multiple matches), and smart_feedback (recommends True). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '点击页面元素（智能优化版）' which translates to 'click page element (smart optimized version)'. It specifies the exact action (click) and resource (page element), and distinguishes itself from siblings like find_elements or get_element_text by focusing on the clicking action with smart optimization features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines with a standardized workflow: 1) use take_screenshot to confirm element existence, 2) use get_dom_tree or find_elements to analyze page structure, 3) build selectors based on accurate information. It also specifies when NOT to use the tool ('禁止猜测元素名称' - no guessing element names) and references sibling tools for prerequisite steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes the tool's behavior: it's an analysis tool that returns structured DOM tree information with tags, attributes, and hierarchical relationships. It warns about potential information overload with complex pages and suggests reducing max_depth. However, it doesn't mention performance characteristics, error conditions, or what happens with invalid selectors.
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 well-structured with clear sections (core analysis tool, main purposes, tool collaboration, args, returns, usage suggestions) but contains some redundancy and could be more concise. The emoji decorations and formatting add visual clarity but don't contribute essential information. The content is front-loaded with purpose information, but some sections like the four main purposes could be more succinctly expressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (DOM tree analysis with 2 parameters) and the presence of an output schema (which covers return values), the description is remarkably complete. It covers purpose, workflow positioning, collaboration with other tools, parameter semantics, usage scenarios, and behavioral considerations. The description compensates for the lack of annotations and 0% schema description coverage by providing comprehensive context about how and when to use this tool effectively.
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 description adds significant semantic meaning beyond the input schema, which has 0% description coverage. It explains that 'selector' is the '起始选择器' (starting selector) with default 'body' to get the entire page structure, and 'max_depth' controls '最大遍历深度' (maximum traversal depth) with default 10 to avoid deep nesting. It provides practical guidance on when to use each parameter, including using default for initial analysis, specifying selector to focus on specific areas, and reducing max_depth for complex pages.
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 '获取DOM树结构' (gets DOM tree structure) with specific verbs like '获取' (get/acquire) and '分析' (analyze). It distinguishes from siblings by focusing on structured hierarchical analysis rather than screenshots, text extraction, or element interaction. The description explicitly lists four main purposes including obtaining hierarchical structure, providing selector paths, analyzing layout relationships, and supplying structured information to non-multimodal LLMs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives. It states this is '标准化工作流程的第3步' (step 3 of the standardized workflow) and should be used '在 take_screenshot() 和 get_page_text() 之后' (after take_screenshot() and get_page_text()). It also specifies collaboration with other tools like find_elements() and get_element_text(), and provides three specific usage scenarios with recommendations for different contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the tool's role in workflows, debugging assistance, and documentation purposes. It mentions '操作结果' (operation results) but doesn't specify error behavior or performance characteristics. No contradiction with annotations since none 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?
Well-structured with clear sections (用途, 配合, Args, Returns, 场景) but somewhat verbose with emojis and formatting. Every sentence adds value, though some redundancy exists between '主要用途' and '推荐使用场景'. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, the description provides comprehensive context: clear purpose, usage guidelines, parameter explanations, return value indication, and workflow integration. The output schema exists, so return values don't need detailed explanation in the description.
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 compensates by explaining all three parameters in Chinese: filename (optional, auto-generated timestamp), full_page (complete page vs visible area), and element_selector (specific element only). It adds meaningful context beyond basic schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '截取页面截图' (take page screenshot) and positions it as '标准化工作流程第1步' (standardized workflow step 1). It distinguishes from siblings by emphasizing visual confirmation before element operations, unlike text-based tools like get_page_text or get_dom_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided with '推荐使用场景' (recommended usage scenarios) listing specific situations like after page navigation and before clicks/inputs. It also explains tool coordination with multimodal vs non-multimodal LLM workflows, clearly differentiating when to use this versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing important behavioral traits: it explains this is a preprocessing tool for precise element information, describes what happens when elements don't exist (returns error message), and provides selector construction principles. It doesn't mention rate limits or authentication needs, but covers most essential behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (important note, use cases, selector principles, args/returns, best practices) but could be more concise. Some sections like the best practice examples are helpful but slightly verbose. Overall, most content earns its place by providing valuable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (element interaction with precise selectors), no annotations, and an output schema that only specifies return type, the description provides excellent completeness. It covers purpose, usage guidelines, behavioral context, parameter semantics, and best practices - everything needed for an agent to use this tool correctly in the context of sibling browser automation tools.
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?
With 0% schema description coverage for the single parameter, the description fully compensates by providing rich semantic context: it explains the selector must be based on actual DOM structure from get_dom_tree() or find_elements(), gives construction principles (prioritize ID, class, attribute selectors), and warns against guessing selectors. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取元素文本内容（精确定位版）' (get element text content - precise positioning version), specifying both the verb (get) and resource (element text content). It distinguishes from sibling tools like get_page_text by emphasizing precise element-level retrieval rather than whole-page text extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives: it lists three specific use cases (verifying text before click/input, getting dynamic content, confirming element existence/visibility) and gives clear best practice examples showing when to use this tool versus find_elements. It also explicitly states this is a '预处理工具' (preprocessing tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's operational behavior including the selection strategy priority, the clear_first parameter's effect on content handling, and workflow dependencies. It doesn't cover rate limits or error handling, but provides substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (warning, workflow steps, selector priority, parameters, returns, best practices) and uses visual markers effectively. While comprehensive, some sections could be more concise, but every sentence adds value for tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (DOM interaction with selector validation), no annotations, and 0% schema coverage, the description provides complete context. It covers purpose, prerequisites, parameter semantics, workflow integration, and best practices. The presence of an output schema means return values don't need explanation in the description.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all three parameters. It explains selector requirements ('必须基于实际DOM结构，禁止猜测'), text parameter purpose, and clear_first behavior with recommendations. The description adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('输入文本' - input text) and the target resource ('输入框' - input box), with the '智能优化版' (smart optimized version) qualifier distinguishing it from basic input operations. It explicitly differentiates from siblings like click_element and find_elements by focusing on text input functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit, step-by-step guidance on when to use this tool ('先使用 take_screenshot() 确认输入框存在且可见', '使用 find_elements() 验证输入框的选择器'), clear prerequisites, and best practice examples showing correct vs incorrect usage patterns. It integrates with sibling tools in a workflow context.
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:

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

Score Badge

Copy to your README.md:

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

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/HyperClockUp/DrissionPageMCPServer_Modified'

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