How do I use wecom-crm-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wecom-crm-mcp list all external contacts" 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.

wecom-crm-mcp

by andyleimc-source

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

wecom-crm-mcp

WeCom (企业微信) 客户联系 / External Contact MCP Server — a Python SDK + Model Context Protocol server that covers the full customer-contact API surface so an LLM can manage customers, tags, group chats, moments, and mass-send messages on your behalf.

PyPI Python License

Why this exists

GitHub has plenty of WeCom group-bot webhook MCP servers. None covered the real 私域运营 / CRM surface exposed by 企业微信's 「客户联系」 API: customers, tags, group chats, 朋友圈, 群发, transfer-on-handover, acquisition links. This does — 11 modules, 63 actions, 1:1 with the official docs.

Related MCP server: reasonix-feishu-mcp

Coverage

#	Module	MCP tool	Key actions
1	客户管理	`wecom_customer`	`list_followers`, `list`, `get`, `batch_get`, `remark`
2	客户标签	`wecom_tag`	`list_corp_tags`, `add_corp_tag`, `edit_corp_tag`, `del_corp_tag`, `mark_tag`
3	在职继承	`wecom_transfer_active`	`transfer_customer`, `transfer_result`, `group_chat_transfer`
4	离职继承	`wecom_transfer_resigned`	`get_unassigned_list`, `resigned_transfer_customer`, `resigned_transfer_result`, `groupchat_transfer`
5	客户群	`wecom_group_chat`	`list`, `get`, `opengid_to_chatid`
6	联系我 / 加入群聊	`wecom_contact_way`	`add`, `get`, `list`, `update`, `del`, `close_temp_chat`, `groupchat_*_join_way`
7	客户朋友圈	`wecom_moment`	`add_moment_task`, `get_moment_task_result`, `cancel_moment_task`, `get_moment_list`, `get_moment_task`, `get_moment_customer_list`
8	获客助手	`wecom_acquisition`	`create_link`, `list_links`, `get_link`, `update_link`, `delete_link`, `list_customers`, `get_quota`, `get_statistic`
9	消息推送 / 群发	`wecom_msg_template`	`add_msg_template`, `send_welcome_msg`, `get_groupmsg_list_v2`, `get_groupmsg_task`, `get_groupmsg_send_result`
10	统计管理	`wecom_statistics`	`get_user_behavior_data`, `groupchat_statistic`, `groupchat_statistic_group_by_day`
11	附加功能	`wecom_misc`	`product_album_`, `_intercept_rule`, `get_new_external_userid`

Plus two helpers: wecom_upload_media (temporary media for attachments) and wecom_describe_action (list the actions each tool supports, so the LLM can self-introspect).

Install

pip install wecom-crm-mcp

Setup — 企业微信 Side

This is the part that trips most people up. Do it before you put credentials into the MCP config; otherwise you'll get errcode=60020 "not allow to access from your ip" on every call.

1. Find your 客户联系 secret

Log into work.weixin.qq.com as an admin
客户联系 → 客户 → page bottom: API section
Click 配置 next to "API 接口" → you'll see Secret. Click 查看 and copy it. This is your WECOM_CORPSECRET.
In the same page, find your 企业ID (CorpID) from 我的企业 → bottom of the page. This is your WECOM_CORPID.

2. Add your server IP to the 可信 IP list

WeCom enforces IP whitelisting on the 客户联系 API. Every IP that calls the API must be whitelisted, including your laptop if you run the MCP locally.

The whitelist lives in the same 客户联系 → API page where you got the secret (not in the generic "应用管理 → 企业可信IP" — that one asks for a filed domain and is for self-built apps, not 客户联系).

Find your current public IP with:

curl https://ipinfo.io/ip

Paste it in, separated by ; if multiple.

Running from a laptop on home Wi‑Fi / VPN means your IP will change. Either (a) pin a stable exit via a cloud VM and run the MCP there, or (b) re-add the IP every time it changes. See deploy/README.md for the cloud-VM pattern.

3. Give the secret access to the employees whose customers it should manage

