托管 vs. 自托管 Gmail MCP 服务器：优势、劣势与成本

如果你想让 AI 代理读写 Gmail，真正可行的只有两条路：用开源仓库跑一个自托管的 Gmail MCP 服务器，或者让客户端指向一个托管服务器。DIY 这条路一分钱不花，给你完全的掌控，但 OAuth 配置、令牌加密、托管、更新和安全都得你亲自扛。像 MCP Emails 这样的托管服务器只需几分钟就能接好，还会让凭据保持加密——代价是你得信任一家厂商来处理这层连接。

这是诚实的剖析。我做的是托管服务器，所以我有立场，但我会明确告诉你自托管在哪些地方更胜一筹，以及哪类人应该选它。如果你想先理解动词层面的模型，那篇为 AI 代理开通邮件访问的完整指南是与本文配套阅读的支柱文章。

“自托管 Gmail MCP 服务器”到底是什么意思

搜索“Gmail MCP server”，你会找到一打 GitHub 仓库。你克隆一个，注册一个 Google Cloud 项目，生成 OAuth 客户端凭据，跑一遍本地的 OAuth 同意流程，然后服务器会把刷新令牌存在磁盘上或某个环境变量里。之后你的 MCP 客户端就会跟一个运行在 localhost 或你租来的机器上的进程通信。

整套卖点就是这些，对于你自己笔记本上的单个 Gmail 账户来说，它确实管用。代价会在后面才显现，而且不是用美元来衡量的。

自托管的理由：它真正胜出的地方

我不打算假装 DIY 是个坏主意。对合适的人来说，它就是正确的选择。

你拥有完全的掌控，零厂商信任

代码跑在你自己的硬件上。没有任何第三方夹在你的代理和 Google 之间。如果你的威胁模型说“绝不让外部服务碰我的邮箱，没得商量”，那自托管是唯一能满足这一点的答案。你可以读每一行代码，分叉它，永远把它钉在某个版本上。

它在美元上是免费的

没有订阅费。Gmail API 本身在任何代理会触及的用量下都是免费的。如果相对于 $12/month 来说你的时间很便宜，那这笔账就偏向自己动手。

你可以把它改成任何样子

自定义工具、奇怪的 IMAP 文件夹、一套私有的标签分类法、一条喂给你 SIEM 的日志管道。当你拥有这个进程，这些你都能做。托管产品只能给你它给你的那块界面。

自托管的理由：它真正让你付出代价的地方

现在说说那些仓库 README 一笔带过的部分。

OAuth 配置得你自己扛

一个 Google Cloud 项目、一个 OAuth 同意屏幕、正确的权限范围，以及——如果你想让自己以外的人也能用它——Google 的应用验证流程，那是一次真实的审核，有真实的等待周期。权限范围弄错一个，你就得回到控制台。这一步第一次会吃掉你一个下午，之后每次令牌过期或 Google 改了策略时，再咬掉小一点的一口。

凭据存储和加密得你自己扛

这是让我睡不着觉的那一个。一个拥有 read:email 和 send:email 权限的刷新令牌，等于某人邮箱的万能钥匙。大多数 DIY 方案会把它丢进一个明文文件或一个环境变量里。如果那台机器被攻破，或者令牌泄露进了某个日志或备份，攻击者就能以你的身份读邮件、发邮件。

把这件事做对，意味着对静态令牌加密、把加密密钥与令牌存储分开、并且只在调用时在隔离的上下文中解密。这描述起来不难，建起来和维护起来却着实烦人。如果你跳过它，那你就建起了一个隐患。为什么“邮件从不存储”很重要从架构层面更深入地谈了这一点。

托管和正常运行得你自己扛

一个 localhost 服务器会在你笔记本休眠时死掉。如果你想让代理在早上 6 点整理邮件，或者无人值守地运行，你就需要一个始终在线的进程——一台 VPS、一个容器、一套重启策略、TLS、监控。那是运维工作，而且它永远不会停止是运维工作。

更新和安全补丁得你自己扛

MCP 还很年轻。规范在变，Google 在轮换要求，你克隆的那个仓库可能会变得陈旧或被弃坑。当某个依赖爆出一个 CVE，那就是你的传呼机响了。钉死一个版本你就会落后；跟着 main 走，你就继承了别人的 bug。

