Windows Automation MCP Server

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 targeting specific Windows automation tasks like window management, browser control, file operations, and system monitoring. However, some overlap exists: 'take_screenshot' and 'take_screenshot_region' are closely related, and 'browser_type' vs 'type_text' could cause confusion in web vs general input contexts. Descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly. Examples include 'activate_window', 'browser_click', 'copy_file', and 'get_system_info'. This predictability makes the set easy to navigate and understand at a glance.
Tool Count3/5
With 41 tools, the count feels heavy for a single server, potentially overwhelming for agents. While Windows automation is broad, many tools (e.g., 'get_mouse_position', 'move_mouse', 'mouse_click') could be consolidated into fewer, more general tools. It's borderline but leans toward excessive given the scope.
Completeness5/5
The tool surface comprehensively covers Windows automation domains: file management (CRUD operations), process control, window manipulation, browser automation, system monitoring, and input simulation. No obvious gaps are present; agents can perform end-to-end workflows without dead ends.
Average 2.6/5 across 41 of 41 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '鼠标点击' gives no information about what the tool actually does—whether it simulates a mouse click at the current cursor position, requires specific permissions, has side effects, or interacts with UI elements. This is completely inadequate for a tool that performs an action with potential system-level effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is extremely concise (just two characters), this is a case of under-specification rather than effective brevity. The single term '鼠标点击' fails to convey necessary information, making it inefficient rather than well-structured. Conciseness should not come at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an action tool with no annotations, no output schema, and a minimal description, the description is completely inadequate. It doesn't explain what the tool does, when to use it, what behavior to expect, or how it differs from similar tools. For a tool that performs a system interaction, this level of incompleteness is problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('button' and 'double') clearly documented in the schema. The description adds no additional meaning about parameters beyond what the schema already provides. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '鼠标点击' (mouse click) is a tautology that merely restates the tool name without specifying what it does. It doesn't distinguish this tool from sibling tools like 'browser_click' or 'move_mouse', nor does it clarify whether this performs a system-level mouse click or something else. This provides no meaningful purpose clarification beyond the obvious name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'browser_click' (for browser-specific clicks) or 'move_mouse' (for movement without clicking), nor does it provide any context about appropriate use cases, prerequisites, or exclusions. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '点击元素' only states the action without explaining what happens (e.g., whether it simulates a user click, requires a browser to be open, handles errors if the selector isn't found, or affects browser state). This leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly concise to the point of under-specification—it's a single phrase with no structure or elaboration. While brief, it fails to convey necessary information, making it inefficient rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a browser interaction tool with no annotations and no output schema, the description is severely incomplete. It doesn't cover behavioral aspects, usage context, or expected outcomes, leaving the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'selector' as CSS selector, 'sessionId' as optional session ID). The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 '点击元素' (click element) is a tautology that essentially restates the tool name 'browser_click' in Chinese. While it indicates the action involves clicking, it doesn't specify what kind of element (e.g., UI element in a browser) or provide any distinguishing details from sibling tools like 'mouse_click'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context (e.g., browser automation vs. system-level interaction), prerequisites like needing an active browser session, or how it differs from similar tools such as 'mouse_click' or 'activate_window'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this operation requires specific permissions, if it's reversible, what happens to the window state, or any side effects. The single Chinese phrase adds no behavioral context beyond the basic action implied by the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three Chinese characters, this is under-specification rather than effective brevity. The description fails to provide necessary context and reads as incomplete rather than efficiently structured. Every sentence should earn its place, but here the single phrase doesn't earn enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, no output schema, and sibling tools performing similar window operations, the description is completely inadequate. It doesn't explain what 'minimize' means in this context, how it differs from closing or maximizing, what happens after minimization, or any error conditions. The agent would struggle to use this 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 input schema has 100% description coverage with the 'title' parameter clearly documented as '窗口标题' (window title). The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline score of 3 for adequate schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '最小化窗口' (minimize window) is a tautology that restates the tool name in Chinese without adding specificity. It doesn't clarify what type of window (browser, application, system) or provide any distinguishing context from sibling tools like 'close_window' or 'maximize_window'.
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 'close_window' or 'maximize_window'. There's no mention of prerequisites, context requirements, or comparison with sibling tools, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the basic action ('write file content') without any information about permissions required, whether it overwrites existing files, what happens if the path doesn't exist, error conditions, or any side effects. This is critically inadequate for a file system mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just four Chinese characters, this is an example of under-specification rather than effective conciseness. The description fails to provide necessary context and is too minimal to be helpful, earning a low score despite its brevity.
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 file system mutation tool with no annotations and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, what errors might occur, file permission considerations, or any behavioral nuances. The description fails to compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('path' and 'content') clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides, so it meets the baseline of 3 for adequate coverage through schema alone.
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 '写入文件内容' (write file content) is a tautology that essentially restates the tool name 'write_file' in Chinese. It specifies the verb 'write' and resource 'file content', but doesn't distinguish this tool from any potential siblings or provide any additional context about what makes this tool unique.
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 on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison to sibling tools like 'copy_file', 'move_file', or 'read_file' that exist on the same server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action without details on output format, potential side effects, permissions required, or error conditions. For a tool with no structured annotations, this is insufficient to inform safe or effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取网络信息', which is overly concise to the point of under-specification. It lacks necessary details for clarity and completeness, failing to earn its place as a helpful description despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (implied by retrieving network data), lack of annotations, and no output schema, the description is incomplete. It does not explain what information is returned, how it's structured, or any limitations, making it inadequate for the agent to understand the tool's behavior or outputs.
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 no parameter information is needed. The description does not add or detract from parameter understanding, meeting the baseline for parameterless tools without introducing confusion.
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 '获取网络信息' (Get network information) restates the tool name 'get_network_info' in Chinese, making it tautological. It lacks specificity about what network information is retrieved (e.g., IP addresses, network interfaces, connectivity status) and does not distinguish it from sibling tools like 'get_system_info' or 'get_disk_info', which could also provide 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent to guess based on the name alone. This is inadequate given the presence of sibling tools that might overlap in functionality.
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. '创建目录' only states the action without any information about permissions required, whether it overwrites existing directories, error conditions (e.g., invalid paths), side effects, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('创建目录'), which could be efficient if it were informative. However, it's under-specified rather than appropriately concise—it lacks necessary details for a mutation tool. While front-loaded, it doesn't earn its place by providing sufficient context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral traits. While the parameter is covered by the schema, the overall context for safe and correct usage is missing, making it inadequate for an agent to invoke this tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. However, schema description coverage is 100% (the 'path' parameter is documented in the schema as '目录路径' or 'directory path'), so the baseline score is 3. The description doesn't compensate or add value, but the schema adequately covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建目录' (Create directory) is a tautology that essentially restates the tool name 'create_directory' in Chinese. While it does specify the verb ('create') and resource ('directory'), it doesn't distinguish this tool from any potential siblings or provide any additional context about what kind of directory creation this performs (e.g., local filesystem, remote, with specific permissions).
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 file operations like 'copy_file', 'delete_file', 'move_file', and 'list_directory', there's no indication of whether this is for creating directories in a specific context (e.g., browser, system) or any prerequisites. It's completely missing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('get screen size') without revealing any behavioral traits such as whether it returns current or maximum resolution, requires specific permissions, has side effects, or handles multi-monitor setups. For a tool with zero annotation coverage, this is a significant 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取屏幕尺寸', which is extremely concise but under-specified rather than efficiently informative. While it avoids waste, it fails to provide necessary context (e.g., what 'screen size' means, return format, or usage notes) that would help an agent use it correctly. Conciseness here comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'screen size' entails (e.g., resolution in pixels, physical dimensions, multi-monitor support) or the return format. For a tool that likely returns structured data, the lack of output schema means the description should compensate by detailing the response, which it doesn't do.
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% (since there are no parameters to describe). With no parameters, the baseline score is 4, as there's nothing for the description to compensate for. The description doesn't need to add parameter semantics beyond what the empty schema already provides.
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 '获取屏幕尺寸' (Get screen size) is a tautology that essentially restates the tool name 'get_screen_size' in Chinese. It specifies the verb ('get') and resource ('screen size'), but doesn't differentiate from siblings like 'get_system_info' or 'get_active_window' that might also provide screen-related data. The purpose is clear at a basic level but lacks specificity about what exactly is retrieved (resolution, dimensions, units).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a display), exclusions (e.g., not for remote systems), or sibling tools that might overlap (like 'get_system_info' which could include screen data). Without any usage context, the agent must infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. '复制文件' only states the action without any details on behavior: it does not specify if the copy overwrites existing files, preserves metadata, handles errors, requires specific permissions, or has rate limits. For a mutation tool with zero annotation coverage, this is a critical gap that leaves the agent guessing about important operational traits.
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 at just two characters ('复制文件'), which translates to 'copy file'. It is front-loaded with the core action and wastes no words. While brevity can indicate under-specification, in terms of structure and economy of language, every character serves the purpose of stating the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a file mutation operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to address key contextual aspects: behavioral traits (e.g., overwrite behavior, error handling), usage guidelines, or output expectations. The high schema coverage helps with parameters, but overall, the description does not provide enough information for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('source' and 'destination') clearly documented in the schema as file paths. The description adds no additional meaning about parameters beyond what the schema provides (e.g., path formats, restrictions). According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param info in the description, which applies here.
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 '复制文件' (copy file) is a tautology that merely restates the tool name 'copy_file' in Chinese. It does not specify what kind of file copying operation this performs (e.g., local file system, network, with overwrite behavior) or distinguish it from sibling tools like 'move_file'. While the verb 'copy' is clear, the description lacks specificity about the resource scope or operational 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. It does not mention prerequisites (e.g., file existence, permissions), exclusions (e.g., cannot copy directories based on sibling 'create_directory'), or comparisons to related tools like 'move_file' or 'write_file'. Without any usage context, an agent must infer everything from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '输入文本' only states the action without explaining how it works—e.g., whether it types into the active window, requires focus, simulates keystrokes, or has side effects like triggering events. It fails to describe key behavioral traits like error handling or performance implications.
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 at just two characters, with no wasted words. It is front-loaded and to the point, though this brevity contributes to its inadequacy in other dimensions. Every character serves the minimal purpose of stating the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a system interaction with two parameters) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how it behaves, or its context among siblings. For a tool that likely involves UI automation, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema itself. The description adds no additional meaning beyond what the schema provides—it doesn't clarify parameter interactions, constraints, or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 '输入文本' (input text) is a tautology that merely restates the tool name 'type_text' in Chinese. It doesn't specify what resource the text is being typed into (e.g., active window, browser field) or distinguish this tool from similar siblings like 'browser_type' or 'press_key'. The purpose is vague and 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 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 multiple sibling tools for text input (e.g., 'browser_type', 'press_key'), but the description doesn't indicate whether this tool is for general system-wide typing, browser-specific input, or another context. No prerequisites 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.
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. '启动浏览器' (launch browser) implies a creation/initialization action, but it doesn't specify what happens after launch (e.g., whether it opens a new window, returns a session ID, or has side effects like consuming system resources). It also doesn't mention potential failures, permissions needed, or interaction with other tools like 'sessionId' parameter usage.
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 two Chinese characters ('启动浏览器'), which directly translates to the tool's purpose. There is no wasted verbiage, and it's front-loaded with the core action, making it efficient despite its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a browser launch operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a session handle or success status), how it integrates with other browser tools, or any behavioral nuances, leaving significant gaps for an AI agent to understand its full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters ('headless' and 'sessionId') well-documented in the schema itself. The description adds no additional meaning about parameters beyond what's already in the schema, so it meets the baseline score of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '启动浏览器' (launch browser) is a tautology that essentially restates the tool name 'browser_launch' in Chinese. While it does specify the verb ('launch') and resource ('browser'), it doesn't distinguish this tool from other browser-related siblings like 'browser_navigate' or 'browser_close', nor does it provide any additional context about what launching entails.
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 multiple sibling tools that interact with browsers (e.g., 'browser_navigate', 'browser_close'), but the description doesn't indicate that this is specifically for initializing a browser instance, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose error handling (e.g., if selector fails), performance (e.g., timeouts), side effects, or return format. For a tool interacting with a browser, this leaves critical behavior unspecified.
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 phrase '获取元素文本', which is concise and front-loaded. However, it's overly terse—it could benefit from slightly more detail without losing efficiency, as it under-specifies the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that interacts with a browser (complex environment), the description is incomplete. It doesn't cover return values, error cases, or dependencies on other tools like 'browser_launch', making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are documented in the schema. The description adds no meaning beyond the schema's 'CSS 选择器' (CSS selector) and '会话 ID（可选）' (session ID optional). It doesn't explain selector syntax examples or session context, resulting in baseline adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取元素文本' (Get element text) states a clear verb ('获取' - get) and resource ('元素文本' - element text), but it's vague about what type of element (browser DOM element) and doesn't distinguish from sibling tools like 'get_clipboard' or 'read_file' that also retrieve text. It's functional 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?
No guidance on when to use this tool vs. alternatives is provided. It doesn't mention prerequisites (e.g., requires an active browser session), context (e.g., use after navigation), or differentiate from similar tools like 'browser_screenshot' for visual capture. The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '导航到网页' implies a navigation action but doesn't specify whether this opens a new tab/window, requires an existing browser instance, handles errors (e.g., invalid URLs), or has side effects like loading time. For a tool with potential dependencies and no annotation coverage, this is a significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('导航到网页'), which is extremely concise and front-loaded. It wastes no words, though it might be overly brief for a tool with potential complexity. This efficiency earns a high score, but it's not a perfect 5 due to possible under-specification in 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?
Given the complexity of a browser navigation tool (which may involve session management, error handling, and dependencies), the description is incomplete. No annotations exist to cover behavioral traits, and there's no output schema to explain return values. The description alone is insufficient for an agent to fully understand how to use this tool effectively in context with its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters (url and optional sessionId). The description adds no additional meaning beyond what the schema provides, such as URL format examples or sessionId usage context. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 '导航到网页' (navigate to web page) states a clear verb+resource combination, indicating this tool opens a URL in a browser. However, it doesn't distinguish itself from potential sibling tools like browser_launch (which might initiate a browser) or differentiate navigation from other browser operations. The purpose is understandable but lacks specificity about how it relates to other browser tools in the server.
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), exclusions, or comparisons to siblings like browser_launch or browser_click. Without such context, an agent might struggle to choose between this and other browser-related tools in the list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('获取磁盘信息') but doesn't describe any behavioral traits such as whether it's read-only, what permissions are required, potential side effects, or output format. For a tool with zero annotation coverage, this is a significant 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 that directly states the tool's function. There is no wasted verbiage or unnecessary elaboration, making it front-loaded and efficient. Every word earns its place by conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what disk information is returned (e.g., usage stats, partition details) or any behavioral context, leaving the agent with insufficient information to understand the tool's full scope and output.
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 the schema description coverage is 100% (since there are no parameters to describe). In such cases, the baseline score is 4, as there are no parameters for the description to compensate for. The description doesn't need to add parameter semantics beyond what the schema provides.
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 '获取磁盘信息' (Get disk information) is a tautology that essentially restates the tool name 'get_disk_info'. While it correctly identifies the resource (disk), it lacks specificity about what information is retrieved (e.g., usage, partitions, capacity) and doesn't distinguish this tool from sibling tools like 'get_system_info' or 'get_network_info'. The purpose is clear but overly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. Given sibling tools like 'get_system_info' that might overlap in functionality, the lack of differentiation leaves the agent without clear 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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as file format support, encoding issues, error handling (e.g., if file doesn't exist), or performance aspects. This leaves significant gaps for a tool that interacts with the file system.
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 phrase '读取文件内容', which is very concise and front-loaded with the core action. There's no wasted text, making it efficient, though it could benefit from more detail to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what is returned (e.g., text content, binary data) or address potential complexities like file permissions or size limits. Given the context, more information is needed to make this tool fully understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter documented as '文件路径' (file path). The description adds no additional meaning beyond this, as it doesn't elaborate on path formats or constraints. Given high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.
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 '读取文件内容' (Read file content) states the basic action (read) and resource (file content), which is clear but minimal. It doesn't distinguish from siblings like 'search_files' or 'write_file', making it somewhat vague in context. However, it avoids tautology by specifying the action beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose 'read_file' over 'search_files' for content retrieval or 'write_file' for file operations. The description lacks any context or exclusions, leaving usage unclear.
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. '截取网页截图' implies a read-only operation that captures visual content, but doesn't disclose important behavioral aspects: whether it requires an active browser session, what happens if no session exists, whether it saves automatically or requires a path parameter, what the default behavior is when parameters are omitted, or what format/quality the screenshot has. For a tool with 3 parameters and no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 characters (2 Chinese words), with zero wasted words. It's front-loaded with the core function and contains no unnecessary elaboration. For a simple tool, this level of brevity is appropriate and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (screenshot data? file path? success status?), doesn't mention error conditions, and provides minimal behavioral context. For a tool that likely interacts with browser sessions and file systems, more completeness is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 3 parameters (path, fullPage, sessionId) with their types and optional status. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain what 'fullPage' means in practice, what format 'path' should use, or how 'sessionId' relates to browser sessions. With complete schema coverage, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '截取网页截图' (capture webpage screenshot) clearly states the tool's basic function as a screenshot utility, but it's vague about scope and doesn't distinguish it from sibling tools like 'take_screenshot' or 'take_screenshot_region'. It specifies 'webpage' which differentiates it from general screen capture tools, but doesn't clarify how it differs from other browser-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'take_screenshot' or 'take_screenshot_region'. There's no mention of prerequisites (such as needing an active browser session), nor any context about when this specific browser screenshot tool is preferable to general screenshot tools. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action (close) but doesn't describe what 'close' means behaviorally - whether it terminates applications, closes GUI windows, requires specific permissions, has side effects on unsaved data, or provides any confirmation/feedback. For a potentially destructive operation with zero annotation coverage, this is inadequate.
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 maximally concise with a single four-character phrase that directly states the tool's purpose. There's zero waste or unnecessary elaboration, making it efficiently front-loaded despite its simplicity.
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 potentially destructive window management tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral implications, success/failure conditions, error handling, or what constitutes a 'window' in this context. Given the complexity of window management operations and lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'title' documented as '窗口标题' (window title). The description doesn't add any meaningful parameter semantics beyond what the schema already provides - no examples of valid titles, format requirements, or matching behavior. Baseline 3 is appropriate when schema does the heavy lifting.
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 '关闭指定窗口' (Close specified window) clearly states the action (close) and target (window), but it's vague about what constitutes a 'specified window' and doesn't differentiate from sibling tools like 'browser_close' or 'activate_window'. It provides basic purpose but lacks specificity about window identification method or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'browser_close', 'minimize_window', 'maximize_window', or 'kill_process'. The description doesn't mention prerequisites, exclusions, or appropriate contexts for window closure versus other window management operations.
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 only states what the tool does ('获取进程详细信息') without mentioning permissions needed, output format, error handling, or system impact (e.g., whether it's read-only or has side effects). This is inadequate for a tool that likely interacts with system processes.
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 phrase ('获取进程详细信息') that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that retrieves system process information. It lacks details on return values, error cases, or behavioral traits (e.g., read-only nature), which are critical for an AI agent to use it correctly in a system context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'name' documented as '进程名称' (process name). The description doesn't add any meaning beyond this, such as format examples or constraints. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取进程详细信息' (Get process details) states a clear verb ('获取' - get) and resource ('进程详细信息' - process details), providing basic purpose. However, it doesn't differentiate from sibling tools like 'list_processes' or 'kill_process', leaving ambiguity about what specific information is retrieved versus other process-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., vs. 'list_processes' for enumeration), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions launching but doesn't describe what happens on success/failure, whether it requires specific permissions, if it runs in background/foreground, or how errors are handled. The description is minimal and leaves critical behavioral traits unspecified.
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 a single phrase ('启动应用程序'), which is front-loaded and wastes no words. For a simple tool, this brevity is appropriate, though it may sacrifice clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of launching applications (which can involve permissions, environment variables, error handling) and no annotations or output schema, the description is incomplete. It doesn't cover return values, failure modes, or system-specific behaviors, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (path, args, wait) with descriptions. The tool description adds no additional meaning beyond what's in the schema, such as examples of valid paths or typical args usage. Baseline 3 is appropriate when the schema does the heavy lifting.
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 '启动应用程序' (launch application) states the basic verb+resource but is vague about scope and differentiation. It doesn't specify what types of applications (local executables, scripts, etc.) or how it differs from sibling tools like 'browser_launch' or 'run_cmd'. The purpose is clear at a high level 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?
No guidance is provided on when to use this tool versus alternatives like 'browser_launch' for web browsers, 'run_cmd' for command-line execution, or 'activate_window' for already-running applications. The description offers no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions maximizing a window but doesn't disclose behavioral traits like whether it requires a window to be active, what happens if the window is already maximized, or if it affects other windows. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '最大化窗口', which is extremely concise and front-loaded with the core action. There is no wasted text, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a window operation with no annotations and no output schema), the description is incomplete. It doesn't explain what happens on success or failure, return values, or error conditions. For a tool that interacts with system windows, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'title' documented as '窗口标题' (window title). The description adds no additional meaning beyond the schema, such as examples or constraints. Since the schema fully covers the parameter, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '最大化窗口' (maximize window) states a clear verb ('maximize') and resource ('window'), but it's vague about what type of window (e.g., application window, browser window) and doesn't distinguish from sibling tools like 'activate_window' or 'minimize_window'. It provides basic purpose 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?
No guidance is provided on when to use this tool versus alternatives like 'activate_window' or 'minimize_window', or prerequisites such as needing an existing window. The description only states the action without context, leaving usage unclear.
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 the action (execute CMD command) but lacks critical details such as execution environment (e.g., shell context, permissions needed), potential side effects (e.g., system changes, security risks), error handling, or output format. This is inadequate for a tool that executes commands, which can have significant behavioral implications.
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 a single phrase '执行 CMD 命令', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to scan and understand quickly.
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 a command execution tool with no annotations and no output schema, the description is incomplete. It fails to address key contextual aspects like what the tool returns (e.g., output, exit codes), execution constraints, or safety considerations, leaving significant gaps for an AI agent to understand how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('command' and 'timeout'). The description adds no additional meaning beyond what the schema provides, such as examples of valid commands or timeout behavior. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately documents the parameters without extra help from the description.
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 '执行 CMD 命令' (Execute CMD command) clearly states the verb (execute) and resource (CMD command), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'run_powershell' or other execution tools, leaving the scope vague regarding what type of commands or environment it operates in.
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 on when to choose 'run_cmd' over 'run_powershell' or other execution-related tools in the sibling list, nor any context about prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what happens after capture (e.g., saves to a file if 'path' is provided, returns image data, requires user permissions, or has side effects like overwriting files). For a tool with potential system interactions, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '截取屏幕区域', which is extremely concise and front-loaded with the core action. There is no wasted language, making it efficient for quick understanding, though it may be overly terse for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involves screen capture and file operations), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like output format, error handling, or dependencies, leaving gaps for an AI agent to infer usage correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (x, y, width, height, path). The description adds no additional meaning beyond the schema, such as coordinate system details (e.g., origin at top-left) or path format examples. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '截取屏幕区域' (capture screen region) states the basic action but is vague about specifics. It uses a verb+resource structure but doesn't distinguish from the sibling 'take_screenshot' tool or clarify what 'capture' means (e.g., saves to file, returns image data). The purpose is understandable but lacks precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention the sibling 'take_screenshot' tool (which likely captures the full screen) or 'browser_screenshot' (for browser-specific captures), nor does it specify prerequisites like screen access or file system permissions. Usage is implied but not explicitly defined.
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 the action ('activate') but doesn't explain what activation entails (e.g., bringing the window to the front, focusing it), potential side effects (e.g., interrupting other processes), or constraints (e.g., may fail if the window isn't found). This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese: '激活指定窗口（通过标题）'. It's front-loaded with the core action and includes the key parameter method. There's no wasted text, making it appropriately concise for a simple tool, though it could be slightly more informative without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects like what happens on success/failure, whether it requires specific permissions, or what the return value might be. For a tool that modifies window state, this lack of context leaves significant gaps for an AI agent to understand its full implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'title' documented as '窗口标题（支持部分匹配）' meaning 'window title (supports partial matching)'. The description adds minimal value beyond this, as it only repeats '通过标题' ('by title'). However, with 0 parameters beyond the single documented one, the baseline is 4, as the schema fully covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '激活指定窗口（通过标题）' translates to 'Activate specified window (by title)', which clearly states the verb (activate) and resource (window). However, it doesn't distinguish this tool from sibling tools like 'get_active_window' or 'maximize_window', which also operate on windows but serve different purposes. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this is appropriate (e.g., to bring a window to the foreground) or when not to use it (e.g., if the window is already active). There's no reference to sibling tools like 'get_active_window' for checking status or 'close_window' for other actions, leaving usage context implied at best.
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 states the action but lacks details on behavioral traits such as whether it requires a browser session, handles errors, waits for elements, or has side effects. This is inadequate for a tool that interacts with UI elements.
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 phrase ('输入文本到元素') that directly conveys the core action without unnecessary words. It's front-loaded and appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that performs UI interaction, the description is incomplete. It doesn't cover expected outcomes, error conditions, or dependencies (e.g., needing an active browser session), leaving significant gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'selector' (CSS selector), 'text' (text to input), and 'sessionId' (optional session ID). The description adds no additional meaning beyond the schema, so it meets the baseline but doesn't enhance parameter understanding.
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 '输入文本到元素' (Input text to element) clearly states the action (input text) and target (element), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'type_text' or 'press_key', which might have overlapping functionality in text input scenarios.
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. With siblings like 'type_text' and 'press_key' available, there's no indication of context-specific usage, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('删除文件或目录') but lacks critical details: whether deletion is permanent or reversible, if it requires specific permissions, what happens with non-empty directories, or error handling. This is a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('删除文件或目录') with zero waste. It is front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with no annotations and no output schema, the description is incomplete. It fails to address key aspects like return values, error conditions, or safety warnings, leaving significant gaps for an AI agent to understand the tool's behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'path' documented as '文件或目录路径' (file or directory path). The description adds no additional meaning beyond what the schema provides, such as path format examples or constraints, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除文件或目录' clearly states the verb ('删除' meaning delete) and resource ('文件或目录' meaning file or directory), making the purpose unambiguous. It doesn't explicitly distinguish from sibling tools like 'copy_file' or 'move_file', but the action is distinct enough to infer differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'copy_file' or 'move_file', nor does it mention prerequisites such as file existence or permissions. The description only states what it does, not when or why to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '获取系统信息' implies a read-only operation, but it doesn't specify what information is returned (e.g., OS version, hardware details, uptime), whether it requires permissions, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '获取系统信息', which is extremely concise and front-loaded with the core purpose. There's no wasted space or unnecessary elaboration, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what system information is retrieved, the return format, or how it differs from sibling tools. For a tool in a server with many specific system-info siblings, more context is needed to guide proper usage.
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% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取系统信息' (Get system information) states a clear verb and resource, but it's vague about what specific system information is retrieved. It doesn't distinguish from siblings like get_disk_info, get_network_info, or get_process_info, which all get specific types of system information. 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?
No guidance is provided on when to use this tool versus alternatives. With siblings like get_disk_info, get_network_info, and get_process_info that retrieve specific system data, the description doesn't indicate whether this tool provides a comprehensive overview, a subset, or something different. There's no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '结束进程' implies a destructive mutation, but it doesn't state whether it requires elevated permissions, what happens on failure (e.g., process not found), or if it affects system stability. For a destructive tool with zero annotation coverage, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('结束进程') that front-loads the core action with zero waste. It's appropriately sized for a straightforward tool, though brevity limits informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 2 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral traits like permissions, error handling, or return values, leaving critical gaps for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('name' as process name and 'force' as optional boolean). The description adds no additional meaning beyond what the schema provides, such as examples of valid names or effects of 'force'. Baseline 3 is appropriate when the schema does the heavy lifting.
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 '结束进程' (end process) clearly states the verb ('end') and resource ('process'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'get_process_info' (read-only) and 'list_processes' (list). However, it doesn't specify whether it terminates by name or PID, which could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing admin rights), when to prefer 'force' mode, or how it differs from system-specific commands. The description alone offers no usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('list directory contents') without detailing permissions needed, error handling (e.g., for invalid paths), output format, or any side effects. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('列出目录内容') that directly conveys the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 is incomplete. It doesn't explain what the tool returns (e.g., file list format, error responses) or behavioral aspects like read-only nature, which is critical for an agent to use it correctly in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'path' parameter documented as '目录路径' (directory path). The description doesn't add any meaning beyond this, such as path format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出目录内容' (list directory contents) clearly states the verb ('list') and resource ('directory contents'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_files' or 'list_processes', which also list resources, 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. It doesn't mention when to choose 'list_directory' over 'search_files' for finding files or 'list_processes' for listing processes, nor does it specify prerequisites or exclusions, 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.
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 only states what the tool does ('列出正在运行的进程') but doesn't describe what information is returned, format of output, whether it's real-time or cached data, permissions needed, or any side effects. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple listing tool and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a description that only states the basic purpose, this is incomplete. For a process listing tool, the description should ideally mention what information is returned (PID, name, CPU usage, etc.), format considerations, or any limitations. The current description is too minimal given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention parameters at all, but the input schema has 100% description coverage with the 'filter' parameter documented as '过滤进程名（可选）' (filter process name, optional). Since schema coverage is high, the baseline is 3 even without parameter information in the description.
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 '列出正在运行的进程' (List running processes) clearly states the verb ('列出' - list) and resource ('正在运行的进程' - running processes). It's specific about what it does, though it doesn't explicitly distinguish from the sibling 'get_process_info' tool, which might provide different information about processes.
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's no mention of when to use it instead of 'get_process_info' or other sibling tools, nor any context about prerequisites 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?
No annotations are provided, so the description carries the full burden. It states what the tool does but doesn't disclose behavioral traits such as whether it returns window IDs, titles, or other metadata; whether it includes minimized windows; what format the output is in; or any performance considerations. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence '列出所有打开的窗口' (List all open windows) that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'list' entails (e.g., returns window titles, IDs, or other properties), how results are structured, or any limitations. For a tool that interacts with system windows, more context on output behavior is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'filter' documented as '过滤窗口标题（可选）' (Filter window title, optional). The description doesn't add any meaning beyond this, but since schema coverage is high, the baseline score of 3 is appropriate as the schema adequately explains the parameter.
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 '列出所有打开的窗口' (List all open windows) clearly states the verb 'list' and resource 'open windows', making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'get_active_window' or 'activate_window', but the core action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_active_window' (which gets only the active window) or 'activate_window' (which activates a specific window). There's no mention of prerequisites, context, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('move or rename') but doesn't disclose critical traits: whether it overwrites existing files at the destination, requires specific permissions, handles errors (e.g., if source doesn't exist), or affects file metadata. For a mutation tool with zero annotation coverage, this is a significant 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 that front-loads the core action without any wasted words. It's appropriately sized for a simple tool, making it easy to parse quickly. Every part of the description earns its place by directly stating the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks behavioral details (e.g., overwrite behavior, error handling), usage context, and output information. While the schema covers parameters well, the description doesn't add enough value to compensate for missing annotations and output schema, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions ('源文件路径' for source path, '目标文件路径' for destination path). The description adds no additional meaning beyond the schema, such as path format examples or constraints (e.g., absolute vs. relative paths). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
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 '移动或重命名文件' (move or rename a file) clearly states the verb ('move/rename') and resource ('file'), making the purpose immediately understandable. It distinguishes from siblings like 'copy_file' (which copies) and 'delete_file' (which removes), though it doesn't explicitly contrast with them. The purpose is specific but could be slightly more detailed about scope (e.g., across directories vs. same location).
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 when to choose 'move_file' over 'copy_file' (for duplication) or 'rename_file' (if a sibling exists), nor does it specify prerequisites like file existence or permissions. Usage is implied by the action but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states the action ('move mouse') but doesn't disclose whether this requires elevated permissions, affects system state, has rate limits, or what happens if coordinates are out of bounds. For a tool that interacts with system input, this lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's function. It's front-loaded with the core action and contains no redundant or unnecessary information. Every word earns its place, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (system interaction with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after the move (e.g., whether it returns success/failure, if the mouse stays at the position), nor does it cover error conditions or behavioral nuances. For a tool that could have side effects, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in Chinese ('X坐标', 'Y坐标', '是否平滑移动'). The tool description adds no additional parameter semantics beyond what the schema provides. Since the schema adequately documents parameters, the baseline score of 3 is appropriate—no extra value is added, but no gap exists either.
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 '移动鼠标到指定位置' (Move mouse to specified position) clearly states the verb ('move') and resource ('mouse'), making the purpose immediately understandable. It distinguishes from siblings like 'mouse_click' (which clicks) and 'get_mouse_position' (which reads position). However, it doesn't specify coordinate system or screen reference, which could help differentiate from potential 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 alternatives. It doesn't mention when to prefer 'mouse_click' (for clicking) or 'get_mouse_position' (for reading), nor does it specify prerequisites like needing mouse control permissions or appropriate screen context. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action ('press keyboard key') but lacks critical details: whether this simulates a single key press/release, requires focus on a specific application, has side effects (e.g., triggering system shortcuts), or handles international keyboards. For a tool with potential system-wide impact and no annotation coverage, this is a significant 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 a single, efficient phrase ('按下键盘按键') that directly conveys the core action without any fluff. It's front-loaded with the essential verb and object, making it immediately understandable. Every word earns its place, and there's no wasted text or redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interacting with system input, 2 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling (e.g., invalid key names), return values (e.g., success status), or system dependencies (e.g., OS compatibility). For a low-level input simulation tool, more context is needed to ensure safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for 'key' (key name like enter) and 'modifiers' (modifier keys like control). The description adds no parameter-specific information beyond what's in the schema, such as examples of valid key names beyond 'enter, tab, escape' or how modifiers combine. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '按下键盘按键' (press keyboard key) clearly states the action (press) and target (keyboard key) in a simple verb+resource format. It distinguishes from sibling tools like 'type_text' (which inputs text strings) and 'mouse_click' (which handles mouse actions), making the purpose specific and unambiguous. However, it doesn't explicitly mention virtual/software keyboard simulation versus physical hardware interaction.
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 'type_text' (for text input) or 'browser_type' (for browser-specific typing). There's no mention of prerequisites (e.g., needing a focused window), typical use cases (e.g., automation shortcuts), or exclusions (e.g., not for continuous key holding). This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('执行' - execute) but doesn't describe what happens during execution (e.g., runs in a shell, returns output/errors, affects system state), security implications, permission requirements, or error handling. For a tool that executes system commands with potential side effects, this is a significant 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 sentence that directly states the tool's function without any fluff. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there is no wasted verbiage.
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 PowerShell commands (which can have system-wide effects) and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like output format, error handling, security risks, or dependencies. For a tool with potential high impact and no structured safety hints, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('command' and 'timeout') fully described in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples of valid commands, timeout defaults, or script formats). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding.
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 '执行 PowerShell 命令或脚本' clearly states the tool's purpose: executing PowerShell commands or scripts. It specifies both the verb ('执行' - execute) and the resource ('PowerShell 命令或脚本' - PowerShell commands or scripts), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'run_cmd', which likely executes CMD commands instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to choose PowerShell over CMD (via 'run_cmd') or other execution methods, nor any context about prerequisites, security considerations, or typical use cases. Usage is implied only by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions wildcard support, which adds some behavioral context beyond basic searching. However, it fails to disclose critical traits: whether it's read-only or has side effects, error handling, performance implications, or output format. For a search tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at '搜索文件（支持通配符）' (Search files (supports wildcards)). It's front-loaded with the core purpose and includes essential behavioral detail in parentheses. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a search tool. It doesn't explain what the tool returns (e.g., file list, paths, metadata), error conditions, or limitations. The complexity is moderate (2 parameters), but the description lacks necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (directory, pattern) well-documented in the schema. The description adds minimal value beyond the schema by implying wildcard usage in the pattern parameter. Baseline is 3 since the schema does the heavy lifting, and the description doesn't provide additional syntax or format details.
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 searching files with wildcard support. It specifies the verb ('搜索') and resource ('文件'), distinguishing it from siblings like list_directory (which lists without search) or read_file (which reads content). However, it doesn't explicitly differentiate from other potential search tools, though none exist 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., needing an existing directory), exclusions, or comparisons to similar tools like list_directory for basic listing. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('设置' - set) but doesn't describe what happens (e.g., overwrites existing content, requires permissions, system-specific behavior, or potential side effects). For a mutation tool with zero annotation coverage, this is a significant 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 a single, direct phrase ('设置剪贴板内容') with zero wasted words. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, making it highly concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., what happens to existing clipboard data), error conditions, or return values. For a tool that modifies system state, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'text' fully documented as '要设置的文本内容' (text content to set). The description doesn't add any meaning beyond this, such as format constraints or examples. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '设置剪贴板内容' (Set clipboard content) clearly states the verb ('设置' - set) and resource ('剪贴板内容' - clipboard content), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'clear_clipboard' or 'get_clipboard', but the action is specific enough to understand its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'clear_clipboard' (for emptying) or 'get_clipboard' (for reading), nor does it specify prerequisites or contexts for setting clipboard content, leaving usage unclear.
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. '截取屏幕截图' implies a read-only operation that captures screen content, but it doesn't disclose behavioral aspects like whether it requires permissions, saves files automatically, overwrites existing files, or handles errors. For a tool with system-level access, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('截取屏幕截图') that directly conveys the core action. It's front-loaded with zero redundant information, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that performs a system-level operation (screenshot capture), the description is inadequate. It doesn't explain what the tool returns (e.g., file path, success status), error conditions, or dependencies, leaving critical gaps for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('path' and 'format') well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '截取屏幕截图' (Take screenshot) clearly states the verb ('take') and resource ('screenshot'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'browser_screenshot' or 'take_screenshot_region', which would require explicit distinction for 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 'browser_screenshot' (for browser-specific screenshots) or 'take_screenshot_region' (for partial screenshots). Without any contextual cues, the agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '关闭浏览器' implies a destructive action (closing), it does not specify critical details such as whether this action is reversible, if it requires confirmation, what happens to unsaved data, or if it affects all browser windows. This is a significant gap for a tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase ('关闭浏览器'), which is extremely concise and front-loaded with the core action. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension.
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 potential complexity (closing a browser may have side effects), lack of annotations, and no output schema, the description is insufficient. It does not explain what happens upon execution (e.g., success/failure indicators, error conditions) or behavioral nuances, leaving the agent with incomplete context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single optional parameter 'sessionId', documented as '会话 ID（可选）' (session ID, optional). The description adds no additional parameter information, but with high schema coverage and zero required parameters, the baseline is high. A score of 4 reflects that the schema adequately handles parameter semantics without needing description support.
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 '关闭浏览器' (close browser) clearly states the verb ('close') and resource ('browser'), making the purpose immediately understandable. However, it does not distinguish this tool from sibling tools like 'close_window' or specify whether it closes a specific browser instance or all browsers, which prevents 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 such as 'close_window' or 'browser_launch'. It lacks context about prerequisites (e.g., whether a browser must be open) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '清空剪贴板' implies a destructive mutation (clearing), but doesn't specify whether this requires special permissions, if the action is reversible, what happens to multiple clipboard formats, or if there are any side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 maximally concise - a single phrase that communicates the core action. There's zero wasted language or unnecessary elaboration. Given the tool's simple purpose, this is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'success' looks like (does it return confirmation?), what errors might occur (e.g., if clipboard is empty or inaccessible), or system-specific considerations. The simplicity of having zero parameters doesn't compensate for the lack of behavioral context needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema). With no parameters to document, the baseline is 4. The description appropriately doesn't attempt to explain nonexistent parameters, though it could theoretically mention that no configuration options are available.
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 '清空剪贴板' (Clear clipboard) clearly states the verb ('clear') and resource ('clipboard'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_clipboard' and 'set_clipboard' by specifying the destructive action. However, it doesn't explicitly mention what 'clipboard' refers to (system clipboard vs. application-specific), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing clipboard access), when it's appropriate (e.g., after copying sensitive data), or what happens to clipboard contents (permanently lost vs. recoverable). It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '获取剪贴板内容' implies a read operation but doesn't specify what happens on failure (e.g., empty clipboard), whether it returns text, images, or other formats, or if there are system-specific limitations. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient phrase ('获取剪贴板内容') that directly conveys the core purpose without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and no output schema, it fails to provide crucial behavioral details like return format or error handling, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取剪贴板内容' (Get clipboard content) clearly states the verb 'get' and the resource 'clipboard content', making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'clear_clipboard' or 'set_clipboard', which would require mentioning it's a read operation versus modification operations.
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 'clear_clipboard' or 'set_clipboard'. It doesn't mention prerequisites (e.g., requires clipboard access) or typical use cases (e.g., retrieving copied text). This leaves the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '获取' (get) implies a read-only operation, it doesn't specify whether this requires specific permissions, what coordinate system is used (screen vs. window), whether it returns absolute or relative positions, or if there are any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 phrase that directly states the tool's function without any wasted words. It's appropriately sized for a simple tool with no parameters and gets straight to the point. Every character earns its place in conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It tells the agent what the tool does at a basic level. However, without an output schema, the description doesn't explain what format the mouse position is returned in (coordinates, units, etc.), leaving the agent to discover this through trial or additional documentation.
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 with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since there are no parameters to explain beyond what the empty schema already indicates.
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 current mouse position), which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'move_mouse' or 'mouse_click' by focusing on retrieval rather than action. However, it doesn't explicitly differentiate from all siblings in the system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, timing considerations, or comparison to related tools like 'get_active_window' or 'get_screen_size' that might provide complementary information. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('get') but lacks behavioral details such as whether this is a read-only operation (implied but not stated), what happens if no window is active, the format of the returned data, or any system dependencies. For a tool with zero annotation coverage, this is a significant 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 a single, efficient sentence in Chinese ('获取当前激活的窗口'), which directly conveys the purpose without any wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., window title, handle, or other properties), which is critical for an agent to use it effectively. With no structured output information, the description should compensate more to be 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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline. No extra parameter information is provided or needed, but it doesn't explicitly state 'no parameters required,' which could slightly improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前激活的窗口' (Get the currently active window) clearly states the verb ('get') and resource ('active window'), making the purpose unambiguous. It distinguishes from siblings like 'list_windows' (which lists all windows) and 'activate_window' (which changes the active window). However, it doesn't specify what information about the window is returned (e.g., title, handle, position), keeping it from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the current active window information is needed, but doesn't explicitly state when to use this tool versus alternatives like 'list_windows' for all windows or 'get_screen_size' for display info. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent in tool selection.
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:

[![windows-automation-mcp MCP server](https://glama.ai/mcp/servers/eva-wanxin-git/windows-automation-mcp/badges/card.svg)](https://glama.ai/mcp/servers/eva-wanxin-git/windows-automation-mcp)

Score Badge

Copy to your README.md:

[![windows-automation-mcp MCP server](https://glama.ai/mcp/servers/eva-wanxin-git/windows-automation-mcp/badges/score.svg)](https://glama.ai/mcp/servers/eva-wanxin-git/windows-automation-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/eva-wanxin-git/windows-automation-mcp'

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