Still on 客户联系 → API → 可调用接口的应用 → add the employees/departments whose customer list you want the API to see. The secret can only read customers serviced by these people.

Setup — Client Side

Claude Desktop / Claude Code

Add to ~/.claude.json (or ~/Library/Application Support/Claude/claude_desktop_config.json for Claude Desktop):

{
  "mcpServers": {
    "wecom-crm": {
      "command": "wecom-crm-mcp",
      "env": {
        "WECOM_CORPID": "ww...",
        "WECOM_CORPSECRET": "...",
        "WECOM_AGENTID": "1000001"
      }
    }
  }
}

WECOM_AGENTID is only required for mass-send (wecom_msg_template); everything else works without it.

Restart the client and you should see a wecom-crm server with 13 tools.

Plain Python

import asyncio
from wecom_crm_mcp import WecomClient, WecomConfig
from wecom_crm_mcp.modules.customer import CustomerModule

async def main():
    cfg = WecomConfig.from_env()  # reads WECOM_CORPID / WECOM_CORPSECRET
    async with WecomClient(cfg) as c:
        customers = await CustomerModule(c).list_followers()
        print(customers)

asyncio.run(main())

Example LLM sessions

User: 列出所有带"VIP"标签的客户
Claude → wecom_tag (list_corp_tags)
       → wecom_customer (batch_get)
       → returns list

User: 帮我给所有客户发朋友圈，文案"春节快乐"，附张 /tmp/banner.jpg
Claude → wecom_upload_media (attachment_type=2)
       → wecom_moment (add_moment_task, with media_id from above)
       → returns jobid

User: 我们销售小王离职了，把他的所有客户转给小李
Claude → wecom_transfer_resigned (get_unassigned_list)
       → wecom_transfer_resigned (resigned_transfer_customer)

Error codes you'll actually hit

errcode	Meaning	Fix
`60011`	no permission on this customer	The customer isn't served by any user listed in 可调用接口的应用
`60020`	IP not allowed	Add your current IP to the 可信 IP list
`42001` / `40014`	token expired / invalid	Handled automatically — the client refreshes and retries once
`40003`	invalid external_userid	You passed an app-scoped openid, not an external_userid — convert with `wecom_misc action=get_new_external_userid`

Architecture

┌──────────────────┐           stdio            ┌──────────────────────┐
│  Claude / LLM    │ ─────── MCP ─────────────▶ │  wecom-crm-mcp       │
└──────────────────┘                             │  (FastMCP server)    │
                                                 │                      │
                                                 │  ┌────────────────┐  │
                                                 │  │ 11 Tool routers│──┼─▶ action → SDK method
                                                 │  └────────────────┘  │
                                                 │  ┌────────────────┐  │
                                                 │  │  WecomClient   │──┼─▶ httpx.AsyncClient
                                                 │  │  • token cache │  │  + diskcache
                                                 │  │  • retry 42001 │  │
                                                 │  └────────────────┘  │
                                                 └──────────┬───────────┘
                                                            │ HTTPS
                                                            ▼
                                              qyapi.weixin.qq.com

Development

git clone https://github.com/andyleimc-source/wecom-crm-mcp.git
cd wecom-crm-mcp
uv venv && source .venv/bin/activate
uv pip install -e ".[dev]"
uv run pytest -q

All tests mock HTTP with pytest-httpx — no network, no credentials needed.

Contributing

Issues and PRs welcome. If you add an endpoint, the pattern is:

