用途
MultiMail 的 MCP 服务器为 AI 智能体提供电子邮件能力。正如其官方描述所言：智能体目前没有邮箱，是因为还没有人敢信任它使用邮箱。MultiMail 通过为智能体分配真实邮箱地址、引入信任阶梯机制、为每封邮件附加加密身份，以及按收件人控制发送权限来解决这一问题。
主要能力
监督模式（Oversight Mode） 每个邮箱都有一个监督模式，可从只读开始，随着智能体获得信任逐步升级。智能体可通过 API 请求升级，操作者用一次性验证码批准；降级无需批准，智能体也可随时自我限制。门控审批流程在 Lean 4 中经过形式化验证，确保任何代码路径下邮件都必须通过操作者批准才能投递。
按收件人白名单 在 gated_send 模式下，白名单收件人可绕过审批队列。支持精确地址（如 vendor@example.com）或域名通配符（如 *@example.com）。每次添加都需要操作者邮件批准，智能体无法自行批准白名单变更。这是实用折中方案：与已知联系人的常规通信立即发送，新收件人仍需监督。
加密身份 每封外发邮件都带有签名的 X-MultiMail-Identity 头（ECDSA P-256），载荷包含操作者名称、监督模式、能力与验证状态。收件人可通过 GET /.well-known/multimail-signing-key 的公钥进行验证。另有 X-MultiMail-Reputation 头链接到隐私保护的信誉数据：退信率、投诉率、账户年龄，不暴露原始地址。
智能体 DID 中继（可选） 若智能体已将 did:key 绑定到 MultiMail 账户，可在 send_email / reply_email 中传入可选的 ucan 参数。MultiMail 会在单独的 X-Agent-Identity 头中原样中继智能体自签的 UCAN，不为其签名或背书，由收件方工具独立验证委托。未绑定 DID 时此功能不生效。
智能体自注册（auth.md） 智能体无需浏览器即可自行注册。协议使用已验证邮箱的身份断言，遵循受 WorkOS AuthKit 启发的 auth.md 约定。发现流程遵循 RFC 9728：GET /.well-known/oauth-protected-resource（资源元数据）、GET /.well-known/oauth-authorization-server（含 agent_auth 扩展的授权元数据）、GET /auth.md（人类/智能体可读的注册指南）。401 响应中的 WWW-Authenticate 头会自动将智能体指向这些端点。
内容扫描 每封外发邮件在投递前都会被扫描，进入 pending_scan 状态，随后转为投递或 pending_send_approval（门控模式下）。入站邮件经过同一管道。钓鱼、恶意软件和提示注入模式会在到达智能体收件箱前被标记。
邮件格式与线程 邮件正文以 Markdown 输入、格式化 HTML 输出。入站 HTML 以干净的 Markdown 到达（比原始 MIME 少 15 倍 token）。线程自动处理，回复邮件时头部会正确设置。
使用方式
远程服务器（推荐）：无需安装，首次连接时通过 OAuth 认证。适用于 Claude.ai、Claude Desktop、Claude Code、Cursor、Windsurf、Copilot（VS Code）、ChatGPT Desktop，以及任何支持远程服务器的 MCP 客户端。
本地 stdio 服务器：作为替代方案。可在 multimail.dev 获取密钥，或不带密钥运行以交互式创建账户。
其他接入方式：
- REST API：https://api.multimail.dev（提供 OpenAPI 规范）
- CLI：npx -y @mvanhorn/printing-press install multimail（将每个 API 端点作为 shell 命令）
- SDK：Python、Vercel AI SDK、LangChain、LlamaIndex、CrewAI、AutoGen
适用场景
需要让 AI 智能体代表操作者收发邮件的场景，尤其是对身份可信度、发送权限控制和人工监督有要求的场合。适合希望从只读逐步过渡到自主发送、并需要收件方可验证发件方身份的智能体应用。
限制
- 发送后返回 pending_scan 状态表示正在扫描，门控邮箱随后转为 pending_send_approval 等待人工审核，此时不应重试。
- 白名单变更必须由操作者邮件批准，智能体无法自行批准。
- DID 中继功能仅在智能体已绑定 did:key 时生效。
- 使用即表示同意其服务条款与可接受使用政策。
（注：资料未提供具体收费、价格、平台覆盖范围或效果数据，暂未提供。）
