Allows sending and receiving WeChat messages, including QR login, listing accounts, sending text/media, receiving messages, and showing typing indicator.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wechat-mcp Wait for a new WeChat message, then send a reply saying 'Hi there'."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for sending and receiving WeChat (Weixin) messages, built on Tencent's iLink bot protocol.
This is a port of the messaging core of
Tencent/openclaw-weixin (an
OpenClaw channel plugin) into a standalone MCP server usable from Claude Code,
Claude Desktop, or any MCP client. The WeChat protocol logic — QR login, the
getUpdates long-poll receive loop, sendMessage, and the AES-128-ECB CDN
media pipeline — is preserved; the OpenClaw runtime/SDK coupling has been
removed and replaced with a thin MCP tool layer.
MCP tool | Purpose |
| QR-code login. Prints a QR to the terminal (STDERR); scan with WeChat mobile and confirm. Persists the bot token. |
| List logged-in WeChat bot accounts. |
| Remove an account's stored credentials, sync cursor, and context tokens. |
| Send text and/or a media attachment (image / video / file) to a user. Accepts a local path or a remote http(s) URL. Text is markdown-filtered by default (WeChat-unsupported syntax stripped); pass |
| Poll for new inbound messages (one long-poll cycle). Tracks a per-account sync cursor so repeated calls don't return duplicates. Inbound media is downloaded + decrypted to local temp files. |
| Continuously poll until a message arrives, an error occurs, or the window elapses (default 2 min). Re-polls back-to-back — the reliable way to wait for a message, since a single |
| Show (or cancel) the "typing…" indicator for a user. The typing ticket is resolved automatically. |
Related MCP server: WinAutoWx
Node.js >= 20
A WeChat (Weixin) mobile app to scan the login QR code
Clone and install. The prepare hook compiles TypeScript to dist/
automatically on npm install, so there is no separate build step.
git clone https://github.com/jimingyuan7/wechat-mcp.git wechat-mcp
cd wechat-mcp
npm installTo rebuild after editing source: npm run build.
Optional: voice-message transcoding (SILK → WAV) requires the optional
silk-wasm package. Without it, inbound voice is saved as raw .silk.
npm install silk-wasmRun the interactive login in a real terminal (the QR renders to STDERR):
npm run loginScan the QR code with the WeChat mobile app and confirm. Credentials are saved
under ~/.wechat-mcp/openclaw-weixin/accounts/.
You can also trigger login through the wechat_login MCP tool, but a real
terminal is friendlier for scanning the QR.
Prerequisites: the project is built (npm install already ran the prepare
build, so dist/mcp/server.js exists) and you have logged in once
(npm run login).
1. Add the server. Run this from anywhere — use the absolute path to the built entry point:
claude mcp add wechat -- node /absolute/path/to/wechat-mcp/dist/mcp/server.jsTip: if you're inside the project dir, $(pwd) fills the path in for you:
claude mcp add wechat -- node "$(pwd)/dist/mcp/server.js"By default the server is added at local scope (only this project on this machine). To make it available across all your projects, use user scope:
claude mcp add -s user wechat -- node /absolute/path/to/wechat-mcp/dist/mcp/server.jsTo override a config env var (e.g. a custom state dir), pass -e:
claude mcp add wechat \
-e WECHAT_MCP_STATE_DIR=/data/wechat \
-- node /absolute/path/to/wechat-mcp/dist/mcp/server.js2. Verify it's connected:
claude mcp list # should show: wechat ✓ connected
claude mcp get wechat # shows the full command + health3. Use it. Start claude, and the 7 wechat_* tools are available. Just
ask in natural language, e.g.:
"Use wechat_listen to wait for a WeChat message, then reply with a friendly greeting."
Remove when you no longer need it:
claude mcp remove wechatNote: first-time WeChat login (
npm run login) needs a real terminal to scan the QR code, so do that before relying on the tools inside Claude Code. Credentials persist under~/.wechat-mcp/, so you only log in once.
claude_desktop_config.json){
"mcpServers": {
"wechat": {
"command": "node",
"args": ["/absolute/path/to/wechat-mcp/dist/mcp/server.js"]
}
}
}Recipient ids look like xxxxxxxx@im.wechat. You normally obtain one
from an inbound message (wechat_receive → message From).
Context tokens: the WeChat backend issues a per-conversation
context_token on each inbound message that must be echoed on outbound sends.
The server caches these automatically (in memory + on disk) as messages
arrive, so wechat_send to a user who has recently messaged the bot "just
works". Sending to a user with no cached token may be rejected by the
backend.
Receiving is poll-based: call wechat_receive repeatedly (e.g. in a
loop). Each call holds the connection open up to timeoutMs (default 35s)
waiting for new messages, then returns. The sync cursor is persisted, so you
never see the same message twice across calls or restarts.
Media: outbound media is auto-classified by file extension
(video/*, image/*, else generic file). Inbound media is downloaded,
AES-128-ECB decrypted, and written to ~/.wechat-mcp/tmp/media/inbound/;
the local path comes back in the message's MediaPath.
In a chat with an MCP client (e.g. Claude Code / Claude Desktop) you just ask in natural language — "reply to the last WeChat message", "send this photo to the user", etc. The tool-call payloads below show what the client sends under the hood, and are also handy for direct/manual testing.
The recommended flow is receive first, then reply: an inbound message caches
the context_token that outbound sends require.
{ "name": "wechat_list_accounts", "arguments": {} }// → result
{ "count": 1, "accounts": [
{ "accountId": "bfa52ff0d915-im-bot",
"userId": "o9cq...@im.wechat", "configured": true }
] }wechat_listen re-polls until a message arrives or the window elapses:
{ "name": "wechat_listen", "arguments": { "windowMs": 120000 } }// → result (returns as soon as a message arrives)
{ "messages": [
{ "From": "o9cq...@im.wechat", "Body": "Hello",
"MediaPath": null, "context_token": "AARz..." }
], "pollCycles": 3, "timedOut": false }Copy From — that's the to you reply to. The context_token is now cached,
so the next send will actually deliver.
{ "name": "wechat_send", "arguments": {
"to": "o9cq...@im.wechat", "text": "Hi! Got it 👍" } }// → result
{ "messageId": "wechat-mcp:...", "hadContextToken": true, "markdownFiltered": false }
hadContextToken: truemeans it will be delivered. If it'sfalse, the recipient hasn't messaged the bot yet — have them send one message first.
{ "name": "wechat_typing", "arguments": { "to": "o9cq...@im.wechat" } }…do your slow work (call an LLM, fetch data), then wechat_send the result.
Cancel the indicator early with { "to": "...", "status": "cancel" }.
Local path (absolute recommended) or a remote URL — type is auto-detected:
{ "name": "wechat_send", "arguments": {
"to": "o9cq...@im.wechat", "text": "Here's the photo", "media": "/tmp/photo.png" } }{ "name": "wechat_send", "arguments": {
"to": "o9cq...@im.wechat", "media": "https://example.com/cat.jpg" } }Outbound text is markdown-filtered by default — WeChat-unsupported syntax
(H5/H6 headings, CJK italics *…*, inline images) is stripped so users see
clean text instead of stray symbols. Pass filterMarkdown: false to send raw:
{ "name": "wechat_send", "arguments": {
"to": "o9cq...@im.wechat", "text": "raw **markdown** stays", "filterMarkdown": false } }Note: WeChat chat bubbles do not render rich text at all — filtering only removes noisy markers; it cannot make text bold/italic on the WeChat side.
You can drive the server over stdio directly:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"cli","version":"0"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"wechat_list_accounts","arguments":{}}}' \
| node dist/mcp/server.jsVariable | Default | Description |
|
| Where credentials, sync cursors, and context tokens are stored. |
|
| Temp dir for downloaded / decrypted media. |
|
|
|
|
| UA-style self-identifier sent on every request (for backend log attribution). |
| Tencent C2C CDN | Override the media CDN base. |
| — | Optional |
src/
api/ iLink HTTP+JSON protocol (getUpdates, sendMessage, getUploadUrl, …) + types
auth/ QR login flow + per-account credential store
cdn/ AES-128-ECB encrypt/decrypt + CDN upload/download
media/ MIME mapping, media download/decrypt, optional SILK→WAV transcode
messaging/ send (text/image/video/file), inbound normalization + context tokens,
receive (single cycle + receiveUntil listen loop), outbound (high-level
send w/ markdown filter), typing (indicator), markdown-filter
storage/ state-dir resolution + sync-buf (getUpdates cursor) persistence
util/ logger (STDERR-only), redaction, id/account-id helpers
mcp/ MCP stdio server exposing the 5 toolsThe STDOUT stream is reserved exclusively for the MCP JSON-RPC protocol; all human-facing output (logs, QR codes, prompts) goes to STDERR.
Protocol implementation ported from
Tencent/openclaw-weixin (MIT).
List all WeChat (Weixin) bot accounts that have been logged in via QR code. Returns each account id, base URL, and whether it has a valid token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the selection criteria (QR code login) and return fields (id, base URL, token validity). It does not mention additional behavioral details like authentication or side effects, but none are expected for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no wasted words. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description fully covers what the tool does and what it returns, leaving no gaps for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no information. The description adds value by explaining the return structure beyond the schema, which is adequate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'WeChat bot accounts' and adds scope 'that have been logged in via QR code', clearly distinguishing it from sibling tools like wechat_listen or wechat_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving logged-in accounts, but does not explicitly state when to use or not use this tool versus alternatives. The context from sibling names provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continuously poll until at least one inbound message arrives, an error occurs, or the listen window elapses. Unlike wechat_receive (a single poll cycle that often returns empty immediately), this re-polls back-to-back across the whole window — the correct way to wait for a message. Returns as soon as a message is received, with pollCycles and timedOut for diagnostics. Media is downloaded + decrypted to local temp files by default. If multiple accounts are logged in, pass accountId.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | Account id to listen on; required only when multiple accounts are logged in. | |
| windowMs | No | Total time to keep listening, in ms (default 120000 = 2 min). | |
| cycleTimeoutMs | No | Per-cycle long-poll timeout, in ms (default 30000). | |
| downloadMedia | No | Download + decrypt inbound media to temp files (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains polling loop, early return, diagnostic fields, and media handling, but lacks mention of potential errors or rate limits beyond 'error occurs'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear contrasts and explanations, but slightly verbose with repeated detail about polling behavior that could be condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, description fully compensates by explaining return diagnostics, media handling, and behavior differences, ensuring complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters; description adds context for accountId (conditional), windowMs default, cycleTimeoutMs default, and downloadMedia default, though some defaults are already in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'poll' with resource 'inbound messages', explicitly distinguishes from sibling wechat_receive by contrasting single-poll vs continuous polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Directly states when to use (waiting for messages) and when not (single poll via wechat_receive), plus conditional guidance for accountId with multiple accounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an interactive WeChat login. A QR code is printed to the server's STDERR/terminal; scan it with the WeChat mobile app and confirm. Blocks until login completes or times out. For first-time setup it is usually easier to run npm run login in a real terminal. Returns the connected account id on success.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutMs | No | Max time to wait for the QR scan (default 480000 = 8 min). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses blocking behavior, QR code output to STDERR, need for mobile app scanning, and return of account id on success. It lacks details on failure modes or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences covering purpose, behavior, and an alternative approach. No unnecessary words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive login tool, the description covers the process, blocking, and return value. It lacks output schema but states the return. Could mention error handling or cancellation, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description for timeoutMs. The description adds context by mentioning the default timeout (8 minutes) and the blocking nature, which complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool logs in to WeChat via QR code, specifying the verb (login) and resource (WeChat). It distinguishes from sibling tools like wechat_list_accounts, wechat_logout, etc., by describing the interactive login process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance that for first-time setup, running 'npm run login' in a real terminal is easier, indicating when not to use this tool. However, it does not explicitly list alternative tool uses or when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a logged-in WeChat account: deletes its stored credentials, sync buffer, and cached context tokens. Provide the accountId from wechat_list_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | Account id to remove (see wechat_list_accounts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully bears the burden. It discloses that the tool deletes stored credentials, sync buffer, and cached context tokens, giving clear insight into the destructive actions. It could mention irreversibility, but current detail is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The purpose and parameter source are front-loaded, making it quick to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema or annotations, the description covers the action, consequences, and parameter source. Minor omission: no mention of return value or confirmation, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal new meaning beyond 'Account id to remove (see wechat_list_accounts).' It reinforces the source of the ID but does not deepen parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and identifies the resource as 'logged-in WeChat account'. It clearly distinguishes the action from sibling tools like wechat_login (login) and wechat_list_accounts (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Provide the accountId from wechat_list_accounts', indicating a prerequisite for using this tool. However, it does not explicitly mention when not to use it or suggest alternatives, though the context of sibling tools implies distinct use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll for new inbound WeChat messages (one long-poll cycle). Returns messages received since the last poll; the server tracks a per-account sync cursor so repeated calls do not return duplicates. Media (images/voice/files/video) is downloaded and decrypted to local temp files by default, with the path returned in MediaPath. If multiple accounts are logged in, pass accountId.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | Account id to poll; required only when multiple accounts are logged in. | |
| timeoutMs | No | Long-poll timeout in ms (default 35000). The server holds the request open up to this long waiting for new messages. | |
| downloadMedia | No | Download + decrypt inbound media to temp files (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: long-poll mechanism, deduplication via sync cursor, default media download/decrypt to temp files, and the accountId condition. No contradictions with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core action, each sentence adds distinct value: purpose, behavior details, and account condition. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers key behavioral aspects, the absence of an output schema means the description should elaborate on response structure beyond MediaPath. It mentions the sync cursor and dedup but omits other return fields like message content, sender, etc., leaving some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context beyond schema: ties accountId to multi-account scenario, explains timeoutMs as long-poll holding time, and clarifies downloadMedia default. However, the schema descriptions are already informative, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Poll for new inbound WeChat messages (one long-poll cycle)', which clearly states the verb (poll) and resource (inbound WeChat messages). It differs from siblings like wechat_send and wechat_listen, establishing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it's a long-poll, deduplicates via sync cursor, and requires accountId only with multiple accounts. However, it does not explicitly state when not to use this tool or contrast with wechat_listen, missing explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a WeChat message to a user. Provide to (the recipient WeChat id, e.g. 'xxxx@im.wechat'), and text and/or media. media may be a local file path (absolute recommended) or a remote http(s) URL — images, videos, and other files are auto-detected by extension. If multiple accounts are logged in, pass accountId. The per-recipient context token (cached from inbound messages) is attached automatically when available. Outbound text is markdown-filtered by default (WeChat-unsupported syntax such as H5/H6 headings, CJK italics, and inline images is stripped; code blocks, tables, and bold are kept).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient WeChat id, e.g. 'xxxx@im.wechat'. | |
| text | No | Message text. Optional when sending media only. | |
| media | No | Local file path or remote http(s) URL for an image/video/file attachment. | |
| accountId | No | Sending account id; required only when multiple accounts are logged in. | |
| filterMarkdown | No | Strip WeChat-unsupported markdown from text (default true). Set false to send raw text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: media auto-detection, automatic context token attachment, markdown filtering, and optional accountId. It does not cover error cases or rate limits but is detailed for a read-write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 5 sentences, front-loaded with purpose, and each sentence adds meaningful detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for usage instructions, but lacks explanation of return values or success/failure indicators. Given no output schema, this is a gap, but it's acceptable for a simple send operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond schema, explaining media types, auto-detection, context token, and markdown filtering, making it easier for an agent to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'WeChat message', and the detailed explanation of parameters distinguishes it from sibling tools like wechat_receive or wechat_list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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; the description simply states its function without indicating when not to use it or mentioning other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show (or cancel) the '正在输入…' typing indicator to a WeChat user. Useful before a slow reply so the user sees the bot is working. The required typing ticket is resolved automatically. If multiple accounts are logged in, pass accountId.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient WeChat id, e.g. 'xxxx@im.wechat'. | |
| status | No | 'typing' to show the indicator (default), 'cancel' to clear it. | |
| accountId | No | Sending account id; required only when multiple accounts are logged in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions automatic ticket resolution but omits potential side effects like rate limits or session requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences that front-load the action and provide key usage context without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 params fully described in schema, the description covers usage context and a practical tip. No output schema is needed for a side-effect tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining accountId's conditional necessity and default status value, exceeding mere schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Send a WeChat typing indicator' and description 'Show (or cancel) the '正在输入…' typing indicator' clearly specify the action and resource. It is distinct from sibling tools like wechat_send and wechat_listen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use ('before a slow reply') and hints at accountId condition. However, it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0wechat_list_accountswechat_listenwechat_loginwechat_logoutwechat_receivewechat_sendwechat_typingScored across 7 tools
Each tool has a clearly distinct purpose: listing accounts, listening for messages, logging in/out, receiving, sending, and typing. There is no functional overlap.
All tools follow a consistent 'wechat_verb_noun' pattern (e.g., wechat_list_accounts, wechat_send), making the naming predictable and easy to understand.
With 7 tools, the set is well-scoped for a WeChat integration, covering core operations without being excessive or insufficient.
The tool set covers essential operations (login, logout, send, receive, typing) but lacks tools for managing contacts, groups, or deleting messages, which are common use cases.
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
A very simple remote MCP server that greets you, with a custom icon.
MCP server for AI dialogue using various LLM models via AceDataCloud
The official MCP Server for the Mux API
