为什么 MCP 正在变得过时：对模型上下文协议的批判性审视

TL;DR – MCP 正在失去相关性

模型上下文协议（MCP）于 2024 年 11 月推出，如今已越来越没有必要，因为当今的大语言模型可以直接发现并调用 API 或命令行工具，从而消除了 MCP 服务器带来的上下文膨胀和运维开销。

MCP 最初的承诺

MCP 由 Anthropic 创建，旨在让智能体通过统一的 JSON-RPC 接口访问外部服务。早期的模型需要一个轻量抽象层来将自然语言意图转换为具体的工具调用，而 MCP 迅速成为一种即插即用的解决方案，适用于无法访问终端的智能体。

“MCP 于 2024 年 11 月由 Anthropic 团队发布，作为一种旨在帮助智能体连接外部服务和数据源的协议”【1】。

协议为何开始瓦解

工具集不断增长导致上下文膨胀

每个 MCP 服务器都捆绑了许多工具，每个工具都有自己的模式。当智能体加载多个服务器时，组合模式会淹没模型的上下文窗口，迫使开发者修剪或代理工具。

“每个服务器都会附带多个工具，每个工具都有自己的模式，这开始使所有这些模型的上下文过载”【1】。

更好的模型可以直接生成和执行代码

现代智能体（Claude Code、Meta Muse、OpenClaw 等）可以编写脚本、组合多服务工作流，并调用它们从未见过的 API。Cloudflare 的 Code Mode 展示了这一转变，让 LLM 生成沙箱脚本，而不是依赖 MCP 服务器【1】。

“LLM 在这方面已经非常擅长，Cloudflare 甚至推出了 Code Mode，这是一种更好的 MCP 使用方式，让 LLM 将各种调用组合成可在沙箱中执行的脚本”【1】。

通过 `--help` 直接发现 CLI

智能体现在使用命令行工具的 --help 输出来推断参数，从而无需单独的发现层。

“LLM 已经学会了如何使用 --help 命令来发现 CLI，因此它们不再需要 MCP 服务器来访问许多服务”【1】。

来自社区的反对观点

治理、身份验证和可审计性

几位评论者认为，MCP 仍然提供了一个受控的网关，用于凭证处理、权限边界和审计日志——这些是原始 API 或 CLI 访问所缺乏的功能。

“MCP 使得控制智能体可以访问哪些外部服务、在不暴露 API 密钥的情况下处理身份验证以及提供强大的审计日志变得更加容易” – @simonw。

企业级工具和插件商店

商业用户依赖 ChatGPT/Claude 市场中的一键式 MCP 插件，这些插件捆绑了身份验证和 UI 集成。

“MCP 之所以胜出，是因为在 ChatGPT 和 Claude 应用中存在插件商店。这些插件是一键安装的 MCP 服务器，支持身份验证” – @whazor。

远程控制场景

当智能体必须与仅限 UI 的应用程序或没有公共 API 的设备交互时，MCP 服务器可以暴露一个套接字级命令协议。

“对于远程控制 UI 应用程序（如游戏引擎编辑器）来说，MCP 服务器仍然很有意义，因为这类应用通常没有其他‘访问点’” – @flohofwoe。

何时直接使用 HTTP 或 CLI 优于 MCP

无状态、文档完善的 REST 端点 – 智能体可以附加 Accept: text/markdown 头（或类似头）来接收简洁、智能体友好的响应，而无需额外的模式。
大型 JSON 负载 – 使用带大小限制的 jq 或 curl 让智能体迭代过滤数据，避免 MCP 冗长响应导致的令牌爆炸。
安全优先的环境 – 集中式身份验证和权限系统可以直接构建在 API 网关中，从而无需额外的 MCP 层。

“我们应该开始标准化智能体如何直接使用 HTTP API。例如，智能体客户端可以附加头来标识自己是智能体，服务器可以自动以 Markdown 或文本形式发送响应数据” – 作者。

新兴实践的真实示例

Accept-Markdown 头 – 文档站点现在支持 Accept: text/markdown 来提供渲染后的 Markdown 而不是 HTML，从而减少令牌数量。
Accept-Language 用于 SDK 选择 – Vercel 和 Shopify 使用语言偏好来提供特定语言的 SDK 示例，提高智能体的相关性。

前进之路 – 并非二选一

社区共识是微妙的：

在 MCP 提供独特价值的地方保留它 – 受控的凭证处理、遗留 UI 自动化和企业插件生态系统。
对于简单、无状态的服务逐步淘汰 MCP – 用直接 HTTP 调用或 CLI 工具替代，智能体可以通过 --help 发现这些工具。
标准化智能体友好的 HTTP – 引入头（例如 User-Agent: agent/1.0）和内容协商格式，使 API 对 LLM 来说像 MCP 工具一样易于使用。

结论

MCP 是早期 LLM 的务实桥梁，但模型能力的快速提升、代码生成工具的兴起以及维护 MCP 服务器的开销已经改变了成本效益平衡。组织在承诺使用 MCP 之前，应评估它是否仍然解决真正的问题——例如安全凭证中介或远程 UI 控制——否则应采用更简单、性能更高且不易出现上下文膨胀的直接 HTTP 或 CLI 方法。