开发者对MCP协议应关注的5个核心问题

模型上下文协议（MCP）自2024年底由Anthropic推出以来，已成为AI集成领域最受关注的发展之一。如果你关注AI领域，可能已经被开发者对这个话题的各种"热议"淹没了。有些人认为这是有史以来最好的东西；另一些人则迅速指出其不足之处。实际上，两种观点都有一定道理。

我注意到MCP采用的一个模式是，怀疑通常会让位于认可：这个协议确实解决了其他方法无法解决的真实架构问题。我整理了以下问题清单，反映了我与考虑将MCP引入生产环境的其他开发者的对话。

**1. 为什么我应该选择MCP而不是其他替代方案？**

当然，大多数考虑MCP的开发者已经熟悉了OpenAI的自定义GPT、原生函数调用、带函数调用的Responses API，以及与Google Drive等服务的硬编码连接等实现方式。问题并不在于MCP是否完全取代了这些方法——在底层，你完全可以使用仍然连接到MCP的带函数调用的Responses API。这里重要的是最终的技术栈。

尽管MCP备受炒作，但实话实说：它并不是一个巨大的技术飞跃。MCP本质上是以大语言模型可以理解的方式"包装"现有API。当然，许多服务已经拥有模型可以使用的OpenAPI规范。对于小型或个人项目，MCP"没那么重要"的反对意见是相当公平的。

实际好处在你构建需要连接多个生态系统数据源的分析工具时变得明显。没有MCP，你需要为每个数据源和每个你想支持的大语言模型编写自定义集成。有了MCP，你只需实现一次数据源连接，任何兼容的AI客户端都可以使用它们。

**2. 本地与远程MCP部署：在生产环境中的实际权衡是什么？**

这里你真正开始看到参考服务器和现实之间的差距。使用stdio编程语言的本地MCP部署运行起来非常简单：为每个MCP服务器生成子进程，让它们通过stdin/stdout通信。对技术用户很好，但对普通用户很困难。

远程部署显然解决了扩展问题，但在传输复杂性方面带来了一系列问题。最初的HTTP+SSE方法被2025年3月的可流式HTTP更新所取代，试图通过将所有内容放在单个/messages端点来降低复杂性。即便如此，对于大多数可能构建MCP服务器的公司来说，这实际上并不需要。

但问题是：几个月后，支持充其量是零散的。一些客户端仍然期望旧的HTTP+SSE设置，而另一些则使用新方法——所以，如果你今天部署，你可能需要支持两种方式。协议检测和双传输支持是必须的。

授权是远程部署需要考虑的另一个变量。OAuth 2.1集成需要在外部身份提供商和MCP会话之间映射Token。虽然这增加了复杂性，但通过适当的规划是可以管理的。

**3. 如何确保我的MCP服务器是安全的？**

这可能是MCP炒作和你在生产中实际需要解决的问题之间最大的差距。你看到的大多数展示或示例使用没有任何身份验证的本地连接，或者通过说"它使用OAuth"来回避安全问题。

MCP授权规范确实利用了OAuth 2.1，这是一个经过验证的开放标准。但在实现上总会有一些变化。对于生产部署，专注于基础：

- 与你实际工具边界匹配的适当基于范围的访问控制 - 直接（本地）Token验证 - 工具使用的审计日志和监控

然而，MCP最大的安全考虑是工具执行本身。许多工具需要（或认为它们需要）广泛的权限才能有用，这意味着宽泛的范围设计（如全面的"读取"或"写入"）是不可避免的。即使没有重手段方法，你的MCP服务器也可能访问敏感数据或执行特权操作——所以，有疑问时，坚持最新MCP认证草案规范中推荐的最佳实践。

**4. MCP值得投入资源和时间吗，它会长期存在吗？**

这涉及任何采用决策的核心：当AI的一切都在如此快速发展时，为什么我要费心使用一个季度性协议？你如何保证MCP在一年甚至六个月内会是一个可靠的选择（甚至还存在）？

好吧，看看主要参与者对MCP的采用：谷歌通过其Agent2Agent协议支持它，微软已将MCP与Copilot Studio集成，甚至为Windows 11添加内置MCP功能，Cloudflare也非常乐意帮助你在他们的平台上启动第一个MCP服务器。同样，生态系统的增长令人鼓舞，有数百个社区构建的MCP服务器和知名平台的官方集成。

简而言之，学习曲线并不可怕，对于大多数团队或独立开发者来说，实现负担是可管理的。它做到了它所承诺的。那么，为什么我会对购买这种炒作保持谨慎？

MCP从根本上是为当前一代AI系统设计的，这意味着它假设你有一个人类监督单个智能体交互。多智能体和自主任务处理是MCP没有真正解决的两个领域；公平地说，它也不需要解决。但如果你正在寻找一个既常青又仍然前沿的方法，MCP并不是。它正在标准化一些迫切需要一致性的东西，而不是在未知领域开拓。

**5. 我们是否即将见证"AI协议大战"？**

有迹象表明，AI协议未来会出现一些紧张局势。虽然MCP通过早期进入占据了一个不错的受众群体，但有大量证据表明它不会独自存在太久。

以谷歌与50多个行业合作伙伴推出的Agent2Agent（A2A）协议为例。它与MCP互补，但时机——就在OpenAI公开采用MCP几周后——感觉并非巧合。谷歌在看到大语言模型领域最大的名字采用MCP时，是在酝酿MCP竞争对手吗？也许转向是正确的举措。但认为随着MCP即将发布的多大语言模型采样等功能，A2A和MCP可能成为竞争对手，这很难说是投机。

然后是今天的怀疑论者对MCP是"包装器"而不是API到大语言模型通信真正飞跃的情绪。这是另一个变量，只有当面向消费者的应用程序从单智能体/单用户交互转向多工具、多用户、多智能体任务处理领域时，才会变得更加明显。MCP和A2A未解决的问题将成为另一种协议的战场。

对于今天将AI驱动的项目投入生产的团队，明智的做法可能是对冲协议。实现现在有效的方法，同时设计灵活性。如果AI实现代际飞跃并将MCP抛在后面，你的工作不会因此受损。对标准化工具集成的投资绝对会立即得到回报，但保持你的架构对接下来的任何事物都具有适应性。

最终，开发者社区将决定MCP是否保持相关性。是生产中的MCP项目，而不是规范的优雅性或市场炒作，将决定MCP（或其他东西）在下一个AI炒作周期中是否保持领先地位。坦率地说，这可能就是应有的方式。

Meir Wahnon是Descope的联合创始人。