MCP服务器为何慢：上下文token开销实测

让 AI 智能体使用你的产品，有两种方式。

A）发布一个 MCP Server。定义工具、描述工具、运行进程，由模型调用。

B）发布一个 CLI。yourtool do-the-thing --json，智能体像人类一样在 shell 中运行。

大约一年前，答案显然是 A。到了 2026 年，许多团队悄悄回到了 B——而这些这样做的团队并没有发"MCP 已死"的内容，他们发的是延迟数据图。

以下是实际情况。五个代价，按触发顺序排列。

1. 每个工具、每轮对话都要付费——在模型做任何事之前

MCP Server 的工具定义在上下文窗口初始化时就会加载。不是在工具被使用时加载，而是始终加载。

40 个工具 × 一个完整的带描述的 JSON Schema ≈ 数万个 token

这在第 1 轮、第 2 轮、第 60 轮都要付这笔钱

模型此时还没做任何事

CLI 只占用系统提示词中的一行。如果智能体需要具体细节，它会运行 yourtool --help——仅一次，只在需要时，而且输出可以是 30 行而不是 40 个 Schema。

Anthropic 测量了这个问题的极端情况：一个工作流在传递工具定义和中间数据时消耗了约 150,000 个 token，而当同一批工具以代码形式暴露给智能体调用时，降到了约 2,000 个 token——减少了 98.7%。这个差距不是微优化，这是整个账单。

原则：工具定义是租金，不是买断。你在删除工具之前每轮对话都要付这笔钱。

2. CLI 可以组合，MCP 工具不行

观察 shell 让模型在一个动作中能写出什么：

yourtool list --json | jq '.[] | select(.status=="failed") | .id' | head -20

一次往返，上下文里只有一个结果。

list_items → 800 行数据回到上下文窗口

模型在内部过滤

模型组织答案

至少四轮往返，而且第一步已经用 780 行没人要的数据污染了窗口。

Shell 已经有五十年的组合能力——管道、重定向、xargs、退出码。MCP 只有一列函数调用。每个"组合两个工具"的场景都变成了模型的工作，用 token 来做，而且做得很糟糕。

原则：如果你的用户会链式调用你的工具，一个没有链式原生支持的协议就是错误的形态。

3. 每个字节都要经过模型

这是真正变慢的原因。

MCP 工具结果进入上下文窗口。没有其他目的地。所以：

5 MB 的 JSON 响应不只是花钱的问题——它会驱逐所有有用的内容，然后你就得到经典的会话中段质量下滑

模型随后在每个后续轮次重新读取那个 blob

你无法"处理后丢弃"

在 shell 中，中间数据可以直接……留在磁盘上。

yourtool export --json > /tmp/out.json      # 5 MB，从不进入上下文
jq '.summary' /tmp/out.json                  # 只处理3行

智能体只看到三行。就上下文窗口而言，那五兆字节从未存在过。

原则：MCP 没有 > file。每个结果都是对模型的广播。设计返回值时要像你按字符付费一样，因为确实如此。

4. 一个没有任何增值的协议跳板（在一台已有 shell 的机器上）

每一层都是延迟和一个故障模式。而且这些故障模式智能体处理得比非零退出码更差，因为"服务器断连"不是模型能智能重试的情况。

2026 年的规范修订让很多人具体认识到了这一点：协议级会话被放弃，转向无状态核心。对企业横向扩展是合理的——但它破坏了每个悄悄在会话之上构建状态的 Server。那周没有人的 --help 输出坏掉。

原则：不需要的传输层不是免费的。它是延迟加上调用者无法推理的一类错误。

5. 模型已经知道 git。它从来没听说过 create_document_v2

这是被低估的那一点。

git、curl、psql、ffmpeg、gh、jq——模型见过这些工具数百万次。它知道参数、惯用法、错误信息，以及出错时该怎么做。

你的定制工具表面有零个训练样本。所以你用描述文本来补偿——这就是代价 #1——但你仍然会遇到经典失败：

两个重叠 80% 的工具，靠抛硬币选择

一个工具被选中是因为它的名字最接近，而不是因为它是对的

模型发明一个看起来合理但不存在的参数

遵循 Unix 约定的 CLI 继承所有这些先验知识，无需付费。--json、--dry-run、失败时非零退出码、错误输出到 stderr。模型对每一条都有强力先验。

原则：约定是不需要付费的预训练上下文。

诚实的部分：MCP 何时明显是对的

以上都不是在说 MCP 不好。而是在说 MCP 正在它最弱的环境中被人使用——一个已经有终端的编程智能体。

保留 MCP Server 的场景：

没有 shell 的地方。ChatGPT、Claude 的聊天界面、移动端 App、嵌入式助手。这是真正的答案，而且是个大答案。对于没有机器可运行 CLI 的用户来说，CLI 分文不值。

你不想给模型 shell。MCP 是你逐个工具控制的权限边界。bash 不是。

你的用户不是工程师。他们永远不会 brew install 任何东西。

你需要协议实际提供的能力——资源、订阅、采样、一个 CLI 只能糟糕地重新发明的认证流程。

你是一个托管服务。本来就没有二进制文件需要安装。

删除它——或者大幅缩减——当：

你的消费者是已经有终端的编程智能体

你的 MCP Server 只是你自己的 CLI 或公共 API 的薄包装

你有超过约 20 个工具且没有渐进式披露

你的工具最常见的用途是被链式调用

中间路径（大多数团队实际上应该做的）

你不必二选一。正在胜出的模式是：

保持 MCP 精简。三个或四个工具——搜索、获取、执行——而不是四十个。

其余的以代码而非 Schema 的形式暴露。让智能体从沙箱中发现并调用你的 API，而不是预先加载每个定义。150k→2k 的数字就是这么来的。

也发布 CLI。它通常只需要在你已有的 API 之上花一天功夫，终端智能体会自己偏好它，无需告知。

默认返回小结果。--json 加一个摘要字段，完整数据放在参数或文件路径后面。

用这些问题审视你自己的 Server：

我的工具定义有多少 token？（数一数。真的数一数。）

我的 p50 结果大小是多少？p99 呢？

我的两个工具在干同样的事吗？

如果今天删掉这个 Server，一个能干的智能体能用 curl 和我的文档做到吗？

如果最后一个问题答案是"是"且你的用户有终端——你为毫无意义的东西付着协议租金。

MCP 的优势从来不是更快。它是让你的产品可以从没有 shell 的界面触达。就为这个用它，然后在它不产生价值的地方停止为此付费。