最近的一篇文章提出，模型上下文协议（MCP）是为早期一代 AI 助手设计的，如今应当让位于直接的 HTTP API 和命令行工具。这篇文章最有力的技术观察是：拥有广泛终端访问权限的智能体，可以查看文档、编写脚本、调用多个 API，并组织起完整的工作流程，而无需专用的 MCP 服务器。这确实是一项重要能力，但它本身并不能证明，对于每一种智能体或每一种部署方式，MCP 都已经变得不再必要。
本文所讨论的文章主张，MCP 从一开始就是个糟糕主意；这张图片呈现了这一开场立场，以便文章随后提出反驳。
分歧的关键在于适用范围。Anthropic 于 2024 年 11 月推出 MCP，将其定义为一种开放标准，用于在 AI 应用与外部数据源之间建立双向连接。其公开目标是，用一种共同架构取代定制化的连接器：由服务器公开各项能力，客户端则负责发现并调用这些能力。这一描述说明了 MCP 为何能够充当集成与治理层，但并不能证明每一种具体实现都高效，也不能证明该协议是所有智能体的最佳接口。
在智能体已经拥有可靠的执行环境、足以理解某个 API 的上下文，以及访问该 API 的权限时，直接访问的理由最为充分。一份文档完善的 REST 端点，或一个成熟的 CLI，届时可能比一组固定不变的 MCP 工具更加灵活。智能体可以自行构造请求、组合不同服务，并在端点发生变化时作出调整。然而，这种比较预设了许多生产环境智能体刻意不具备的能力。终端访问并不仅仅是另一种传输选项：它还可能泄露凭据、本地文件和网络资源，并开放超出目标服务范围的操作用途。
这一区别对安全与运营十分重要。一个权限范围经过严格限定的 MCP 服务器，可以只提供选定的工具，而不是开放不受限制的网络或 Shell 访问。它还可以在由管理员控制的边界上，集中处理身份验证、授权、权限撤销和审计日志记录。这些是 MCP 可能带来的架构优势，并不保证每一次 MCP 部署都能安全落实这些措施。本文提供的证据不包括比较性安全审计、性能研究或事故数据，因而无法证明 MCP 比通过代理介导的 API 设计更安全、更快或更便宜。
这篇文章还指出了一个真实存在的规模化问题：服务器数量过多，工具模式过于冗长，都会占用模型上下文，并增加工具选择难度。工具发现、搜索和程序化调用，正是针对这一问题提出的解决方案。Anthropic 报告称，截至 2025 年 12 月，活跃的公共 MCP 服务器已超过 10,000 个；该公司还表示，其 API 已加入 Tool Search 和 Programmatic Tool Calling，以应对大型工具集，并降低复杂工作流中的延迟。这些是 Anthropic 关于自身生态系统与产品的说法，而非独立测量结果，但它们表明，生态系统的参与者正在把上下文膨胀视为一个需要解决的工程问题，而不是简单地予以接受。
直接 API 解决的是问题的另一个方面。它们无需把每一项操作都转换成单独声明的工具，便能提供广泛的功能；标准的內容协商机制还可能允许智能体请求简洁的文本或 Markdown。然而，API 规范仍然必须易于发现、容易理解、具有清晰的版本管理，并且与智能体的运行环境兼容。CLI 可以提供稳定接口，但前提是它确实存在、拥有完整文档、能够输出机器可读的结果，并且适合由智能体自主调用。本文提供的来源并未证明，MCP 当前连接的各项服务普遍满足这些条件。
MCP 的治理沿革，也让“它仅仅是一项与过时模型绑定的 Anthropic 实验”这一说法变得更加复杂。Anthropic 于 2025 年 12 月宣布，将把 MCP 捐赠给 Agentic AI Foundation；后者是 Linux Foundation 旗下的一项定向基金。与此同时，Anthropic 表示，该项目的治理模式将保持不变。这一举措或许能够支持 MCP 正获得更广泛管理的说法，但并不能验证相关采用数据，也无法解决其中的技术权衡。它确实意味着，人们不能再只把 MCP 的未来视为某一家厂商旗下助手的一项功能来评估。
因此，对构建者而言，实际选择取决于具体条件。一个权限受到谨慎控制的终端智能体，可能只需要更少的 MCP 封装，并从直接访问 API 或 CLI 中受益。多用户应用、受管桌面助手或企业工作流，则可能需要受约束的能力边界、经过委托的凭据、一致的用户同意机制以及集中式日志。MCP 可以为公开这一边界提供一种共同方式，不过，设计良好的 API 网关或服务代理，即使不采用该协议，也可能提供部分相同的控制措施。
现有证据支持的结论，比“MCP 从一开始就是个糟糕主意”更为有限。它支持这样一种观察：对于能力较强的智能体，直接接口可能具有更强的表达能力；规模庞大的 MCP 部署也确实会带来工具发现与上下文管理方面的挑战。但它并不能证明，具备终端能力的智能体代表着默认的生产环境；不能证明直接访问能够消除身份验证风险；也不能证明，在不适合开放执行权限的场景中，MCP 毫无价值。真正有用的工程问题，并不是智能体能否调用 API，而是哪一种接口能够以最小的访问权限、运营复杂度和暴露面，提供所需的能力。