wxauto MCP Server

by cluic

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation3/5
The tool set has clear functional groupings (e.g., friend management, message sending, session handling, system operations), but there is notable overlap within groups. For example, 'get_sessions', 'get_unread_sessions', and 'filter_sessions' all retrieve session lists with slight variations, which could cause confusion. Similarly, multiple send tools ('send_message', 'send_image', 'send_files', 'send_directory_files', 'send_url_card') target different media types but share similar parameters, risking misselection if not carefully reviewed.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., 'get_friends', 'send_message', 'switch_chat'), which aids predictability. However, there are minor deviations like 'wechat_activate' (verb_adjective) and 'wechat_list_tools' (verb_noun_noun), and some tools use underscores inconsistently (e.g., 'check_file_exists' vs. 'get_my_info'). Overall, the naming is mostly consistent with a few irregularities that do not severely hinder usability.
Tool Count3/5
With 27 tools, the count is borderline high for a WeChat automation server, suggesting potential bloat. While the domain (WeChat automation) is broad, covering friend management, messaging, sessions, and system operations, some tools could be consolidated (e.g., multiple session retrieval tools). The count is not extreme but may overwhelm agents with redundant or overlapping functionality.
Completeness4/5
The tool set provides comprehensive coverage for core WeChat automation tasks, including friend CRUD (add, accept, list), messaging (send various types, retrieve history), session management, and system operations (initialize, status, activation). Minor gaps exist, such as no tools for deleting friends or managing group settings beyond listing, but agents can likely work around these with available tools for basic workflows.
Average 3/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action '发送' (send) but doesn't disclose behavioral traits such as rate limits, authentication needs, whether it's synchronous/asynchronous, error handling, or what happens on failure (e.g., partial sends). For a mutation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by parameter details. It uses minimal sentences without redundancy, though it could be slightly more structured (e.g., separating purpose and parameters clearly).
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, 0% schema coverage, no output schema, and a mutation tool with 1 parameter, the description is incomplete. It lacks details on return values, error conditions, side effects, and operational constraints, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'messages' is a JSON array with items containing 'msg' and 'who', which clarifies the structure beyond the schema's 'string' type. However, it doesn't explain the semantics of 'msg' (message content) and 'who' (recipient identifier), leaving ambiguity in usage.
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 '发送' (send) and the resource '消息' (messages), with the qualifier '批量' (bulk) indicating it handles multiple messages at once. It distinguishes from sibling tools like 'send_message' (singular) and 'send_files' (different resource type). However, it doesn't specify the target platform or context beyond the sibling tool names suggesting WeChat.
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 explicit guidance on when to use this tool versus alternatives like 'send_message' (for single messages) or 'send_files' (for files). The description implies bulk messaging but doesn't state prerequisites, limitations, or comparative scenarios with other sending tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sending files but doesn't disclose behavioral traits like whether this requires authentication, what happens if files are large, if there are rate limits, or what the expected output is. The description is minimal and lacks critical operational context for a tool that performs file operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by parameter explanations. It uses minimal sentences without waste, though it could be slightly more structured (e.g., separating purpose from parameters more clearly). Overall, it's efficient and 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 the tool's complexity (file operations with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'sending' entails (e.g., via chat, email), potential errors, or return values. For a tool that interacts with files and recipients, more context is needed to ensure safe and correct 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 description adds meaningful parameter semantics beyond the schema, which has 0% coverage. It explains that 'directory' is a path, 'who' is an optional recipient, and 'pattern' is a file matching pattern with default '*'. This compensates well for the lack of schema descriptions, though it doesn't provide format details or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('发送目录下的所有文件' - send all files in a directory) which is clear but vague. It specifies the action and resource but doesn't differentiate from sibling tools like 'send_files' or 'send_image' that might handle similar file-sending operations. The purpose is understandable but lacks specificity 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 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 lists parameters but doesn't mention context, prerequisites, or exclusions. With sibling tools like 'send_files' and 'send_image' available, there's no indication of when this directory-based sending is preferred over other file-sending methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('accept new friend requests') which implies a write/mutation operation, but doesn't disclose permissions needed, side effects (e.g., notification to sender), error conditions, or response format. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose followed by a parameter list. Every element earns its place: the action, parameters, and their roles. It could be slightly more structured but avoids 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 (mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after acceptance, error cases, or return values. For a friend-request acceptance tool in a chat system, more context about behavior and outcomes 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 0%, so the schema provides no parameter documentation. The description compensates by listing all 4 parameters with brief Chinese explanations: content (required, friend request content), exact (default false, whether to match exactly), remark (optional, nickname), and tags (optional, tag list). This adds meaningful semantics beyond the bare schema, though details like format constraints are missing.
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 '接受新的好友请求' (accept new friend requests), which is a specific verb+resource combination. It distinguishes from siblings like 'add_friend' (which likely initiates requests) and 'get_new_friends' (which likely retrieves pending requests). However, it doesn't explicitly differentiate from all siblings, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'add_friend' or 'get_new_friends'. It doesn't mention prerequisites (e.g., pending friend requests must exist), exclusions, or contextual triggers. The parameter list implies usage but offers no strategic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('检查文件是否存在') without detailing what 'exists' means (e.g., file permissions, symbolic links), error handling, or any side effects. This is a significant gap 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 extremely concise and front-loaded: it states the purpose in the first phrase and includes parameter info in a compact format. Every sentence (or phrase) earns its place with no wasted words, 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 simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain the return value (e.g., boolean, error messages) or behavioral aspects like what constitutes 'existence'. For a basic check tool, more context on output and edge cases would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: it names the parameter ('filepath') and provides a brief explanation ('文件路径' - file path). With 0% schema description coverage and 1 parameter, this compensates slightly but doesn't elaborate on format, constraints, or examples. Baseline is 3 due to the single parameter, but the added value is limited.
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: '检查文件是否存在' (check if a file exists). It specifies the verb ('检查' - check) and resource ('文件' - file), making the function unambiguous. However, it doesn't distinguish from siblings, as no other file-related tools are listed among the sibling tools, so differentiation isn't needed but also not addressed.
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 lacks context about prerequisites, such as file system access or permissions, and doesn't mention any related tools or scenarios where this check is necessary, leaving usage entirely implicit.
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. While '筛选' (filter) implies a read operation, the description doesn't specify whether this is a read-only tool, what permissions are required, how results are returned, or any rate limits. It provides minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the purpose and parameters. There's no wasted text, though some might argue it's too brief given the lack of annotations and output schema. The structure is front-loaded with the core purpose first.
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 0% schema description coverage, the description is incomplete. It doesn't explain what the tool returns (filtered session objects? just counts?), how results are structured, error conditions, or authentication requirements. For a filtering tool with two parameters, 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?
The description explicitly lists both parameters with Chinese explanations ('是否有未读' for has_unread meaning 'whether has unread', '是否免打扰' for ismute meaning 'whether muted'). With 0% schema description coverage, this adds meaningful semantic context that the schema lacks. However, it doesn't explain parameter formats, valid values, or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('筛选' meaning filter) and resource ('会话列表' meaning session list), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_sessions' or 'get_unread_sessions', which appear to be related session retrieval 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. With sibling tools like 'get_sessions' and 'get_unread_sessions' available, there's no indication of when filtering is preferred over direct retrieval or how this tool complements other session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('获取历史消息') and mentions a parameter, but doesn't describe any behavioral traits such as permissions needed, rate limits, whether it's read-only or destructive, or what the output looks like. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence that states the purpose and parameter. It's front-loaded with the main function, and there's no wasted text, making it efficient. However, it could be slightly improved with more structure or clarity, but it's well within acceptable bounds.
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, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't provide enough context for the agent to understand the tool's behavior, output, or how it fits among siblings, making it insufficient 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?
The description adds some meaning by explaining the parameter 'n' as '获取数量，默认50' (meaning 'number to retrieve, default 50'), which clarifies its purpose beyond the schema's type and default. However, with 0% schema description coverage and only one parameter, this provides basic but incomplete compensation, aligning with the baseline expectation.
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 'get') and resource ('历史消息' meaning 'historical messages'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_messages' or 'get_next_new_message', which appear to handle similar message-related functions, 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. With sibling tools like 'get_messages' and 'get_next_new_message' present, there's no indication of how this tool differs in context or when it should be preferred, leaving the agent with insufficient usage information.
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. The description only states what the tool does ('get recent group chat list') without revealing any behavioral traits, such as whether it's read-only, requires authentication, has rate limits, or what the output format might be. 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 ('获取最近群聊列表') that directly states the tool's 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recent' means, the structure of the returned list, or any error conditions. For a tool that likely returns data, more context is needed to help the agent understand how to interpret and use the results effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add any parameter information, but since there are no parameters, this is acceptable. The baseline for 0 parameters is 4, as the description doesn't need to compensate for missing schema details.
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 'Get recent group chat list', which clearly states the verb ('get') and resource ('recent group chat list'). However, it doesn't distinguish this tool from sibling tools like 'get_sessions' or 'get_chat_info', which also appear to retrieve chat-related data. 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 any context, prerequisites, or exclusions, such as how 'recent' is defined or if this should be used instead of 'get_sessions' for group-specific data. Without such information, the agent has little basis for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic action of sending files but reveals nothing about permissions required, rate limits, file size restrictions, supported file types, whether the operation is synchronous/asynchronous, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief at two sentences. The first sentence states the purpose, and the second explains parameters efficiently. There's no wasted text, though the structure could be slightly improved by separating purpose from parameter explanations more clearly.
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-sending mutation tool with no annotations and no output schema, the description is insufficient. It covers basic parameters but misses critical context: what the tool returns, error conditions, file constraints, authentication requirements, and how it differs from similar tools like send_directory_files. The agent would struggle to use this tool correctly without additional information.
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?
With 0% schema description coverage, the schema provides no parameter documentation. The description adds basic semantics for all three parameters: filepath (supports comma-separated multiple files), who (optional recipient), and exact (default false, exact matching). This compensates somewhat but lacks details like filepath format, who identifier format, or what 'exact matching' means in practice. The baseline would be 1 without this information, so the added value raises it to 3.
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 '发送' (send) and resource '文件' (files), making the purpose immediately understandable. It distinguishes from siblings like send_message, send_image, and send_url_card by specifying files rather than other content types. However, it doesn't explicitly differentiate from send_directory_files, which could be confusing.
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 send_files over send_directory_files or send_image, nor does it specify prerequisites or appropriate contexts for file sending. The only contextual hint is the optional 'who' parameter, but this isn't framed as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool sends an image but doesn't describe what 'send' entails (e.g., via chat, email, or other means), whether it requires authentication, potential rate limits, error conditions, or what happens on success/failure. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—just two sentences that directly state the purpose and parameters. It's front-loaded with the core function and wastes no words, though it could benefit from slightly more structure (e.g., separating purpose from parameter details).
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 'send' operation with no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral aspects like delivery method, success criteria, error handling, or integration context (e.g., which messaging platform), leaving the agent with insufficient information to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly lists both parameters ('filepath' and 'who') and provides brief semantic context ('图片路径' meaning 'image path' and '接收人，可选' meaning 'recipient, optional'). However, with 0% schema description coverage, it doesn't fully compensate by explaining format expectations (e.g., filepath syntax, who identifier format) or default behaviors beyond optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发送图片' meaning 'send image') and identifies the resource (image), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'send_files' or 'send_message', which might have overlapping functionality in a messaging 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 like 'send_files' or 'send_message'. It doesn't mention prerequisites, context requirements, or any exclusions that would help an agent choose between similar messaging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions a timeout parameter with default 5 seconds, which hints at potential delays or failures, but doesn't describe what happens on success/failure, whether the operation is reversible, what permissions are needed, or how it interacts with the friend request workflow. The description is minimal and leaves critical behavioral aspects 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 appropriately concise and front-loaded with the core purpose. The parameter explanations are efficiently listed in a single sentence with clear labels. No wasted words, though the structure could be slightly improved with bullet points or separation of purpose from parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool (adding friends) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns on success/failure, error conditions, side effects, or how it fits into the broader friend management workflow. The parameter semantics are helpful, but critical behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for all 6 parameters: 'keywords' as search terms (required), 'addmsg' as verification message, 'remark' as nickname, 'tags' as tag list, 'permission' with enum values (朋友圈/仅聊天), and 'timeout' with default. This adds substantial value beyond the bare schema, though it doesn't explain parameter interactions or constraints.
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 '添加新好友' (add new friend), which is a specific verb+resource combination. It distinguishes from siblings like 'accept_new_friend' (which accepts pending requests) and 'get_friends' (which retrieves existing friends). However, it doesn't explicitly mention how it differs from these siblings beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the friend must be found via search first), when not to use it (e.g., for existing friends), or clarify the relationship with 'accept_new_friend' for handling incoming friend requests.
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 '获取好友列表' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. The description mentions two parameters but doesn't explain broader behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another explaining parameters. It's front-loaded with the core functionality. While efficient, it could potentially benefit from slightly more context about the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. While it covers parameter basics, it doesn't address authentication requirements, rate limits, error conditions, or output format. Given the complexity of social data retrieval and the lack of structured documentation, more comprehensive description would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential parameter information that compensates for the schema gap. It explains that 'n' controls the number of friends to retrieve with a default of 10, and 'save_avatar' determines whether to fetch avatars with a default of false. This adds meaningful semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '获取好友列表' (get friends list), which is a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_new_friends' or 'get_sessions', which might also retrieve friend-related information in different contexts.
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 sibling tools like 'get_new_friends' and 'get_sessions' that might retrieve similar or overlapping data, there's no indication of when this specific friends list retrieval is appropriate versus those other options.
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 (get new friend request list) and mentions one parameter behavior. It doesn't describe what 'new' means (timeframe criteria), whether this requires authentication, rate limits, error conditions, or what the return format looks like. For a tool with no annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that both add value. The first states the tool's purpose, the second explains the parameter. There's no wasted text, though it could be slightly more structured with clearer separation between purpose and parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple sibling tools in the same domain, the description is incomplete. It doesn't explain what constitutes 'new' friend requests, how results are returned, error handling, or how this differs from 'get_friends' and 'accept_new_friend'. For a tool in a rich context with many related tools, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful parameter semantics beyond the schema. The schema only shows 'acceptable' is a boolean with default true, but the description explains it means '是否过滤掉已接受的好友申请' (whether to filter out already accepted friend applications). This clarifies the parameter's purpose and effect, which isn't evident from the schema alone. With 0% schema description coverage, the description effectively compensates for the single 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 clearly states the tool's purpose: '获取新的好友请求列表' (get new friend request list). It specifies the verb ('获取' - get) and resource ('新的好友请求列表' - new friend request list). However, it doesn't explicitly differentiate from sibling tools like 'get_friends' or 'accept_new_friend', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to friends and messaging (get_friends, accept_new_friend, get_messages, etc.), but the description offers no context about when this specific tool is appropriate versus those other options.
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 the tool retrieves '下一个' (next) new message, implying sequential or priority-based retrieval, but doesn't clarify what 'next' means (chronological, unread priority, etc.), whether it marks messages as read, or what happens when no new messages exist. For a message retrieval 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two parts: the core purpose statement followed by parameter documentation. Both sentences earn their place by providing essential information without redundancy. It could be slightly improved with clearer separation between purpose and parameters, but it's appropriately 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, no output schema, and a single parameter with 0% schema coverage, the description is incomplete. While it covers the parameter well, it doesn't explain what 'next' means operationally, what format the returned message takes, or how this differs from sibling tools. For a message retrieval tool in a chat context, this leaves too many contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'filter_mute' with its purpose ('是否过滤消息免打扰' - whether to filter muted messages) and default value ('默认false' - default false). With 0% schema description coverage and only 1 parameter, this provides complete parameter semantics beyond the bare schema, earning a high score.
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 '获取' (get/retrieve) and the resource '下一个聊天窗口的新消息' (next new message in chat window), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_messages' or 'get_unread_sessions', which appear to have overlapping functionality.
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 sibling tools like 'get_messages', 'get_unread_sessions', and 'filter_sessions' available, there's no indication of when this specific 'next new message' retrieval is appropriate versus other message-fetching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('get') but doesn't disclose behavioral traits such as whether this is a read-only operation, what specific information is returned (e.g., chat title, participants, status), or any limitations (e.g., requires an active chat window). 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 that directly states the tool's purpose without any wasted words. It is 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 'chat window information' includes (e.g., metadata, participants, status) or the return format, leaving the agent with insufficient context to understand the tool's full behavior 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 schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and a baseline score of 4 is appropriate as it avoids redundancy while being complete for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取当前聊天窗口信息' (Get current chat window information) clearly states the verb 'get' and the resource 'current chat window information', making the purpose understandable. It doesn't explicitly differentiate from siblings like 'get_sessions' or 'get_messages', but the focus on 'current chat window' provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_sessions' (which might list all sessions) or 'get_messages' (which retrieves message content). It lacks explicit when-to-use or when-not-to-use instructions, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('get WeChat session list') without mentioning any behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. 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 sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It is 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 fails to provide necessary context such as what the session list includes (e.g., chat windows, groups), how results are structured, or any behavioral constraints. For a tool in this environment, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it also doesn't compensate for any gaps since there are none. A baseline of 4 is applied as it meets the requirement for zero parameters.
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 'get') and resource ('微信会话列表' meaning 'WeChat session list'), making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'get_unread_sessions' or 'filter_sessions', which limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'get_unread_sessions' or 'filter_sessions'. It lacks any context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on 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 the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, pagination, or response format. This is a significant gap for a tool that likely interacts with messaging data.
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 purpose without unnecessary words. It is 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 return value includes (e.g., session IDs, unread counts) or behavioral aspects like error handling, which are crucial for an AI agent to use this tool effectively in a messaging context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, but this is acceptable given the lack of parameters, warranting a baseline score above minimum.
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 '获取' (get/retrieve) and the resource '有未读消息的会话' (sessions with unread messages), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_sessions' or 'filter_sessions', which likely return broader session lists.
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, exclusions, or comparisons to similar tools like 'get_sessions' or 'filter_sessions', leaving the agent to infer 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool sends messages but provides no information about permissions needed, rate limits, whether messages are saved to history, or what happens on failure. '发送文本消息' implies a write operation, but no safety or behavioral context is given.
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 stating the purpose followed by a clean parameter list. Every element serves a clear purpose with zero wasted words, 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?
For a message-sending tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after sending (success/failure indicators, message IDs), doesn't mention any limitations or requirements, and provides no context about the messaging platform or integration specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides essential parameter information: msg (message content), who (recipient, optional), at (@ target, optional), and exact (exact match, default false). This covers all 4 parameters and adds meaningful context about optionality and defaults that the schema alone doesn't provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发送文本消息' - send text message) and resource (text message), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like send_bulk_messages or send_image, but the core function 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 send_bulk_messages, send_image, or send_files. It simply lists parameters without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('切换到指定聊天窗口') but doesn't explain what 'switching' entails operationally—whether it changes UI state, loads messages, or requires specific conditions. No information is given about side effects, permissions, or error handling, leaving significant gaps for a tool that likely interacts with a chat interface.
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 and front-loaded: the first part states the tool's purpose, followed directly by parameter explanations. Every sentence earns its place with no wasted words, making it efficient for an AI agent to parse.
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 tool that likely changes chat state, with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after switching (e.g., success indicators, error conditions, or what 'chat window' means in context). For a tool with behavioral implications, more detail is needed to guide proper 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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'who' is a contact name and 'exact' controls exact matching with a default of false. This clarifies the purpose and usage of both parameters, compensating well for the schema's lack of descriptions. However, it doesn't detail format constraints (e.g., for 'who'), preventing a perfect score.
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: '切换到指定聊天窗口' (switch to a specified chat window). It uses a specific verb ('切换' - switch) and resource ('聊天窗口' - chat window), making the action clear. However, it doesn't explicitly distinguish this from the sibling tool 'switch_to_contact', which appears to serve a similar function, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'switch_to_contact' or explain any differences in context, prerequisites, or exclusions. The only usage hint is the parameter explanation, which doesn't address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't reveal any behavioral traits such as whether this requires specific permissions, if it's idempotent, what happens on failure, or if it triggers side effects. 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 that directly states the tool's 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 simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, it lacks context about when to use it, behavioral details, or integration with sibling tools, making it incomplete for effective agent use in a complex environment with many alternatives.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since the schema fully handles parameters, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('切换' meaning 'switch to') and the target resource ('微信到联系人页面' meaning 'WeChat to contact page'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'switch_chat' or other navigation-related tools, 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. It doesn't mention prerequisites (e.g., WeChat must be active), exclusions, or compare it to similar tools like 'switch_chat' or other navigation functions in the sibling list, leaving the agent with no contextual usage information.
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 parameters for window resizing and debug mode but fails to describe what the tool actually does behaviorally—e.g., whether it establishes a session, requires authentication, has side effects, or returns any output. This leaves critical operational details unclear.
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—two sentences that directly state the purpose and parameter meanings without any fluff. It is front-loaded with the core action, making it efficient and easy to parse.
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 initializing a connection (likely involving state changes or setup), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what happens after initialization, error conditions, or dependencies, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining that 'resize' controls automatic window adjustment and 'debug' enables debug mode, including their default values. This goes beyond the schema's type information, though it doesn't cover all potential behavioral implications of these parameters.
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 '初始化' (initialize) and the resource '微信连接' (WeChat connection), making the purpose evident. It doesn't explicitly distinguish from siblings like 'wechat_activate' or 'wechat_status', but the action is specific enough to understand its role in setting up a connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'wechat_activate' or 'wechat_check_activation'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage based on 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 the full burden of behavioral disclosure. It states what information is retrieved but doesn't describe how the tool behaves: e.g., whether it requires authentication, its read-only nature, potential rate limits, error conditions, or the format of returned data. This leaves significant gaps for a tool that likely interacts with a sensitive system like WeChat.
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 purpose without any fluff or redundant information. It's front-loaded with the core action and lists the three status components clearly, making it easy to parse.
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 interacting with WeChat (a messaging platform with potential authentication and state management), the description is incomplete. It lacks output details (no output schema), doesn't explain behavioral aspects like safety or dependencies, and doesn't guide usage relative to siblings. For a tool in this context, more information is needed to ensure proper agent 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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate here. A baseline of 4 is applied as per the rules for zero parameters, since no compensation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('获取' meaning 'get') and resource ('微信运行状态' meaning 'WeChat running status'), and lists the three components it retrieves: online status, account information, and activation status. It doesn't explicitly differentiate from sibling tools like 'wechat_check_activation' or 'get_my_info', but the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether WeChat must be initialized), exclusions, or comparisons to siblings like 'wechat_check_activation' (which might check activation only) or 'get_my_info' (which might retrieve different account details).
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 tool retrieves messages but doesn't specify whether this is a read-only operation, if it requires specific permissions, what the return format looks like (e.g., list structure, pagination), or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence in Chinese that directly states the tool's purpose without any wasted words. It is front-loaded and appropriately sized for a simple tool with no parameters, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It explains what the tool does but lacks details on behavioral aspects like return format or usage context. Without annotations or output schema, the description should ideally provide more context, but it minimally covers the basic purpose.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and since there are none, it meets the baseline of 4 for tools with zero parameters, as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and resource ('当前聊天窗口的所有消息' meaning 'all messages in the current chat window'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_history' or 'get_next_new_message', which likely retrieve different message sets.
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 chat window), exclusions, or comparisons to siblings such as 'get_history' (which might retrieve historical messages) or 'get_next_new_message' (which might fetch incremental updates).
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 ('get') but doesn't describe what information is returned (e.g., profile details, settings), whether it requires authentication, or any rate limits. 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, clear sentence in Chinese that directly states the tool's purpose without any fluff or unnecessary details. It's appropriately sized and front-loaded, making it highly efficient and easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimal but adequate for a simple read operation. However, it lacks details on what specific account information is retrieved (e.g., username, avatar, settings), which could be helpful for an agent to understand the output. It meets the minimum viable threshold but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion about inputs. A baseline of 4 is appropriate as it avoids misleading or redundant information.
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 my WeChat account information) clearly states the verb ('get') and resource ('my WeChat account information'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'get_friends' or 'get_chat_info', which might also retrieve user-related data, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing WeChat activated), exclusions, or comparisons to sibling tools like 'wechat_status' that might provide related status information, 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 the full burden of behavioral disclosure. It mentions a timeout parameter with a default of 10 seconds, which hints at a waiting behavior, but doesn't explain what happens during that wait (e.g., for delivery confirmation). It doesn't cover permissions, rate limits, or what a 'link card' entails (e.g., preview generation). The description is minimal and lacks critical behavioral details.
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 and front-loaded: it starts with the purpose ('发送链接卡片'), then lists all parameters with brief explanations. Every sentence earns its place by providing essential information without waste. The structure is clear and efficient.
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 complexity (a sending tool with 4 parameters), no annotations, and no output schema, the description is minimally complete. It covers the basic purpose and parameters but lacks details on behavior, output, or integration with sibling tools. It's adequate for a simple tool but has clear gaps in usage context and behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains each parameter in Chinese: url (required link address), friends (optional recipient(s) as single name or list), message (optional additional text), and timeout (optional wait time, default 10 seconds). This compensates well for the schema's lack of descriptions, though it doesn't specify formats (e.g., what constitutes a valid friend name).
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: '发送链接卡片' (send link card). It specifies the action (send) and resource (link card), which is specific enough to understand what it does. However, it doesn't explicitly differentiate from sibling tools like send_message or send_image, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists parameters but doesn't mention when this tool is appropriate compared to other sending tools (e.g., send_message for text, send_image for images). There's no context about 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 of behavioral disclosure. It states the tool activates something, implying a write/mutation operation, but doesn't describe what activation entails (e.g., whether it's reversible, if it requires specific permissions, or what happens on failure). The mention of using an environment variable as a fallback adds some context, but overall, key behavioral traits like side effects or error handling are missing.
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 and front-loaded: it states the purpose in the first part and parameter details in the second, with no wasted words. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and low schema coverage, the description is minimally adequate. It covers the purpose and parameter semantics but lacks details on usage context, behavioral traits, and expected outcomes. For an activation tool with potential side effects, more completeness would be beneficial, but it meets a basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the single parameter: it explains that 'license_key' is an activation key and specifies that leaving it empty uses the environment variable WECHAT_LICENSE_KEY. With 0% schema description coverage (the schema only defines the parameter type and default), this compensates well by clarifying the parameter's purpose and fallback behavior, though it doesn't detail format or validation rules.
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: '激活 wxautox4' (activate wxautox4). It specifies the verb ('激活' - activate) and the target resource ('wxautox4'), making the action explicit. However, it doesn't differentiate from sibling tools like 'wechat_check_activation' or 'wechat_initialize', which might have related but distinct purposes.
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 mentions a parameter for license key but doesn't explain prerequisites, such as whether initialization is required first, or when activation is needed relative to other tools like 'wechat_check_activation'. There's no explicit when-to-use or when-not-to-use 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 only states the purpose ('check activation status') without detailing what the check entails (e.g., returns boolean status, detailed info, requires authentication, has side effects, or rate limits). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, efficient sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized for a simple check operation and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks completeness. It doesn't explain what the check returns (e.g., activation state details) or how it integrates with sibling tools like 'wechat_activate'. For a status-check tool in a WeChat context, more context on output or usage would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required for checking status. Baseline is 4 for 0 parameters, as the description aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('检查' meaning 'check') and the resource ('wxautox4 激活状态' meaning 'wxautox4 activation status'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'wechat_status' or 'wechat_activate', which appear related to WeChat status/activation, leaving some ambiguity about 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. Given sibling tools like 'wechat_status' and 'wechat_activate', it's unclear if this checks a specific component (wxautox4) versus general status, or if it's a prerequisite for other operations. No explicit when/when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool lists available tools but doesn't disclose behavioral traits like whether it's read-only, requires authentication, has rate limits, or what format the output takes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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, clear sentence: '列出所有可用的微信自动化工具'. It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and no output schema, the description is adequate for a simple list operation. However, it lacks context about the output format (e.g., list structure, tool metadata) and doesn't address behavioral aspects like authentication needs. For a tool with no annotations, it should provide more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, as there are none to document. It appropriately focuses on the tool's purpose without unnecessary parameter details, meeting the baseline for zero-parameter tools.
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: '列出所有可用的微信自动化工具' (List all available WeChat automation tools). It uses a specific verb ('列出' - list) and resource ('微信自动化工具' - WeChat automation tools). However, it doesn't explicitly differentiate from sibling tools like 'get_friends' or 'get_sessions', which also list specific resources rather than all 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. It doesn't mention prerequisites, context, or exclusions. Given the sibling tools include various list/retrieval functions (e.g., 'get_friends', 'get_sessions'), the description fails to help an agent choose between them.
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:

[![wxauto-mcp MCP server](https://glama.ai/mcp/servers/cluic/wxauto-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cluic/wxauto-mcp)

Score Badge

Copy to your README.md:

[![wxauto-mcp MCP server](https://glama.ai/mcp/servers/cluic/wxauto-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cluic/wxauto-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/cluic/wxauto-mcp'

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