用开源 MCP 接入 Titan 企业邮箱

Titan 邮箱没有公开 REST API，作者选择用它支持的 IMAP 和 SMTP，做了一个开源 MCP Server，让 Claude 能搜索邮件、整理收件箱和起草回复。通过 GoDaddy 购买邮箱的用户，也可能用得上这条接入路径。

项目的价值是把传统邮件协议接进 AI 工具链。但接通只是第一步：禁止发送能拦住哪些操作、邮件内容会流向哪里，仍需要分开判断。

没有 REST API，Claude 怎么读邮件

作者开发的 titan-email-mcp 充当协议适配层：Claude 通过模型上下文协议（MCP）调用工具，服务端再用 IMAP 访问邮箱、用 SMTP 连接发信服务。

这样，用户可以直接提出任务：总结今天的未读邮件、查找去年三月的发票、起草确认周四安排的回复，或者把收件箱中的 newsletter 移到 Archive。

这些是作者列出的使用场景，原文没有提供各类任务的成功率，也没有展示复杂邮件整理的测试结果。

项目使用 TypeScript 和 Node.js，通过 stdio 与 MCP 客户端通信，采用 MIT 许可证，已发布到 npm，并列入官方 MCP Registry 和 Smithery。文中列举的客户端包括 Claude Desktop、Claude Code 和 Cursor，也支持其他 MCP 客户端。

接入前，先打开 Titan 的协议开关

第一步是在 Titan 网页邮箱中进入 Settings → Enable Titan on other apps，启用 IMAP/SMTP。作者特别提醒：没有打开这个开关，即使密码正确，登录也会被拒绝。

Claude Desktop 可以在 claude_desktop_config.json 中加入以下配置，让客户端通过 npx 启动服务，并关闭发送能力：

{
  "mcpServers": {
    "titan-email": {
      "command": "npx",
      "args": ["-y", "titan-email-mcp"],
      "env": {
        "TITAN_EMAIL": "you@yourdomain.com",
        "TITAN_PASSWORD": "your-password",
        "TITAN_PROVIDER": "titan",
        "TITAN_FROM_NAME": "Your Name",
        "TITAN_ALLOW_SEND": "false"
      }
    }
  }
}

要关注 TITAN_ALLOW_SEND 这一行：它关闭发送，但保留草稿功能。

使用 Claude Code，则可以运行原文给出的命令：

claude mcp add titan-email --scope user \
  -e TITAN_EMAIL=you@yourdomain.com \
  -e TITAN_PASSWORD=your-password \
  -e TITAN_PROVIDER=titan \
  -e TITAN_ALLOW_SEND=false \
  -- npx -y titan-email-mcp

这里的 --scope user 指定用户级配置；如果邮箱由 GoDaddy 托管，需要把 TITAN_PROVIDER=titan 改为 TITAN_PROVIDER=godaddy。

作者称，GoDaddy 预设已在一个真实邮箱上测试过。其他转售商可以直接通过 TITAN_IMAP_HOST 和 TITAN_SMTP_HOST 覆盖服务器地址，但原文没有给出它们的兼容性测试结果。

配置完成后，让 Claude 调用 test_connection。预期 IMAP 和 SMTP 都返回 "status": "ok"。连接检查通过，只能说明协议连接正常，不能代替对具体工具行为的验证。

禁止发送，不等于整个邮箱只读

作者为这个服务列出了几项控制措施：

• TITAN_ALLOW_SEND=false 禁用发送，用户仍可让 agent 起草邮件，再自行发送。
• 凭据从本地配置经 TLS 直接连接 Titan，服务没有代理和遥测。
• 每次调用创建短暂的 IMAP 会话，结束后关闭，不缓存或记录到磁盘。
• 只提供 10 个工具，控制 agent 可以调用的操作范围。

这些设计有实际价值，尤其是把起草和发送分开。但作者把禁发开关称为「只读」，这个表述需要收紧。

禁止发送，不等于禁止修改邮箱。

原文同时列出了把 newsletter 移到 Archive 的场景，却没有交代禁发状态下是否仍允许移动邮件。准备接入工作邮箱时，需要核对具体工具权限，不能只看这个环境变量。

同样，「没有中间代理」描述的是服务连接 Titan 的路径。它并没有说明邮件交给 Claude 处理后，模型侧如何传输和保留这些内容；服务不落盘，也不能据此推导整条处理链路都不保存数据。

我的判断

这个项目选对了接入层：Titan 已经支持 IMAP/SMTP，就可以先用标准协议完成邮件操作，无须等待公开 REST API。对需要在现有 MCP 客户端里处理 Titan 邮件的人，这条路径很直接。

但原文更接近项目介绍，还不足以证明它适合大规模邮箱自动化。明确提到的实测是 GoDaddy 真实邮箱预设；搜索效果、批量整理可靠性、并发行为和性能数据都没有给出，也没有与其他实现做对照。

每次调用都重新建立 IMAP 会话，有助于缩短连接生命周期，但是否增加延迟，原文没有测量。10 个工具便于审查，也不能单凭数量判断权限足够小。比起直接让 agent 批量整理收件箱，我更倾向于先从查询和草稿开始验证。

能拿来做什么

• 如果你使用 Titan 或 GoDaddy 邮箱，可以先开启 IMAP/SMTP、配置正确的 provider，再用 test_connection 排查连接问题。
• 日常 AI 编程时，可以先让 Claude 查找项目往来邮件、总结未读内容或起草回复，并保持 TITAN_ALLOW_SEND=false，由自己完成发送。
• 如果准备批量归档邮件，应先检查工具清单及禁发状态下的可执行操作，再用少量邮件验证整理结果。
• 如果你在写 Node.js MCP 工具，可以参考它把现有协议包装为有限工具的思路，并明确区分读取、草稿、发送和移动邮件的权限。