wechat-mcp

by Xwangtie

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct action or resource: sending text/file, retrieving contacts/rooms/messages, searching history, and fetching status/self information. Even the seemingly similar contacts list and contact info tools are clearly differentiated by scope (list/search vs detailed profile).
Naming Consistency3/5
All tools share the 'wechat_' prefix, and most follow a verb_noun pattern (wechat_send_text, wechat_get_contacts). However, several tools like wechat_status, wechat_contact_info, wechat_self_info, and wechat_setup_guide lack a leading verb, creating a mixed but still readable convention.
Tool Count5/5
With 10 tools, the server is well-scoped for a WeChat bot, covering messaging, contacts, rooms, message history, and account info without unnecessary expansion. This falls comfortably within the ideal range for a domain-specific MCP server.
Completeness4/5
The tool set covers the core WeChat operations: sending text and files, listing contacts and rooms, retrieving recent messages, searching history, and accessing self/contact details. Minor gaps exist, such as no explicit tool for group member management or real-time event subscription, but these are not essential for typical bot workflows.
Average 3.8/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states what is returned ('nickname, remark, ID, etc.'), but omits any mention of auth requirements, rate limits, potential latency, or that it is a read-only operation. It also does not note whether a setup is required (e.g., via wechat_setup_guide), which is a significant gap given sibling tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, direct sentences, front-loaded with the core action and followed by return information. There is no fluff or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list/search tool with one optional parameter, the description is fairly complete. It explicitly mentions the return fields, which is important because there is no output schema. It lacks some guidance on alternatives or behavioral caveats, but given the low complexity and full schema coverage, it is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the sole 'query' parameter, describing it as an optional keyword filter by nickname or remark. The tool description merely reinforces this ('search by keyword') and adds no extra semantics or usage details. Thus, the description adds no additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieve all contacts or search by keyword, returning nickname, remark, and ID. It uses a specific verb ('get') and resource ('contacts'), and the plural 'contacts' distinguishes it from sibling tools like wechat_get_rooms or wechat_get_messages. However, it does not explicitly differentiate from wechat_contact_info, which may provide similar contact details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two usage modes: get all contacts or search by keyword, implying the optional query parameter. It does not explicitly mention when to use this tool versus alternatives like wechat_contact_info, nor does it state any exclusions or prerequisites. The guidance is purely implicit from the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description doesn't explicitly state that this is a read-only operation or describe side effects (e.g., whether it marks messages as read). It only mentions the default limit of 50, leaving behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with no output schema, the description gives only a high-level view of the return value ('list of messages') without specifying message structure or other relevant behavior, making it partially incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'limit' parameter with its default (50), and the description repeats that same information without adding new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a list of recently received messages' with a specific verb and resource, distinguishing it from sibling tools like wechat_send_text and wechat_search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage but doesn't explicitly provide when-to-use vs alternatives. It doesn't mention that wechat_search_messages should be used for searching, so guidance is lacking.
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 claims support for searching by sender, but the schema only exposes 'keyword' and 'limit', with no sender parameter, creating ambiguity about how to perform a sender search. The description also omits details like whether the search covers all conversations, pagination behavior, or read-only nature. This is a significant transparency gap for a search tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the core action ('search historical messages by keyword'). While it is brief, it is not verbose or redundant. However, its brevity may contribute to the lack of behavioral details, so it barely misses a 5 for perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of context, but it leaves out critical information about return values, error handling, and operational scope (e.g., whether the search is global or per-conversation). The parameter count is small and the schema is clear, so the tool is not overly complex, but the description is too sparse to be considered complete for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both keyword and limit having Chinese descriptions. The description adds marginal value by mentioning searchable dimensions (text content, sender), but does not clarify how to specify the sender in the keyword parameter. Since the schema already defines the parameters clearly, the description contributes little beyond the baseline, though it does hint at keyword semantics that are not fully explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching historical message records by keyword. It distinguishes this from sibling tools like wechat_get_messages by explicitly focusing on keyword-based search, and further specifies it can search by text content and sender. This is an unambiguous 'search' verb with resource and scope, fully clarifying purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you need to search historical messages by keyword, rather than simply retrieving messages. It establishes a clear context for use, though it does not explicitly name alternative tools or mention when not to use it. The presence of wechat_get_messages as a sibling provides implicit contrast, but the description could be stronger with explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the types of information returned (nickname, remark, region, signature) and implies a read-only operation via '获取', but it does not mention error behavior, prerequisites, or response structure beyond example fields. No contradictions with annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and lists sample fields, with no redundant words. It is appropriately minimal and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single well-documented parameter and no output schema, the description adequately explains the tool's purpose and expected return fields. However, it could clarify that contactId comes from wechat_get_contacts, but this is a minor gap in an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description for the single parameter (contactId: '联系人的 ID'), achieving 100% schema description coverage. The tool description adds no further parameter details, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (get) and clearly identifies the resource as a specified contact's detailed information, listing example fields (nickname, remark, region, signature). It distinguishes from sibling tools like wechat_get_contacts by focusing on a single contact's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single contact's details when a contactId is available, but it does not explicitly state when to use it over sibling tools or mention obtaining the contactId from wechat_get_contacts. No exclusions or alternatives are given, so usage guidance remains 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the need for an absolute local file path, but does not disclose potential failure modes, size limits, whether the operation blocks, or any authentication requirements. This is minimal disclosure for a mutation-style 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 concise sentence (24 characters in Chinese) that front-loads the core action and the key prerequisite. Every word earns its place, with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required parameters, no output schema, no nested objects), the description adequately covers the essential information: what it does and what is needed. It may lack deeper behavioral context, but for this level of complexity it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('contact' and 'filePath'), giving 100% coverage. The description adds the context that the file can be an image and reinforces the absolute-path requirement, but does not materially increase understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: sending files or images to contacts or group chats. It uses a specific verb ('send') and specifies the resource (contacts/group chats), definitively distinguishing it from sibling tool 'wechat_send_text' which handles text messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool is for file/image sending, implying that text messages should go through 'wechat_send_text'. However, it does not explicitly state when not to use this tool or name the alternative, falling short of a 5.
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?
There are no annotations, so the description carries the full burden for disclosing behavioral traits. It only mentions the flexibility of the contact parameter (ID/nickname/group name) but does not note any side effects, prerequisites, rate limits, or irreversibility of sending a message. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes the key parameter clarification. There is no redundant fluff or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter send tool, the description provides sufficient information for an agent to invoke it correctly, including how to specify the recipient. However, with no output schema and no annotations, it would benefit from a note on return values or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions. The description's note about contact being an ID/nickname/group name largely duplicates the schema's '接收方 ID / 昵称 / 群名称'. Thus, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '向联系人或群聊发送文本消息' (sends a text message to a contact or group chat), which specifies the verb and resource. It distinguishes from sibling tools like wechat_send_file by explicitly limiting to text messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sending text messages to a contact or group, and it does not exclude any scenarios. However, it does not explicitly name alternatives (e.g., wechat_send_file for files) or state when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of conveying behavior. The verb '获取' indicates a read-like operation, but the description does not disclose potential side effects, authentication requirements, rate limits, or return format. It adds minimal behavioral depth beyond the action itself, which is acceptable for a simple getter but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose. It is front-loaded with the verb and resource, contains no redundant information, and is appropriately sized for a tool with no parameters.
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?
With no output schema and no annotations, the description is the only source of information about the return value. It simply says '个人信息' (personal information), which is vague and does not specify what fields (e.g., nickname, avatar, ID) will be returned. Given the low complexity (0 params), this is adequate but leaves room for richer 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 zero parameters, and the schema coverage is 100% (trivially). The description adds semantic value by clarifying scope ('当前登录' - currently logged in), which explains why no parameters are needed. Baseline for 0 params is 4, and the description satisfies this without needing to explain parameter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' - get) and the specific resource ('当前登录微信账号的个人信息' - personal information of the currently logged-in WeChat account). This distinguishes it from siblings like wechat_contact_info (which retrieves other contacts' info) and wechat_status (which retrieves status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to fetch the current user's own profile information, which provides some context. However, it does not explicitly mention when to use it over alternatives, nor does it state any exclusions or prerequisites. Usage guidance is purely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the tool returns all rooms with name and member count, which is useful, but it does not mention potential side effects, authentication needs, or failure modes. The read-only behavior is implied by 'get', but not explicitly stated, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action and outcome in a compact manner. It contains no redundant information and is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple (no parameters, no output schema), and the description covers the essential semantics: it lists all group chats with their names and member counts. However, it does not mention whether additional fields such as group IDs are returned, nor any prerequisites like setup, leaving minor gaps for fully complete 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 zero parameters, so there is nothing to explain beyond the schema. The 100% schema coverage is trivial, and the description adds no parameter-specific meaning. According to the baseline for parameterless tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '获取' (get) with a clear resource '所有群聊列表' (all group chat list), and explicitly states the returned fields (group name and member count). It clearly distinguishes this from sibling tools like wechat_get_contacts, which focuses on contacts rather than rooms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives or when not to use it. The intended usage is only implied by the tool's name and the phrase '所有' (all), so the agent must infer the context without explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates a read-only information retrieval operation ('获取') and specifies the content returned, but does not explicitly state that no state changes occur or describe the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that concisely lists the tool's offerings without any waste. It is easily scannable and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool, the description adequately enumerates the three main outputs (setup guide, dependency status, troubleshooting). It does not detail the response structure, but the simple nature and lack of an output schema make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing for the description to explain about parameters, and the empty schema requires no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Wechaty environment setup guide, dependency status, and troubleshooting suggestions. This specifically distinguishes it from sibling tools focused on sending messages or retrieving contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and tool name: use when you need setup guidance or troubleshooting. However, there is no explicit when-to-use/when-not-to-use guidance or comparison to alternatives like wechat_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It indicates a read-only operation via '获取', but it does not disclose whether it can be called before Wechaty initialization, or describe error conditions or side effects. It adds the three categories of returned info but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, front-loading the purpose with no filler words. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool, the description lists the three key information types (login status, bot running info, Wechaty init status). However, without an output schema, it could specify the response structure more explicitly. It is reasonably complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics and correctly focuses on what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb '获取' (get/retrieve) with specific resources: WeChat login status, bot running information, and Wechaty initialization status. This clearly distinguishes it from sibling tools like wechat_send_text or wechat_get_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should be used when needing status information, but provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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