Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@WeCom Mail MCP send an email to hr@company.com about meeting reminder"
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.
一个基于 Python 的 MCP 服务端，通过企业微信官方邮件 API 发送普通邮件。
它做的事情很简单：
对 AI 暴露 send_email
通过企业微信官方接口发送邮件
从环境变量或 .env 读取 CORPID / CORPSECRET
兼容 uv run 和 uvx --from ...
官方 WeCom 邮件 API 发信，不走 SMTP
自动获取并缓存 access_token
兼容 text / html，也兼容 text/plain / text/html
提供 get_mailbox_info，方便确认当前发件邮箱
支持 stdio、sse、streamable-http 三种传输方式
Related MCP server: Email MCP Server
在企业微信侧确认下面几件事：
有可用的 CORPID
有对应应用的 CORPSECRET
应用具备“邮件”权限
应用邮箱账号已经配置好
调用邮件接口所用的应用 secret 已经在“可调用应用”范围内
官方文档：
获取 access_token: https://developer.work.weixin.qq.com/document/path/91039
发送普通邮件: https://developer.work.weixin.qq.com/document/path/97445
查询应用邮箱账号: https://developer.work.weixin.qq.com/document/path/97991
.env服务端会自动加载项目根目录下的 .env。
优先级是：命令行覆盖 > .env > 系统环境变量。
也就是说，.env 里写了就以 .env 为准；.env 没写或留空时，再回退到系统环境变量。
必填：
WECOM_CORP_ID
WECOM_CORP_SECRET
兼容别名：
CORPID
CORPSECRET
可选：
WECOM_API_BASE，默认 https://qyapi.weixin.qq.com
WECOM_REQUEST_TIMEOUT，默认 20
WECOM_MCP_TRANSPORT，默认 stdio
WECOM_MCP_HOST，默认 127.0.0.1
WECOM_MCP_PORT，默认 8000
WECOM_LOG_LEVEL，默认 INFO
uv sync.env项目里已经提供了 .env.example 和一个本地 .env 模板。
PowerShell 以外，最省事的方式就是直接编辑根目录 .env：
CORPID=你的企业ID
CORPSECRET=你的应用Secret如果你不想用 .env，也可以继续用系统环境变量。
PowerShell:
$env:CORPID="你的企业ID"
$env:CORPSECRET="你的应用Secret"uv run wecom-mail-mcp --check-config成功时会输出当前应用邮箱账号和别名邮箱列表。
uv run wecom-mail-mcpuvx 可以吗可以。对于 Python 项目，uvx 的角色基本就类似 Node 生态里的 npx。
本项目已经提供了 console script，所以本地目录可以直接这样跑：
uvx --from . wecom-mail-mcp如果以后你把它发到 PyPI，上线后就可以直接：
uvx wecom-mail-mcp{
"mcpServers": {
"wecom-mail": {
"command": "uvx",
"args": [
"--from",
"d:/Code_Save/Py/发邮件的mcp",
"wecom-mail-mcp"
],
"env": {
"CORPID": "你的企业ID",
"CORPSECRET": "你的应用Secret"
}
}
}
}如果你更喜欢 uv run，也可以：
{
"mcpServers": {
"wecom-mail": {
"command": "uv",
"args": [
"run",
"--directory",
"d:/Code_Save/Py/发邮件的mcp",
"wecom-mail-mcp"
],
"env": {
"CORPID": "你的企业ID",
"CORPSECRET": "你的应用Secret"
}
}
}
}send_email参数：
to_email：收件人邮箱
subject：邮件主题
content：邮件正文
content_type：可选，支持 text、html、text/plain、text/html，默认 text
说明：
发件人不是由 AI 传入的，而是企业微信“应用邮箱账号”
服务端会把 text/plain 映射为官方接口的 text
服务端会把 text/html 映射为官方接口的 html
如果发送 HTML，请显式传 content_type="html"
MCP 工具描述会直接告知客户端 HTML 邮件兼容限制，避免把网页模板直接当邮件模板发送
如果要发 HTML 邮件，按最保守的邮件写法来：
优先使用 table、tbody、tr、td 做布局
文本和基础内容只用 p、br、span、strong、b、em、i、h1 到 h4、a、img
样式尽量写成 inline style，不要依赖复杂选择器
图片使用公网 https 绝对地址
尽量避免：
script、iframe、form、video、audio、canvas、svg
外链 CSS、Web Font
flex、grid、position
相对路径、本地路径、网页式复杂模板
推荐骨架：
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td>
<h2 style="margin:0 0 16px;">标题</h2>
<p style="margin:0 0 12px;">正文</p>
<a href="https://example.com">链接</a>
<img
src="https://example.com/demo.png"
alt=""
style="display:block;width:100%;height:auto;border:0;"
>
</td>
</tr>
</table>get_mailbox_info返回当前应用邮箱账号与别名邮箱列表，便于确认发件人身份。
如果你要用 HTTP 传输：
uv run wecom-mail-mcp --transport streamable-http --host 127.0.0.1 --port 8000python -m unittest discover -s tests查询当前应用邮箱账号与别名邮箱，用于确认实际发件人地址。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| provider | No | |
| alias_list | No | |
| sender_email | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what is queried (current app mailbox and aliases), and the verb '查询' implies a read-only operation, but it does not explicitly state safety, permissions, or side effects. This is adequate but not rich 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the resource and purpose without any wasted words. It is appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple zero-parameter query and an output schema exists, the description need not explain return values. It covers what is retrieved and a primary use case, which is sufficient for an agent to invoke it correctly, though a note on read-only safety would make it fully complete given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to describe. The baseline for zero parameters is 4, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (查询/query) and resource (当前应用邮箱账号与别名邮箱/current app mailbox account and alias mailboxes), clearly identifying the tool's function. It does not explicitly name or distinguish itself from the sibling send_email tool, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '用于确认实际发件人地址' (used to confirm the actual sender address) provides a clear use case context. It does not offer when-not-to-use guidance or name alternatives, but it gives the agent enough to know when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过企业微信官方邮件 API 发送普通邮件。发件人固定为当前应用邮箱账号。如果发送 HTML 邮件，请显式传 content_type=html，并只使用邮件兼容写法：优先用 table/tbody/tr/td 做布局，样式尽量写 inline style。稳定标签：table、tbody、tr、td、p、br、span、strong、b、em、i、h1-h4、a、img。避免 script、iframe、form、video、audio、canvas、svg、外链 CSS、flex、grid、position、web font、相对路径和网页式复杂模板。图片请使用公网 https 绝对地址。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 邮件正文。如果发送 HTML 邮件，请显式传 content_type=html，并只使用邮件兼容写法：优先用 table/tbody/tr/td 做布局，样式尽量写 inline style。稳定标签：table、tbody、tr、td、p、br、span、strong、b、em、i、h1-h4、a、img。避免 script、iframe、form、video、audio、canvas、svg、外链 CSS、flex、grid、position、web font、相对路径和网页式复杂模板。图片请使用公网 https 绝对地址。HTML 骨架建议：<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0"><tr><td><h2 style="margin:0 0 16px;">标题</h2><p style="margin:0 0 12px;">正文</p><a href="https://example.com">链接</a><img src="https://example.com/demo.png" alt="" style="display:block;width:100%;height:auto;border:0;"></td></tr></table> | |
| subject | Yes | 邮件主题 | |
| to_email | Yes | 收件人邮箱地址，例如 user@example.com | |
| content_type | No | 正文类型。支持 text、html、text/plain、text/html。默认 text。如果正文是 HTML，请显式传 html 或 text/html，并遵守邮件兼容 HTML 限制。 | text |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| message | No | |
| subject | Yes | |
| provider | No | |
| to_email | Yes | |
| content_type | Yes | |
| sender_email | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the fixed sender identity and the HTML rendering restrictions (tags that survive vs. those stripped), which is genuine behavioral context. However, for a tool that fires irreversible outbound email, it says nothing about required permissions, rate limits, or delivery failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and sender constraint are correctly front-loaded, but roughly 80% of the text is an HTML compatibility list that is repeated word-for-word in the schema's content field. The repetition bloats the definition without adding new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and all four parameters are fully documented, so the agent has what it needs to construct a call. The main gap is behavioral rather than structural: nothing covers failure modes, throttling, or whether the send is authenticated as the app identity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the HTML guidance in the description is duplicated almost verbatim in the content parameter's own description, so the prose adds no meaning beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('通过企业微信官方邮件 API 发送普通邮件') and adds a real scoping fact: the sender is fixed to the current app mailbox account. It does not explicitly differentiate from the only sibling, get_mailbox_info, but that sibling is a read tool on a different resource, so confusion risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use/when-not-to-use or alternative routing, though as the sole send tool the implied usage is clear. The conditional guidance it does give is parameter-level (pass content_type=html for HTML bodies), not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_mailbox_infosend_emailScored across 2 tools
The two tools have clearly distinct purposes: one sends email, the other retrieves mailbox information. There is no overlap or ambiguity that could lead to misselection.
Both names use a verb_noun pattern (send_email, get_mailbox_info), which is consistent and predictable. Minor deviation in specificity but acceptable.
With only 2 tools, the set feels thin for an email MCP server. Common operations like listing, reading, or managing emails are absent, making the count borderline inadequate.
The server only supports sending email and checking mailbox info. Critical lifecycle operations such as reading, replying, forwarding, or managing folders are missing, significantly limiting its usefulness for email workflows.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email for AI agents: send mail, manage contacts, automations & webhooks. Zero-DNS first send.
Email for agents: domains, aliases, IMAP mailboxes, DNS, sending and webhooks via one API key.
Send transactional email over a verified domain — templates, attachments, custom headers.
