wecom-crm-mcp

Server Quality Checklist

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

Latest release: v0.1.0
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.
Average 2.4/5 across 13 of 13 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 16, 2026
- 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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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-crm-mcp MCP server](https://glama.ai/mcp/servers/andyleimc-source/wecom-crm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/andyleimc-source/wecom-crm-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/andyleimc-source/wecom-crm-mcp'

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