MCP 一直都是个坏主意吗？

原文 ↗ Hacker News 讨论 ↗

批评 Model Context Protocol（MCP）的人认为，它被过度炒作，而且与其让 AI agent 使用设计良好的 HTTP API 或 CLI 工具相比，往往会浪费更多 token，尤其是在模型如今已经更擅长理解接口的情况下。支持者则反驳说，MCP 仍然在身份验证、最小权限访问、沙箱、审计性和标准化工具发现方面解决了重要问题——特别是在企业和多用户环境中，你不能简单地给 agent shell 访问权限或原始 API 密钥。此次讨论凸显了一个更大的分歧：个人或本地工作流通常更偏好 CLI 和直接 API，而组织级和基于 Web 的 agent 使用场景则越来越倾向于 MCP 风格的标准以及像 WebMCP 这样的新变体。

MCP vs CLI / 直接 API

  • 许多人认为，CLI 和 REST/OpenAPI 已经解决了 MCP 试图解决的大多数问题；CLI 很熟悉、可组合，而且通常在 token 上更省。
  • 也有人说，MCP 本质上就是“给 agent 用的 REST”：一种标准化、可发现的工具接口，更符合如今 agent 调用工具的方式。
  • 有些人认为 MCP server 只是现有 API/CLI 的薄包装（“给猪抹口红”），只是在增加额外基础设施，并没有带来新的语义。

安全性、身份验证与最小权限

  • 在 auth 方面，对 MCP 有很强的支持声：它可以把凭据对 agent 隐藏起来、集中管理 auth，并且只暴露狭窄且经过审核的操作。
  • 批评者回应说，正确的 API 设计、短生命周期的作用域 token、代理，或沙箱化的 CLI 也能达到同样效果——MCP 并不具有独特的安全性。
  • 还有人担心，依赖 MCP 做访问控制可能会产生虚假的安全感；服务器端控制和审计仍然是必需的。

Token 使用、上下文与性能

  • 有几位提到，MCP 比直接使用 CLI/API 消耗更多 token（尤其是在实现糟糕时）；也有人说，当 MCP schema 足够紧凑时，情况正相反。
  • 旧版 MCP 设计会把过多内容加载进上下文，这一点被广泛批评；较新的“无状态 / 渐进式”变体被视为改进。
  • 相比 LLM 或网络延迟，CLI 的进程启动开销通常被认为微不足道。

企业、治理与真实世界使用

  • MCP 被认为在多用户、企业场景中最有价值：集中控制、审计日志、密钥撤销/轮换，以及跨运行时的统一接口。
  • 主流聊天应用中的 MCP 插件商店推动了非技术用户的采用；一些人认为这也是 AI “泡沫”的一部分。

标准、替代方案与 WebMCP

  • 有几位认为，现有标准（REST、OpenAPI/Swagger、SOAP/WSDL、HTTP 头、.well-known 文档）本可以被扩展，而不是发明 MCP。
  • WebMCP 被称赞为更简单、更契合 Web 应用的方案，在那类场景中有可能取代“经典” MCP。
  • 提到的替代方案包括：以 CLI 为中心的 harness、自定义沙箱/VM、AXI，以及带有良好规范的通用“发 HTTP 请求”工具。

总体情绪

  • 共识是：MCP 并非普遍糟糕，但被过度炒作且常被误用。
  • 线程里的大致经验法则是：对于个人/本地开发，CLI + API 通常就够了；当你需要跨工具标准化、远程访问和集中治理时，MCP 才变得有吸引力。