多服务商得你自己扛

你选的那个仓库只做 Gmail。等你哪天要加一个 Outlook 账户或一个 iCloud 地址，你就得自己去对接 Microsoft Graph，或者自己接通 IMAP 和 SMTP，外加第二套认证模型和第二组边界情况。大多数 DIY 服务器都只停留在 Gmail，因为第二个服务商本身就是一个独立的项目。

托管的理由：诚实地说说 MCP Emails

托管 MCP 服务器把这笔交易翻了过来。你放弃自己跑代码；换回上面那张清单本会耗掉的全部时间。

配置只需几分钟，而不是一个下午

你注册，进入 Dashboard → Inboxes → Connect Inbox，选 Gmail，点过 Google 的一键 OAuth。没有 Cloud 项目，没有同意屏幕，没有验证排队。然后你连接你的代理。对于 claude.ai 或 Claude Desktop，你粘贴 MCP 端点 URL，登录，批准权限范围——不需要 API 密钥。对于没有 OAuth 的客户端，比如 Cursor、Cline 或一段原始脚本，你在 Dashboard → API Keys 里铸一个限定范围的 API 密钥，然后把它作为 bearer token 发送。

凭据已加密，邮件从不存储

每个收件箱唯一被持久化的东西就是 OAuth 令牌，并且它以 AES-256-GCM 静态加密。密钥作为一个环境密钥存在，与数据库分开，解密只在调用时于一个隔离的 Edge Function 内部发生。邮件本身完全不被存储——每一次 email_read 调用（无论是列出、读取还是搜索）都实时打到 Gmail，把结果交给你的代理，然后丢弃。这就是自托管那一节里说的加密工作，已经做好并持续维护。把邮件访问交给 AI 代理安全吗完整走了一遍安全模型。

多服务商免费附带

同一个端点、同样的核心工具——inbox_list、email_read、email_compose、用于标记和文件夹的 email_organize，外加 folder、draft、schedule 和 contact_search——可以跨 Gmail、Outlook、iCloud、Fastmail 以及任何 IMAP 收件箱使用。下周加一个 Outlook 账户，你的代理什么都不用改。

发送始终走你自己的服务商

MCP Emails 从不从自己的域名转发邮件。email_compose（配合 send 操作）通过你的 Gmail（或 Microsoft Graph，或你自己的 SMTP）发出，所以你的域名信誉和送达率仍然是你自己的。这跟你自托管能得到的属性一样，只是不用你自己去建。

诚实的代价：你信任一家厂商

这才是真正的取舍，我不会美化它。用托管服务器，你那个加密的令牌待在别人的数据库里，你代理的调用经过别人的代码。你是在信任那加密是真的、那隔离是稳的、那家公司不会干蠢事。对大多数人来说，这份信任放对了地方，而且省下大量时间。如果你的威胁模型直接禁止这一点，那就自托管——这才是选它的正当理由。

在美元上它花多少钱

MCP Emails 起步免费，而且 Free 是无限量的：无限收件箱、无限工具调用、无限 API 密钥，无需信用卡。Free 套餐以 60 requests/minute 运行，配 7 天分析和社区支持。Solo 是 $12/month（300 req/min、90 天分析、邮件支持），Team 是 $49/month，包含角色、多工作区、SSO 和审计日志。自托管的订阅费是 $0，外加你的 VPS 和你的工时所花的一切。对工时要诚实。

那么你该选哪个？

如果你是一名享受底层管道活儿的工程师、需要完全掌控或有“不用第三方”的硬规矩、乐意自己扛 OAuth、加密和正常运行、并且永远只碰一个 Gmail 账户，那就选 self-hosted。这是个真实、站得住脚的选择。

如果你想今天就有一个能用的端点、宁愿不用为自己的邮件基础设施随时待命、以后多半会加上 Outlook 或 iCloud 或一个 IMAP 收件箱、并且想把凭据加密交给全职维护它的人，那就选 hosted。这适合大多数人，包括大多数有能力自己建、但有更要紧的事要做的工程师。

如果你还在拿不准代理究竟该怎样触及你的收件箱，让 Claude 管理收件箱的最佳方式对比了更宽泛的几种选项。准备好了就免费开始，或者快速浏览文档——连接一个 Gmail 收件箱真的只要大约一分钟。