wechatbot-mcp

by zhyyyq

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct operations, but send_image and send_file overlap in that both can send local images, differing only in caption handling and auto-detection; send_url vs send_file could also confuse when dealing with remote files. Overall, descriptions clarify most boundaries.
Naming Consistency4/5
All tools share a consistent wechat_ prefix and snake_case. However, not all follow verb_noun: login/logout/status are bare verbs/nouns, and pending_messages/known_users are adjective-noun phrases, slightly deviating from a strict verb-object pattern though still predictable.
Tool Count5/5
11 tools is well within the 3-15 ideal range. Each tool addresses a distinct need: auth, connection status, sending text/media/URLs/typing indicators, receiving messages, and contact listing. No unnecessary redundancy.
Completeness4/5
Covers the core lifecycle of a WeChat bot: login/logout, send various content types, receive messages, and list contacts. Minor gaps include lacking user detail lookups, message history search, and group management, but these are not essential for basic bot operation.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one meaningful behavioral trait: the SDK downloads the remote URL content and re-uploads it to WeChat CDN, implying the URL must be accessible and the operation is not a simple link pass-through. However, with no annotations, it does not disclose failure modes, auth requirements, media constraints, or side effects beyond the basic upload.
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, purposeful sentences with no filler. The first sentence states the action and resource, the second explains the underlying mechanism, 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?
For a network-resource-sending tool with no annotations and no output schema, this description is too minimal. It lacks return behavior, usage context relative to siblings, URL constraints, and parameter semantics, leaving significant ambiguity for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It only indirectly explains 'url'; the required 'userId' and optional 'caption' are completely undescribed, leaving the agent to infer their meaning from names alone.
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 media from a remote URL') and adds a useful mechanism detail (SDK downloads and uploads to WeChat CDN). It implies distinction from sibling send_* tools by focusing on remote URLs, but it does not explicitly contrast with wechat_send_image or wechat_send_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives like wechat_send_image or wechat_send_file. The remote URL focus is implied, but there are no explicit context cues, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only lists output fields, implying a read-only status check, but does not explicitly state that it is non-destructive, whether authentication is required, or what side effects might exist. This is a significant gap for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a compact list format with no filler words. Every word contributes meaning, and the front-loaded structure immediately communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide a fuller picture of what the tool returns. It lists three fields but gives no details about their format, possible values, or structure. 'Receive-queue depth' in particular is ambiguous without elaboration. The description is too sparse for a tool that lacks any other structured 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 the schema provides no parameter information. The description does not need to explain parameters, and the baseline for 0 params is 4. It appropriately focuses on the output rather than inputs.
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 lists three concrete data items (connection state, account info, receive-queue depth) that clearly differentiate this from sibling tools like wechat_login or wechat_send_text. However, it lacks an explicit verb or sentence structure, making it slightly less direct than an ideal 'Get current status' phrasing.
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 does not mention use cases such as checking connection before sending messages or monitoring queue depth. The user must infer usage solely from the tool name and the listed output fields.
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 only the core action and does not explain side effects, idempotency, error behavior, or any security or state requirements, making the tool's behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately sized for the tool's simplicity and every word contributes to understanding the action.
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?
The tool is simple, with one parameter and no output schema or annotations, so the description is adequately functional but lacks essential context about the inverse relationship with wechat_send_typing and any expected state prerequisites. It is missing enough to be fully actionable in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (userId) and zero description coverage. The description references 'the given user', which implicitly maps to userId, but adds no detail on format, origin, or meaning beyond the schema. This provides minimal semantic value without full compensation for the coverage gap.
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 ('Cancel') and resource ('typing indicator') with a target ('the given user'), clearly distinguishing it from sibling tools like wechat_send_typing. It precisely states what action the tool performs.
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 simply states the action without mentioning the relationship to wechat_send_typing or any prerequisites, 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?
No annotations are provided, so the description carries the full burden. It only states that the message is plain text and the recipient must be known, but it does not disclose side effects, failure modes, whether the send is synchronous, or what happens if the user is unknown. This lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and constraint without any wasted words. It is efficient and easy to parse.
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?
The tool is simple with well-documented parameters, but the description lacks behavioral context such as error handling, return values, and any side effects. The known-user constraint provides some context, but overall the description is minimally complete for a send operation.
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 comprehensive descriptions for both parameters (UTF-8 encoding, paragraph splitting, ID format). The tool description adds no additional parameter meaning, and with 100% schema coverage the baseline of 3 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 clearly states the tool sends a plain text message to a specific userId, distinguishing it from sibling tools like wechat_send_image, wechat_send_file, and wechat_send_url. The constraint "must be a known user" adds specificity to the target.
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 this tool is for sending text messages, but it does not explicitly mention alternatives or when not to use it. The precondition of a known user is mentioned, but no guidance is given on how to verify or handle unknown users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: the caption is sent as a separate text message before the image. However, it does not mention other relevant behaviors such as error handling, whether the operation requires login, or what the return value/response indicates, leaving gaps for an agent.
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 main purpose, and contains no filler or redundant information. It earns its place by adding the useful caption-ordering detail without extra wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send tool with 3 parameters, no output schema, and no annotations, the description gives the essential behavior and a notable quirk, but it lacks information about error conditions, response format, or any prerequisites beyond the parameter list. It is minimally viable but not fully complete.
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 only 33% (only imagePath is described). The description adds meaning for caption (sent separately) and reinforces that imagePath is a local file, but it does not address userId at all, and it does not fully compensate for the low coverage of the other parameters. More explicit parameter explanations are needed.
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 specific verb 'Send' with the resource 'a local image file', clearly distinguishing it from sibling tools like wechat_send_text and wechat_send_file. The added note about caption being sent separately further clarifies the tool's unique behavior.
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 by stating the tool sends a local image file, but it does not explicitly contrast with wechat_send_text or wechat_send_file, nor does it state when this should be preferred. The usage context is only implied through the type of file, not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses one behavioral trait: auto-detection of file type. However, it omits any side effects, prerequisites (e.g., login status), or error handling, leaving room for improvement.
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?
A single, front-loaded sentence that is concise and free of filler. It directly states the action and an important nuance (auto-detection).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send operation with three parameters and no output schema, the description is minimally adequate. It lacks information about return values, errors, or prerequisites, though the sibling tools (e.g., login/status) provide some surrounding context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level details. The parameter names (userId, caption, filePath) are self-explanatory, but the description fails to clarify expected formats, constraints, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an arbitrary local file, with auto-detection of file type. This distinguishes it from siblings like wechat_send_image and wechat_send_text by emphasizing 'arbitrary' and the full range of file types.
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 phrase 'arbitrary local file' implies a general-purpose sending tool, contrasting with specialized siblings like send_image. It provides clear context for when to use it, though it does not explicitly mention alternatives or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the action is one-shot ('once') and not auto-stopping, which are key behavioral traits. However, it does not mention error handling or effects of repeated calls, though this is minor for a simple typing indicator.
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 concise sentences, front-loaded with the action, and every word serves a purpose. It includes the action, the one-shot nature, and the pairing instruction without any redundancy.
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 (one required parameter, no output schema, and no annotations), the description covers the core behavior, the one-shot limitation, and the required pairing with stop_typing. It lacks details about return values or error conditions, but for a tool of this scale, the provided context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter (userId), and the description does not mention it at all. While the parameter name is somewhat intuitive, the description adds no semantic value or clarification about whose ID it is or any constraints.
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: showing a typing indicator ('正在输入中…') once. It is distinguishable from sibling tools like wechat_send_text and wechat_stop_typing, and the pairing note further clarifies its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the typing indicator does not auto-stop and instructs pairing with wechat_stop_typing. This provides clear when-to-use guidance and names the complementary alternative, going beyond simple context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the destructive 'pop' behavior and auto-download side effects (media saved to ~/.wechatbot/pending-media/ and referenced by localPath). This goes beyond the schema, though it doesn't mention prerequisites like login or empty-buffer 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 two sentences, front-loaded with the core action, and includes essential media-handling details. Every word adds value with no redundancy or fluff.
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?
The tool is simple (one parameter), but lacks an output schema and annotations. The description provides some return context (localPath for media), but does not explain the full message object structure, error cases, or whether authentication via wechat_login is required. This creates gaps for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter `limit` with default/min/max but no description. The description adds meaning by clarifying that it returns 'up to `limit`' messages, which directly explains the parameter's role. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Pop and return up to `limit` received WeChat messages that have been buffered since the last call.' This specific verb-resource pairing distinguishes it from sibling tools like send/login/status. Mentioning media auto-download further clarifies the scope.
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 a polling usage pattern by stating 'since the last call' and makes it obvious this is the retrieval tool among the siblings. However, it does not explicitly name alternatives or provide when-not-to-use conditions, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (listing users with context tokens) and the dynamic nature ('currently have'). The verb 'List' implies a read-only operation, and the parenthetical exposes the practical significance, which is sufficient for this simple list 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 sentence that conveys the action, scope, and purpose without any fluff. The parenthetical adds value in a compact way. It 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple no-parameter, no-output-schema tool. The description fully covers what the tool returns and why it matters. No further context (e.g., pagination, permissions) seems necessary given the trivial complexity.
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 (schema is empty), so the baseline is 4. The description adds no parameter details, but none are needed. The output is implicitly described as user IDs, which aligns with the tool's purpose.
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 'List' with a clear resource ('user IDs we currently have a context_token for') and adds a clarifying parenthetical ('i.e., who can be messaged back'). This distinguishes it from sibling tools like wechat_pending_messages and wechat_send_text, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is useful: identifying users who can receive messages. While it does not explicitly name alternatives or exclusions, the 'who can be messaged back' clarification implies its role in messaging workflows, giving the agent enough to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses a key side effect: deleting credentials with clearCredentials=true and the consequent fresh QR requirement. This goes beyond a simple 'logout' statement, though it doesn't detail all state changes (e.g., message receiving stops).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main action is front-loaded ('Stop the bot.'), followed by the conditional side effect. 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 one-parameter logout tool, the description covers the core behavior and the parameter effect. It doesn't elaborate on post-logout state or return values, but given the low complexity and absence of an output schema, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains the single parameter clearCredentials: 'With clearCredentials=true, also deletes ~/.wechatbot/credentials'. It adds concrete meaning and behavior beyond the schema's bare boolean.
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 action: 'Stop the bot.' It uses a specific verb and resource, and the optional clearCredentials behavior adds precision. It is easily distinguished from sibling tools like wechat_login or wechat_send_text.
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 conveys clear usage context: to stop the bot, and explains the credential-clearing option. However, it does not explicitly mention when not to use it or name alternatives, so it falls 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the behavior: silent return on existing session, QR code flow with PNG auto-open and ASCII copy saved to a path, and success return value (account id). This goes well beyond a minimal description.
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 three sentences, front-loaded with the purpose, then conditional behavior. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, no output schema), the description covers the main flow, side effects, and return value. It's complete for a login tool.
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 coverage is 100% for the 'force' parameter, so baseline is 3. The description adds context by explaining the default session behavior, which indirectly clarifies when 'force' would be needed.
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 opens with 'Log into WeChat,' providing a specific verb and resource. It clearly distinguishes from sibling tools by describing the login flow (session check, QR code) rather than sending messages or logging out.
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 gives clear context on when to call: to establish a session, and notes that it returns silently if already logged in, suggesting it may be a no-op in that case. It doesn't explicitly name alternatives, but the sibling toolset makes the use case obvious.
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:

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

Score Badge

Copy to your README.md:

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

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