用途定位
radmail-mcp 是一个面向 AI 智能体的邮件操作系统，以 Model Context Protocol（MCP）服务器的形式提供，使任何 AI 智能体都能操作收件箱。它并不让智能体拥有或代发邮件，而是在真人邮箱之上提供一层“分流与跟进”能力：智能体负责排序、解释、承诺追踪和起草，发送权始终保留在真人手中。
项目将自身定义为邮箱 MCP 服务器分类中的“第四种形态”。它区别于三类常见产品：面向应用的事务性/生命周期邮件发送、智能体自有邮箱的端到端收发，以及通过 OAuth 读写真人 Gmail/Outlook 的授权访问。radmail-mcp 是“停留在真人邮箱之上的分流与跟进层”。
主要能力
- 双轴分流：按重要性 × 紧急度对邮件进行分级。
- Right Now 通道：返回当下不可错过的邮件通道，包含分级、重要度、紧急度与原因。
- 承诺跟进（commitment follow-through）：列出未兑现的承诺，包含方向（owed_by_us / owed_to_us）、当事方、动作、截止日期/表述、状态与置信度。
- 可审阅草稿：由 RadMail 起草，由真人发送，作为硬停止类别之外的人审路径。
- 邮件搜索与读取：在连接模式下可搜索历史邮件并读取完整消息（headers + textBody）。
- BEC 硬停止（机器可验证）：money、changed-banking、first-contact、decision/sign-off、prompt-injection 五类事项被确定性代码判定为 hardStop，永远仅限人工，任何提示词都无法让 RadMail 自动发送。
使用方式
零认证托管沙箱（最快，无需安装、密钥或注册）：将任意 MCP 客户端指向 streamable-HTTP 端点；也可以不带 token 调用 triage_inbox，RadMail 会自动分配一个免费沙箱租户并在一次往返中返回可用的分流结果，之后复用返回的 token。在零认证托管沙箱上，triage_inbox 不接收参数，它分流一个内置演示收件箱。
本地 stdio 方式：
npx radmail-mcp
该包已发布在 npm 上，上述 npx 命令可直接使用。
从源码运行：
git clone https://github.com/radmail-ai/radmail-mcp && npm i && npm run build && npm start
（stdio）。托管部署为 Vercel Node serverless 函数（api/mcp.ts；/ 重写至 MCP 处理器）。
连接模式——接入真实收件箱：设置 RADMAIL_API_KEY 后，search、read_email、list_right_now、list_commitments 四个工具将作用于真实邮箱；可选 RADMAIL_API_URL 覆盖 API 主机（默认 https://app.radmail.ai）。密钥以 tmk_ 开头，可在 https://app.radmail.ai/settings/api-keys 创建。连接模式仅发出 GET 请求，只读，从不发送、起草或修改真实邮件。
适用场景
适合需要将公司邮箱委托给智能体处理、同时又必须对高风险操作保留人工控制的团队。其安全契约通过 /.well-known/agent-safety.json 公开，提出 enforcementModel 的三个取值：capability-absent（能力缺失，工具根本不存在，无法调用、无法配置、无法绕过）、config-restricted（能力存在但被配置收窄，持有配置者可再次放宽）、policy-gated（能力存在，靠指令或文档政策约束）。radmail-mcp 在硬停止类别上报告 capability-absent：托管端点没有任何具备发送能力的工具，发送仅作为本地可选工具存在，且即便启用也无法释放被扣留的邮件。
安全契约还包含：taint envelope——所有源自原始邮件正文的字段都带有 provenance: "untrusted-email-body"，每个响应附带重申硬停止的 safety 块；fail-closed——若风险信号无法评估，则拒绝自动发送。
限制与注意事项
- 不适合希望智能体自有地址并全自动回邮的场景：radmail-mcp 会拒绝的恰恰是这类需求所要求的能力。
- 本地服务器运行的是沙箱引擎（启发式、内存中、免费、无凭据），是真实可运行的，但并非生产环境的“99%”引擎。
- 发布版本存在一处诚实说明（截至 2026-09-30）：npm view radmail-mcp dist-tags 显示 latest: 0.5.0，但该 tarball 内构建在 MCP 上自称 0.4.0（dist/ 在版本号提升前打包）；仓库 main 已至 0.5.1 并修复根因（prepublishOnly 现在会在打包前重建 dist/），修正后的包尚未发布，因为发布需要仅维护者可执行的交互式 npm 登录。安全契约不依赖版本字符串。
- 验证方式：安全契约可机器验证，无需账户与密钥即可获取；还可读回工具列表检查是否存在具备发送能力的工具。托管沙箱 2026-10-09 观察为 6 个工具：triage_inbox、list_right_now、why_surfaced、list_commitments、draft_reply、search。需要注意，按名称 grep 可能误匹配 check_send_domain（只读的 SPF/DKIM/DMARC DNS 查询，不发送任何内容），应阅读每个工具的说明而非仅看名称。
- 一个无法从外部检查的声明（“没有工具能释放被扣留的发送”）由仓库内的测试断言，可运行测试验证；仓库还公开了证伪步骤（在 src/lib/send.ts 添加一行后重跑，第二项断言失败且套件以非零退出）。2026-10-05 观察：3 通过，0 失败。
