作者最近参加了一场围绕模型上下文协议（MCP）的全天活动，演讲者都很出色，也对自己的工作充满热情，但他已厌倦 MCP：这是个糟糕的协议，专为大语言模型还不够聪明的时代设计，如今我们已超越它。MCP 由 Anthropic 于 2024 年 11 月发布，本意是帮智能体连接外部服务和数据源；当时模型还相对原始，连 Claude Code 都没有，通用智能体工作流也远不可靠。

为什么 MCP 一直都是个坏主意

我最近参加了一个聚焦 MCP 最新动态的全天活动，但我真的受够了 MCP。这是个糟糕的协议，为当初大模型还不够聪明时设计，如今我们已经超越它了。

简要历史

Anthropic 团队于 2024 年 11 月发布 MCP，旨在帮智能体连接外部服务和数据源。当时模型相对原始，连 Claude Code 都还没有，通用智能体工作流远不可靠。

用户逐渐发现让 AI 接入外部服务很有用，生产力空前提高。MCP 采用率暴增，与经济中各行业大模型的爆发式增长同步。

后来 MCP 在 Anthropic 管理下演进，最终于 2025 年捐给 Linux 基金会旗下的 Agentic AI Foundation。

MCP 工业复合体

采用率大涨后，用户往配置里加很多 MCP 服务器，遇到了上下文膨胀问题。每个服务器带多个工具和各自 schema，撑爆模型上下文。开发者想出不少变通法，比如 Composio、MintMCP、Pipedream 提供的通用搜索/执行模式，把凭证集中存放，只给智能体最少工具以减少膨胀。短期内这不错。

但我们忽略了一件事：模型在变强。现在整套系统专门监控 MCP 服务器、保证响应质量、帮智能体容易调工具、解析 schema，就为了让智能体在正确时间做正确调用。

不出所料，大厂是对的

模型变强了，能在电脑上执行代码、推理大型代码库、更加自主。其中大量工作是写或跑脚本，副作用是它们擅长直接调 API 了。它们能写脚本、组合不同服务、调用没见过的 API，用户极少干预。

大模型这能力太强，Cloudflare 甚至推出 Code Mode，让大模型把各种调用编成脚本在沙箱执行，作为用 MCP 的更好方式。

更妙的是，大模型学会了用 --help 发现 CLI，不再需要 MCP 服务器就能通过文档化 API 或 CLI 访问服务。多数远程 MCP 服务器不过封装了已有 API。

现在怎么办？

我们删掉大多数 MCP 服务器就行了。有终端权限的智能体就能取代它们，往往还更强。问题比如 CLI 返回机器可读格式（JSON/XML）太费 token，但可以解决。

替代方案大多现成：文档化 HTTP API、标准内容协商、成熟鉴权机制。

我们应规范智能体直接用 HTTP API。比如客户端加标识自身的头，服务器直接返回 Markdown 或文本而非 HTML 或冗长 JSON。

一些真实例子

1. Accept Markdown 头

越来越多对大模型友好的服务器，尤其是文档类文本站，支持 Accept: text/markdown 头，自动发渲染好的 Markdown 而非 HTML。该媒体类型已标准化，用于智能体内容协商正被采纳。

2. 文档站使用 Accept-Language 头

最近一位 Vercel 工程师呼吁框架发送客户端偏好的编程语言，让文档站给更具体的例子。比如加 Python 就优先给 Python SDK 文档。Shopify 的 Tobi Lutke 很喜欢，已在 Shopify 文档上线。

结语

通用协议标准化造就了今天的互联网。MCP 已是过去时代的协议。智能体聪明，能写脚本、精准索要所需。别再陷在 MCP 里了，该让它退休，直接依赖现成的 HTTP API 和 CLI。

针对一篇主张 MCP 已被原生 API 与 CLI 取代的文章，社区并未一边倒否弃 MCP：较多人指出其在权限隔离、无 API 接入和商业化插件中仍有实值，少数人认同 MCP 纯属冗余且烧钱。

认为 MCP 在权限控制与凭证隔离上不可或缺

• 实际用例常需精确限制代理可访问的服务、避免模型直触密钥、提供认证界面与审计，MCP 大幅简化此类管控（较多人） > 若想比裸奔代理更克制，就需要控制访问范围、隐藏密钥、提供认证 UI 和审计日志，MCP 让这些都更易实现（@simonw）

认为 MCP 为无 CLI 或缺少 API 的场景提供桥梁

• 手机等无 shell 环境跑不了命令行，SaaS 也不提供 CLI 扩展；MCP 远程服务与插件商店让商业用户一键带认证接入，且倒逼大批无 REST 的网站暴露可用接口（较多人） > 聊天应用里的插件商店实为一键安装的 MCP 服务，带认证，商业用户正这么用（@whazor）

认为模型直接调 API 仍不可靠且 MCP 能降低困惑

• 前沿模型实操中仍常猜错参数空耗上下文，成本模型短期内仍需辅助；明确定义的 MCP 比让模型自爬文档更确定高效（较多人） > 昨天用微软的 MCP 从文件建语义模型很神奇，比让模型自己查文档网站靠谱得多（@doctaj）

认为 MCP 设计糟糕且鼓励无意义令牌消耗

• 功能受限易卡死，运行时烧钱，本该用确定性程序直连 API；连生产库更涉数据泄露（少数人） > 规范起初就设计拙劣，单请求就吞大量令牌，给生产库开 MCP 纯属冒险（@rvz）

反对借 HTTP 标准头传递编程语言偏好

• Vercel 等提议用 Accept-Language 塞编程语言是滥用数十年标准，应新立头字段或置于 URL，并应与标准组织协作（较多人） > 编程语言差异远甚于翻译，应放 URL 而非混入 Accept-Language 语义（@graypegg）

有价值的补充

• 有开发者推荐 AXI 作为 MCP 替代，称包裹命令行或 MCP 后更可靠且更省令牌（@brycehamrick）
• MCP 作代理仍有价值：可绕 IP 限流、注入必要凭证，且部分供应商为 MCP 注册提供自动续期而非个人令牌（@fweimer）
• 类比：MCP 如同 JSON，解决了问题又没过度设计，让偏爱过度工程的人不适，但恰是其优点（@postalrat）