WeCom MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but send_message can also send text/markdown, overlapping with send_text_message and send_markdown_message. The generic tool is described as a universal interface, but the overlap could still cause selection confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern: send_text_message, send_markdown_message, lookup_user_id, list_users_by_department, check_config. The only slight deviation is send_message, but it is still a clear verb_noun form.
Tool Count5/5
8 tools is well-scoped for a WeCom messaging integration. Each tool covers a distinct function: sending different message types, mass send, user lookup, department listing, and configuration check, without unnecessary bloat.
Completeness4/5
Core messaging workflows are covered: text, markdown, file, generic types, mass send, and user retrieval. Minor gaps include lack of a dedicated media upload tool for images/news and no message status query, but these are not critical for a simple messaging server.
Average 3.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It clearly indicates the action (sending a message), but it does not disclose potential side effects, permission requirements, rate limits, or handling of missing recipient fields. For a mutation-like operation, this lack of context leaves significant behavioral ambiguity.
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 very concise: one sentence for purpose, followed by a compact Args list. Every line provides essential information without fluff. The use of a bullet-like format (though in plain text) is clean and easy to parse. It earns its place entirely.
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-message tool with an output schema, the description covers all parameters adequately. However, it lacks any contextual information about prerequisites (e.g., at least one recipient field must be set) or integration with authentication, and does not address sibling tool distinctions. The presence of an output schema reduces the need to explain return values, but the missing usage context makes it only minimally complete for an agent to confidently select it over alternatives.
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 description coverage is 0%, but the description fully compensates by explaining every parameter: to_user (userid, multiple via '|'), to_party (dept id), to_tag (tag id), content (text), agent_id (leave empty for default). It adds critical formatting details like the '|' separator and default behavior for agent_id, which the schema completely lacks. This is excellent parameter documentation.
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 purpose: '向企业微信成员发送文本消息' (send text messages to WeCom members). This provides a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like send_message or mass_send_message, relying on the word '文本' (text) to imply its scope. The tool name already conveys this, so slightly less credit for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the siblings (send_markdown_message, send_file_message, mass_send_message, etc.). The description only states what it does, not when it should be preferred. No exclusions or alternatives are mentioned, so it provides minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions the WeCom client limitation and gives content examples. It fails to explain expected output, error behavior, whether recipients are required, or any side effects, leaving the tool's behavior largely opaque beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences with a clear purpose and useful content examples. Every word earns its place, and the key information is front-loaded. There is no redundancy or padding.
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 has 5 parameters, no schema descriptions, and no annotations, the description is far too sparse. It covers only the content parameter and the client limitation, leaving recipient parameters and agent_id unexplained, making it incomplete for reliable invocation.
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 zero descriptions for all 5 parameters, so the description must compensate. It only explains the 'content' parameter with formatting examples, but completely omits the semantic meaning of to_user, to_tag, to_party, and agent_id, leaving the recipient selection and configuration fields unexplained.
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: sending a Markdown message. The verb '发送' (send) is paired with the resource 'Markdown消息' (Markdown message), and it includes a specific constraint that only the WeCom client supports it. This distinguishes it from siblings like send_text_message by format, even though alternatives aren't named.
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 using the tool—Markdown messages—and includes a notable usage constraint: only the WeCom client supports it. This implies when not to use it (on other clients) but does not explicitly compare with alternatives like send_text_message or mass_send_message. Thus it offers clear context plus an exclusion, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It does disclose a key behavioral trait (the @all scope limitation), but it omits other important details such as required permissions, possible rate limits, or error handling. The note adds value but is not comprehensive.
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 concise, using only two sentences. The main purpose is front-loaded, the scope caveat is clearly separated, and there is no filler or redundant text.
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 messaging tool, the description covers the primary purpose and an important scope caveat. However, it lacks parameter semantics and does not mention the output behavior (though an output schema exists). The note about the visible scope is valuable, but the overall completeness is moderate.
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 description coverage is 0%, and the description provides no information about the 'content', 'agent_id', or 'msg_type' parameters. It only mentions the sending behavior, leaving the agent without guidance on how to properly populate the 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 mass messages to all members within the app's visible scope (touser=@all). It uses a specific verb (send) and resource (mass message), and the scope limitation distinguishes it from sibling tools that target specific users or departments.
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 includes a clear note about the @all scope limitation and explicitly instructs that to reach the whole enterprise, the app's visible scope must be set to the root department. However, it does not explicitly mention when to use alternative tools like send_text_message for targeted sending.
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 auto-upload behavior and the file size/media_id validity constraints, adding some behavioral context. However, it omits error conditions, permissions, or side effects, leaving notable gaps.
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: the first states the purpose, the second states limitations. Every word earns its place, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential input semantics for the five parameters, making it incomplete for reliable use. The brief purpose and constraints are not enough for an agent to correctly populate recipient fields and file_path.
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 does not mention any parameters. It fails to explain what to_user, to_tag, to_party, agent_id, or even file_path mean, forcing the agent to rely solely on property names. This insufficient compensation for the low schema 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 sends a file to WeChat Work members and mentions automatic upload, distinguishing it from sibling text/markdown message tools. The verb+resource is specific and unambiguous.
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 clearly implies usage when sending files, with contextual constraints like the 20MB limit and media_id validity. It doesn't explicitly contrast with alternatives like send_text_message, but the purpose is distinct enough to provide clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does reveal that msg_type accepts specific values, provides example content_json structures for common types, and explains agent_id's default behavior. However, it does not disclose potential side effects (e.g., message delivery may fail silently), any authentication/permission requirements, rate limits, or what happens if no recipients are specified. The disclosed information is helpful but incomplete for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and relatively well-structured, starting with a one-line purpose then an Args section with parameter definitions and examples. It avoids unnecessary verbosity and front-loads the core purpose. However, the parameter documentation is somewhat dense and not uniformly formatted, slightly reducing 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?
Given the tool's complexity (6 parameters, no annotations, generic purpose), the description is incomplete. It fails to explain three of the six parameters (to_user, to_party, to_tag) which are crucial for directing a message. It also lacks guidance on whether at least one recipient is required and how multiple recipients are specified. The output schema reduces the need for return-value details, but the missing recipient semantics are a critical gap in context.
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 only provides titles and defaults for six parameters, with no descriptions. The tool description adds meaning for msg_type (list of allowed values), content_json (with examples for text, markdown, and textcard), and agent_id (purpose and default behavior). However, it completely omits semantics for to_user, to_party, and to_tag, which are essential recipient fields. Thus, it partially compensates for the schema's lack of descriptions but leaves significant gaps.
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 states '发送任意类型应用消息 (通用接口)' meaning 'Send any type of application message (generic interface)'. This uses a specific verb (send), a clear resource (application message), and explicitly labels itself as a generic interface, which differentiates it from sibling tools like send_text_message and send_markdown_message that handle specific message 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 description indicates this is a generic interface for any message type, which strongly implies it should be used when specialized send tools (e.g., send_text_message, send_markdown_message) are insufficient or when dealing with less common types like news or template_card. However, it does not explicitly state when not to use it or name alternatives, missing a fully explicit exclusion. The context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait (no network requests), which is useful context, but it does not mention whether the check is read-only, what 'ready' means, or what happens if the config is not ready. Lacks fuller transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence in Chinese that states the purpose and a key behavioral caveat. Every word earns its place; no fluff or 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 zero parameters and an output schema, the description is adequate. It covers the tool's core function and adds a behavioral note. It could briefly mention when to use it, but overall the tool is simple and well-described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter details, and the schema correctly defines an empty object, so no gaps exist.
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 checks current WeCom configuration readiness. The verb '检查' (check) and resource '当前 WeCom 配置' are specific, and it is clearly distinct from the sibling tools which all send messages or look up users.
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 does not explicitly state when to use this tool versus alternatives, but the phrase '不发起网络请求' (does not initiate network requests) implies it is a safe, local pre-flight check. No exclusions or alternative tool names are mentioned, so guidance remains implicit.
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 burden of behavioral disclosure. It reveals the output format ('仅返回姓名 + UserID') and parameter effects (department_id 0=root, fetch_child recursion). It does not mention permissions, side effects, or error behavior, but for a read-only listing tool this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for the main purpose and a two-line argument block. It is front-loaded with the essential purpose and avoids all fluff. Every element 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 listing tool with two parameters and an output schema, the description adequately covers the purpose, key parameter semantics, and expected return fields. It lacks details on pagination, ordering, or error conditions, but these are not critical given the tool's simplicity.
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 description provides meaningful explanations for both parameters beyond the schema: department_id semantics (0=root, all members) and fetch_child behavior (recursive sub-departments). The schema itself has zero descriptions, so this fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '列出部门成员' (list department members) and specifies output is limited to name + UserID. This is a specific verb and resource, but it doesn't explicitly differentiate from sibling tools (though none are similar listing tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the description and parameter explanations (e.g., department_id 0 means all members), but no explicit guidance on when to use this vs alternatives or exclusions is provided. Sibling tools like lookup_user_id suggest a potential alternative, but no comparison is made.
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 key behavioral traits: exact match first, fall back to fuzzy matching if no exact match, and returns all matching users with the same name. This goes beyond the basic 'lookup' verb. However, it does not mention error handling (e.g., no match found at all) or output format, though the output schema may cover that.
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. Every sentence provides value: the first states what it does, the second explains the matching behavior. No wasted words.
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 lookup tool with one parameter and an output schema, the description covers the essential context: purpose, matching rules, and multi-result behavior. It does not explicitly state what happens when no fuzzy match is found, but the output schema likely defines the return structure. This is a minor gap for an otherwise simple 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?
Schema coverage is 0%, so the description must compensate. The description explains the 'name' parameter as '成员姓名' (member name) and adds matching semantics: exact match, fuzzy fallback, and multi-result return. This adds significant meaning beyond the bare schema property definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '通过成员姓名查找 UserID' (find UserID by member name). This is a specific verb+resource combination. It also distinguishes from siblings by explaining it's for specifying the recipient when sending messages, which differentiates it from list_users_by_department.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: '用于发送消息时指定接收人' (used to specify recipient when sending messages). This informs the agent when to use this tool (before sending messages) but does not explicitly mention alternatives or exclusion conditions. Sibling tool names like send_text_message suggest this is a prerequisite step, but the guidance is implied rather than explicit.
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:

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

Score Badge

Copy to your README.md:

[![wecom-mcp-server MCP server](https://glama.ai/mcp/servers/atttx123/wecom-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/atttx123/wecom-mcp-server)

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/atttx123/wecom-mcp-server'

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