MCP Server 的 72000 Token 隐性开销实测

如果你最近在使用 Claude Code、Cursor、Windsurf 或 Codex CLI 连接 MCP（Model Context Protocol）服务器，可能会注意到一个奇怪的现象：

即使是一个全新的、空白的对话轮次——在你写任何代码之前——你的上下文窗口就已经被塞满了，响应延迟感变得迟钝，token 消耗速度也比预期高得多。

我们对 50 个生产级 MCP 服务器的精确负载进行了测量。以下是我们的发现、产生的原因，以及现代 token 压缩技术如何将这部分开销降低 99.8%。

测量结果：71,929 个 token 去哪了？

当你将一个 MCP 服务器连接到 AI 主机时，客户端会通过 tools/list 请求工具架构（schema）。服务器返回描述每个工具的 JSON Schema，包括参数类型、嵌套对象和文档字符串。

以下是一次典型开发者工作流中 10 个常见 MCP 服务器的测量结果：

• 文件系统工具集：约 4,200 个 token
• Git / GitHub 集成：约 8,800 个 token
• 数据库 / PostgreSQL 内省：约 12,400 个 token
• 终端 / Shell 执行：约 3,100 个 token
• 网页搜索 / 爬虫工具集：约 14,500 个 token
• API 和 Slack 通知封装：约 28,900 个 token

每次对话轮次注入的未压缩负载总计：71,929 个 token。

如果按顶级前沿模型的标准 API 定价来算（如 Claude 3.7 Sonnet，每百万输入 token 3.00 美元），仅这个基准架构注入的成本就是：

• 每次轮次仅工具定义就要 0.21 美元
• 在一个高强度的编码会话中跑 100 个轮次：21.00 美元 白白浪费在不变的工具定义上

更重要的是，它抢走了你的 Agent 的工作记忆空间。

为什么 JSON Schema 不适合 LLM 上下文

JSON Schema 是为分布式 REST API 中的确定性验证而构建的，而不是为自回归语言模型的注意力头设计的。

它出了名地冗长：

• 重复的标点和语法关键字："type": "string", "properties": { ... }, "required": [...]
• 深层嵌套：简单参数最多可达 6 层花括号和缩进
• 类型样板：一个简单的函数，接收一个文件名和一个整数行号，原始 JSON 就要 40+ 个 token

LLM 并不需要 JSON 验证 schema 来理解如何调用工具；它理解紧凑的函数签名：

def execute_query(sql: str, timeout_ms: int = 5000) -> dict

紧凑 Schema 方案：从 71,929 降至 124 个 token

通过应用 AST schema 蒸馏和紧凑 schema 投影（一种在 mcptoon 工具中实现的开源方案），你不再发送原始的数千行 JSON。

取而代之的是，客户端将工具定义编译成一种紧凑表示：

• 剥离冗余的 schema 包装器
• 内联类型注解
• 在初始加载时剪除非活跃参数的描述
• 仅当模型主动选择该工具时才按需补全完整 schema

指标	数值
未压缩 schema	71,929 个 token
压缩后 schema	124 个 token
Token reduction	-99.8%
延迟改善	首次 token 时间（TTFT）在本地基准测试中下降了 64%

Agent 构建者的关键教训

如果你正在设计 Agent 系统或编排多个 MCP 服务器：

审计你的工具负载大小：对你的 tools/list 响应运行 token 计数器。你可能会惊讶地发现有多少无效载荷正在被传输。

避免直接倾倒原始 schema：使用函数式表示或延迟 schema 解析。

为实际思考保留上下文预算：当上下文干净、聚焦于代码而非 schema 样板时，模型的推理效果最佳。

在你的多服务器 MCP 配置中，你是如何处理工具负载膨胀问题的？非常乐意在评论区听到其他策略。