Add the method to the relevant src/wecom_crm_mcp/modules/*.py
Add one test in tests/modules/test_*.py asserting the JSON body or query params
If it's a new user-facing action, add it to the action table in src/wecom_crm_mcp/server.py

License

MIT — see LICENSE.

Disclaimer

This is an independent community project. Not affiliated with Tencent or 企业微信. Use at your own risk and stay within the 企业微信 API rate limits and policies.

Available Tools

13 tools

wecom_acquisitionD

获客助手 — actions: create_link / list_links / get_link / update_link / delete_link / list_customers / get_quota / get_statistic.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.5/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No behavioral traits (e.g., destructiveness, read-only, side effects) are disclosed. The description only lists actions without indicating consequences or requirements. Annotations are absent, so the description carries full burden but fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, but this is under-specification rather than efficient communication. It lacks necessary structure and depth.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the description does not explain return values, action purposes, or parameter usage. For a multi-action tool, this is severely incomplete.

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 description lists valid values for the 'action' parameter, which adds some guidance beyond the schema. However, it does not explain the 'params' object or the semantics of each action, leaving parameter meaning unclear. Schema coverage is 0%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the tool as '获客助手' (Acquisition Assistant) and lists available actions, but does not clarify what acquisition means in this context or how it differs from sibling tools like wecom_contact_way or wecom_customer. The purpose is vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any conditions for use. The description lacks any usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_contact_wayC

联系我 / 加入群聊 — actions: add / get / list / update / del / close_temp_chat / groupchat_*_join_way.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions destructive actions like 'del' and 'close_temp_chat' but does not explain side effects, permissions, or reversibility. The description fails to provide adequate 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise but lacks structure and completeness. It is a single line that lists actions without explanation, making it under-specified rather than effectively concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple actions) and minimal schema, the description is severely incomplete. It does not explain return values, action-specific details, or how to construct the 'params' object. The agent cannot reliably use this tool based solely on the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% schema description coverage. The description lists possible actions but does not explain what the 'params' object should contain for each action. The agent has no semantic information about the parameters beyond their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists possible actions like add, get, list, update, del, close_temp_chat, and groupchat_*_join_way, which implies the tool manages contact ways and group chat join ways. However, it lacks a clear, concise statement of the tool's overall purpose and does not distinguish it from sibling tools like wecom_group_chat.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or scenarios where another sibling tool would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_customerC

客户管理 — actions: list_followers / list / get / batch_get / remark.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only lists actions without disclosing behavioral traits such as side effects, permissions, rate limits, or mutability. For a tool with multiple actions, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is very short but lacks structure. It front-loads the actions list but omits important sections. Could be more precise while remaining concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0% schema description coverage, the description should compensate but does not. It does not explain output schema or behavioral context for the actions. Incomplete for effective tool selection.

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%. Description does not explain the 'action' parameter values or 'params' object beyond listing actions. The schema provides no defaults or enums, leaving the agent without parameter guidance.

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?

Description states tool is for customer management and lists specific actions (list_followers, list, get, batch_get, remark). This makes the purpose moderately clear, though it lacks detail and doesn't fully distinguish from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not explain which action to use in which scenario or compare with sibling tools like wecom_tag or wecom_group_chat.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_describe_actionA

Return the action list for a wecom_* tool, or all tools when no tool specified.

ParametersJSON Schema

Name	Required	Description	Default
`tool`	Yes
`action`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It accurately indicates a read operation returning an action list, but doesn't disclose any side effects, authentication needs, or behavioral constraints beyond its stated purpose.

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, clear sentence that immediately conveys the tool's function. It is front-loaded and efficient, though it could be slightly more structured for enhanced readability.

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 (2 params, 1 required) and the existence of an output schema, the description adequately covers the basic functionality. It could mention that the returned action list contains names of available actions, but this is not critical.

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 description explains the 'tool' parameter (specify a wecom_* tool or omit for all) but does not clarify the 'action' parameter (optional string/null) and its effect. With 0% schema description coverage, the description should cover both parameters adequately.

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: return action lists for wecom_* tools, with a specific condition (all tools when unspecified). This distinguishes it from sibling tools that perform actions rather than describe them.

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 use via the 'tool' parameter to get actions for a specific tool or omit to get all. It lacks explicit when-not-to-use or alternatives, but the context with siblings makes it clear this is a meta-information tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_group_chatD

客户群 — actions: list / get / opengid_to_chatid.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations and a minimal description, no behavioral traits are disclosed. The agent cannot infer side effects, permissions needed, or whether actions are destructive. The description adds no value beyond the action list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short but at the expense of utility. It front-loads the purpose vaguely but omits all critical details, making it insufficiently informative despite its brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even with an output schema, the description fails to explain outputs or how actions differ. Sibling tools cover related WeCom functions, but this description gives no context for when to use group chat actions compared to others like wecom_msg_template or wecom_tag.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description only lists action names without parameter details. The 'params' field is vaguely defined as any object or null, and no enums or constraints are hinted, leaving the agent unable to format valid inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '客户群 — actions: list / get / opengid_to_chatid' identifies the tool as related to WeCom group chats and lists three actions, giving a basic sense of purpose. However, it does not explain what each action does, making it vague and unable to distinguish from siblings like wecom_customer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus other WeCom tools. There is no mention of prerequisites, context, or exclusions, leaving the agent without direction for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_miscC

附加功能 — product_album_*, *_intercept_rule, get_new_external_userid.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden of disclosing behavioral traits. It does not mention side effects, permissions, or whether the tool is read-only or destructive. Only the action parameter hints at behavior, but no specifics are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short but lacks clarity. It is not concise in a helpful way; instead, it is cryptic and under-specified. Every sentence should add value, but this one only lists a few function families without explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity as a miscellaneous function holder and the presence of many specific sibling tools, the description is severely incomplete. It does not explain how to use the tool, the expected inputs/outputs (despite having an output schema), or how it relates to other tools.

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 input schema has 2 parameters with 0% description coverage. The description lists some action names ('product_album_*', '*_intercept_rule', 'get_new_external_userid') but does not explain the 'action' parameter's possible values or the 'params' structure. The agent cannot infer how to use the parameters from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists some function prefixes and a specific function name but does not explain the overall purpose of the tool. '附加功能' (additional functions) provides a vague sense that it covers miscellaneous operations, but it's unclear what the tool does as a whole. Siblings like wecom_customer and wecom_tag are specific, but this one is a catch-all without definition.

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 its siblings. The description does not mention prerequisites, context, or alternatives. The agent has no information to decide between wecom_misc and other tools for a given task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_momentC

客户朋友圈 — actions: add_moment_task / get_moment_task_result / cancel_moment_task / get_moment_list / get_moment_task / get_moment_customer_list.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose behavioral traits such as side effects, permission requirements, or rate limits. For example, 'cancel_moment_task' is likely destructive, but this is not mentioned. No annotations exist to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loaded with the resource name, making it concise. However, it could be better structured: itemizing actions clearly or grouping them would improve readability.

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?

Despite having an output schema and a list of actions, the description is incomplete for a multi-action tool. It fails to explain what each action does, what parameters are expected, or how to construct the 'params' object, leaving the agent guessing.

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 0% description coverage, leaving 'action' and 'params' undocumented. The description partially compensates by listing allowed action values, but it does not describe the structure of 'params' for each action, which is critical given the generic 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 names the resource ('客户朋友圈' / Customer Moments) and lists six specific actions, clearly indicating the tool's purpose for managing moments. However, it lacks a strong verb (e.g., 'Manage') and relies on the action list to convey purpose.

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 siblings like wecom_customer or wecom_group_chat. The description merely lists actions without context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_msg_templateD

消息推送 / 群发 — actions: add_msg_template / send_welcome_msg / get_groupmsg_list_v2 / get_groupmsg_task / get_groupmsg_send_result.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.3/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, and the description does not disclose behavioral traits such as side effects, required permissions, rate limits, or what operations are read-only vs. destructive. The description only lists action names without any 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very brief, but it is not appropriately structured. It presents a fragmented list of actions without explanation, making it under-specified rather than concise. A single sentence that is unclear does not earn high marks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple actions via a dispatcher pattern) and the presence of an output schema (though not shown), the description fails to explain what each action returns or any other relevant context. It is completely inadequate for an agent to understand the tool's overall functionality.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters (action and params) with no descriptions. Schema description coverage is 0%. The tool's description adds no meaning beyond the schema; it does not explain valid action values or the structure of params. This fails to help the agent construct correct invocations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with '消息推送 / 群发' (message push/broadcast), hinting at a general purpose, but immediately lists actions (add_msg_template, send_welcome_msg, etc.) without clarifying that the tool is a dispatcher for multiple operations. It lacks a clear verb+resource statement distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the many sibling tools (e.g., wecom_customer, wecom_group_chat). There is no indication of prerequisites, alternatives, or context-specific applicability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_statisticsC

统计管理 — actions: get_user_behavior_data / groupchat_statistic / groupchat_statistic_group_by_day.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It only lists sub-actions without explaining side effects, authentication needs, or whether operations are read-only. Lacks essential 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one line), but structure is poor—just a list of action names. It is under-specified, sacrificing clarity for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, return values need no explanation, but the description fails to detail the sub-actions' expected inputs and outputs. The tool dispatches multiple actions; the description is incomplete for effective usage.

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 coverage is 0%, and the description adds no meaning to the 'action' and 'params' parameters beyond listing action values. It does not describe expected input formats or the structure of 'params' objects, leaving the agent underinformed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description indicates this tool manages statistics, listing three sub-actions, but lacks a clear verb and resource. It's adequate but vague, not specifying what kind of statistics or for what context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus sibling tools like wecom_customer or wecom_group_chat. The description does not provide context for selecting this tool over alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_tagC

客户标签 — actions: list_corp_tags / add_corp_tag / edit_corp_tag / del_corp_tag / mark_tag.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior. It only lists action names without explaining effects (e.g., creation, deletion, editing) or side effects. No mention of authentication, rate limits, or data safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one short line). However, it lacks proper structure and fails to front-load a clear purpose statement. The list format is compact but not well-organized for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool supports multiple sub-actions, the description is incomplete. It does not specify what each action does, what parameters are expected, or what the output contains (though an output schema exists). An agent would need additional information to use this tool effectively.

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, so the description must compensate. It enumerates possible action values (list_corp_tags, etc.) but does not explain the 'action' parameter's usage or the 'params' object's structure. 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.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description lists possible actions (list_corp_tags, add_corp_tag, etc.) and states '客户标签' (customer tags), implying the tool covers management of customer tags. However, it does not explicitly state the overall purpose with a clear verb+resource structure, making it somewhat ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like wecom_customer or wecom_group_chat. No context on prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_transfer_activeC

在职继承 — actions: transfer_customer / transfer_result / group_chat_transfer.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description does not disclose behavioral traits such as authentication requirements, rate limits, or effects of transfers. For a tool with zero annotations, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but under-specified. It front-loads the main purpose but could earn its place by adding more structure and detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, 0% schema coverage, and minimal description, the tool definition is severely incomplete. An agent lacks information on how to set parameters for each action and what to expect from the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds no information about parameters. The action parameter is required but its possible values are not listed, and the params parameter is unexplained. The description fails to compensate for the schema's lack of detail.

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 is for 'active inheritance' and lists three actions: transfer_customer, transfer_result, group_chat_transfer. This gives a specific verb and resource, distinguishing it from the sibling wecom_transfer_resigned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like wecom_transfer_resigned, nor when to use each specific action. The description only lists actions without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_transfer_resignedD

离职继承 — actions: get_unassigned_list / resigned_transfer_customer / resigned_transfer_result / groupchat_transfer.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes
`params`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

D1.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior, but it only lists action names without explaining side effects, permissions, or any behavioral traits, offering minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short, but it is not concise in a helpful way; it omits essential information and lacks a clear structure, making it under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple actions, optional params, output schema exists), the description is severely incomplete, failing to explain return values, action behavior, or parameter details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not explain the 'params' object or how to use it with each action, leaving parameter semantics completely undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description includes the Chinese phrase '离职继承' and lists actions, giving a hint about resigned employee transfer, but does not explicitly state the tool's overall purpose in natural language.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings, nor any context for choosing among the listed actions, leaving the agent without usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

wecom_upload_mediaA

Upload a local file as WeCom temporary media.

    If ``attachment_type`` (1=mass-send, 2=moment) is given, uses
    ``/cgi-bin/media/upload_attachment``; otherwise uses the plain
    ``/cgi-bin/media/upload`` endpoint.

ParametersJSON Schema

Name	Required	Default
`file_path`	Yes
`media_type`	No	image
`attachment_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the endpoint selection logic but does not mention authentication requirements, file size limits, side effects, or the format of the return value. The existence of an output schema partially mitigates the lack of return value details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using just four lines to convey purpose and conditional behavior. Every sentence adds value, and the main action is front-loaded.

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 3-parameter tool with no annotations, the description covers the main action and endpoint logic but lacks details on media_type options, file_path requirements, and what the output contains. The output schema may supplement return value info, but parameter guidance is 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?

Schema description coverage is 0%, so the description must compensate. It clarifies that attachment_type uses '1=mass-send, 2=moment' and triggers a different endpoint. However, it does not explain media_type values or file_path format, leaving those parameters partially undocumented.

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 'Upload a local file as WeCom temporary media,' which directly specifies the verb, resource, and purpose. It also distinguishes itself from sibling tools by focusing on uploading media, a separate function from other WeCom operations like customer or tag management.

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 when to use the tool (when uploading temporary media) and explains the conditional behavior based on attachment_type. However, it does not explicitly state when not to use it or compare it to alternatives, leaving some ambiguity for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv0.1.0Jul 5, 2026
- First observedwecom_acquisition
- First observedwecom_contact_way
- First observedwecom_customer
- First observedwecom_describe_action
- First observedwecom_group_chat
- First observedwecom_misc
- First observedwecom_moment
- First observedwecom_msg_template
- First observedwecom_statistics
- First observedwecom_tag
- First observedwecom_transfer_active
- First observedwecom_transfer_resigned
- First observedwecom_upload_media

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0

Scored 2026-07-05 05:50 across 13 tools

Disambiguation5/5

Each tool has a distinct prefix (e.g., wecom_acquisition, wecom_contact_way, wecom_customer) that clearly separates CRM functions. Actions within each tool are specific and non-overlapping, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tools follow a consistent 'wecom_<domain>' pattern in snake_case, and actions use standard verbs like add, get, list, update, del. The naming is uniform and predictable across the entire set.

Tool Count5/5

With 13 tools covering acquisition, contact ways, customer management, group chat, moments, messaging, statistics, tags, transfers, media upload, and a description tool, the count is well-scoped for a comprehensive CRM server without being excessive.

Completeness4/5

The toolset covers major CRM workflows (CRUD for contacts, tags, acquisition links, messaging, etc.) and includes advanced features like transfer and statistics. Minor gaps exist, such as lacking explicit customer creation/deletion outside acquisition, but overall it provides a complete operational surface for WeCom CRM.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Relm CRM A
com.relmcrm
API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
CRM AI & Machine Learning
412
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
sendbird A
io.usefulapi
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
Communication Customer Support
142

Related MCP Servers

wx4py-mcp
Communication Autonomous Agents App Automation
zhentong520
F
license
Not graded
quality
D
maintenance
MCP server for WeChat PC automation, enabling message sending, voice/video calls, and AI-powered listening through Cursor or WorkBuddy.
Updated 3 months ago (2026-06-12 15:19 UTC)
2
-
reasonix-feishu-mcp
Communication Workplace & Productivity
Monc618
A
license
Not graded
quality
C
maintenance
MCP server for Feishu/Lark API integration, enabling AI agents to send messages, manage groups, create and edit documents and spreadsheets, and search knowledge bases.
Updated 3 months ago (2026-06-19 14:47 UTC)
MIT
mcp-watermelon
Customer Support Communication
CDiT-dev
A
license
Not graded
quality
C
maintenance
MCP server for Watermelon.ai that exposes all 13 public API endpoints as tools, enabling AI assistants to manage contacts, conversations, messages, custom fields, and webhooks.
Updated a month ago (2026-08-03 09:01 UTC)
MIT
wxauto-mcp-sse
Communication App Automation
bjdr69
F
license
Not graded
quality
D
maintenance
MCP server for WeChat automation, supporting message sending, chat history retrieval, and contact list management via SSE protocol.
Updated a year ago (2025-07-15 10:25 UTC)
5
-

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/andyleimc-source/wecom-crm-mcp'

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