你的 AI 编程助手每天偷偷烧掉多少 Token？MCP 的隐藏成本

如果你在用 Claude Code、Cursor 或者任何接了 MCP Server 的 AI 编程工具，我有一个坏消息：

你可能有一半以上的 Token 花在了你根本不知道的地方。

这不是夸张。Hacker News 上一个叫 mcp2cli^[1] 的开源项目（146 赞 / 101 条评论）用数据揭示了这个问题——并且给出了一个省 96-99% Token 的解决方案。

MCP 的 Token 黑洞：一笔你从没注意过的账单

先说结论，再解释原因。

假设你接了 4 个 MCP Server，每个提供 30 个工具，总共 120 个工具。一次普通的编程对话大约 25 轮。

36 万 tokens。 仅仅是工具描述。你一个字都没打，AI 一行代码都没写，光是”告诉 AI 有哪些工具可用”就烧掉了 36 万 tokens。

按 Claude Sonnet 的价格算（$3/M input tokens），这一次对话光 schema 就花了 $1.08。一天 10 次对话就是 324。

而你实际用到的工具可能只有 3-5 个。

为什么会这样？MCP 的”全量广播”机制

问题出在 MCP 协议的设计上。

当你在 Claude Code 里配置了一个 MCP Server，每一轮对话时，客户端都会把所有已注册工具的完整 JSON Schema 注入到系统提示词中。这包括：

• 工具名称
• 工具描述
• 每个参数的名称、类型、描述
• 必填/可选标记
• 嵌套对象的完整结构

每一轮都注入。不管你用不用。

这就像你每次去餐厅吃饭，服务员都要把整本菜单从头到尾念一遍——包括你永远不会点的 200 道菜。而且每上一道菜，都要重新念一遍。

为什么 MCP 要这么设计？因为 LLM 是无状态的。每一轮对话，模型都需要知道”我现在能用哪些工具”。MCP 选择了最简单粗暴的方式：全量广播。

简单？是的。便宜？绝对不是。

mcp2cli 的思路：别广播，按需查询

mcp2cli^[2] 的作者 Stephan Fitzpatrick 提出了一个优雅的替代方案：

把 MCP Server 变成 CLI 工具。

原理很简单：

MCP 模式（每轮）：  系统提示词 = 基础指令 + 120个工具的完整schema（14,400 tokens）  → AI 从 120 个工具中选一个调用CLI 模式（按需）：  系统提示词 = 基础指令（~200 tokens）  → AI 需要工具时，运行 mcp2cli --list（~20 tokens，仅名称）  → 找到目标工具后，运行 mcp2cli tool-name --help（~50 tokens）  → 调用具体工具

从”每轮 14,400 tokens”变成”需要时才花 70 tokens”。 这就是 96-99% 节省的来源。

关键洞察是：LLM 不需要在每一轮都知道所有工具的存在。 它只需要在需要工具时能找到工具就行。这和人类使用命令行的方式完全一致——你不会把 man 手册背下来，你会在需要时 --help。

实际怎么用

安装很简单：

# 直接运行，不需要安装uvx mcp2cli --help# 或者全局安装uv tool install mcp2cli

三种使用模式：

1. 连接 MCP Server

# 列出所有工具mcp2cli --mcp https://your-mcp-server.com/sse --list# 调用某个工具mcp2cli --mcp https://your-mcp-server.com/sse search --query "test"# stdio 模式（本地 MCP Server）mcp2cli --mcp-stdio "npx @modelcontextprotocol/server-filesystem /tmp" --list

2. 连接 OpenAPI

# 直接用 OpenAPI specmcp2cli --spec https://api.example.com/openapi.json --listmcp2cli --spec ./openapi.json --base-url https://api.example.com list-pets

3. 连接 GraphQL

mcp2cli --graphql https://api.example.com/graphql --listmcp2cli --graphql https://api.example.com/graphql users --limit 10

一个 CLI 统一了 MCP、OpenAPI、GraphQL 三种协议。 这意味着你不需要为每个 API 写一个 MCP Server——直接指向 spec 就能用。

进阶：Bake 和智能排序

mcp2cli 还有两个特别实用的功能。

Bake：把常用配置固化

# 创建一个"烘焙"好的配置mcp2cli bake create mygithub --mcp-stdio "npx @mcp/github" \  --include "search-*,list-*" --exclude "delete-*"# 以后直接用 @ 前缀调用mcp2cli @mygithub search-repos --query "rust"

不用每次都敲一长串连接参数。

智能排序：越用越省

mcp2cli 会追踪你的工具使用频率。当 AI agent 执行 --list 时，最常用的工具排在最前面。

# 96 个工具的完整列表：~1,400 tokensmcp2cli @myapi --list# 只看最常用的 10 个，仅名称：~20 tokensmcp2cli @myapi --list --top 10 --compact

从 1,400 tokens 压缩到 20 tokens。 这是在 CLI 模式基础上的二次优化。

更大的问题：MCP 协议本身需要进化

mcp2cli 是一个聪明的 workaround，但它暴露的问题值得整个 MCP 生态思考。

问题 1：全量注入是设计缺陷

MCP 协议目前没有”按需发现”的机制。每个 Server 注册后，所有工具的 schema 都会被无条件注入。这在工具数量少的时候不是问题，但当生态繁荣起来——一个开发者可能接 10 个 Server、200 个工具——token 成本就会失控。

问题 2：没有工具优先级

不是所有工具都一样重要。read_file 可能每轮都用，deploy_to_production 可能一周用一次。但 MCP 对它们一视同仁，每轮都注入完整 schema。

问题 3：Schema 太啰嗦

一个简单的”搜索文件”工具，JSON Schema 可能要 150+ tokens 来描述参数类型、可选值、嵌套结构。很多信息对 LLM 来说是冗余的——它不需要知道某个参数是 string 类型，从参数名就能推断。

HN 讨论中有人提到了 LTP（Lazy Tool Protocol）^[3]，另一个尝试解决同样问题的项目，声称能减少 93% 的 token。这说明社区已经意识到这是一个真实的痛点。

对你的实际建议

如果你是 MCP 用户

1. 审计你的工具数量。打开 Claude Code 的配置，数一下你接了多少个 MCP Server、总共多少工具。超过 50 个就该警惕了
2. 试试 mcp2cli。特别是那些你偶尔才用的 MCP Server，完全可以改成 CLI 模式按需调用
3. 用 --top 和 --compact 压缩工具列表。20 tokens vs 1,400 tokens，差距是 70 倍

如果你是 MCP Server 开发者

1. 精简工具描述。每少一个词就少几个 tokens，乘以用户数和对话轮数，节省是巨大的
2. 考虑工具分组。把低频工具放到子命令里，而不是全部平铺
3. 关注 MCP 协议的 lazy loading 提案。这可能是未来的标准方向

如果你是 AI 编程工具的开发者

这是一个产品机会。谁先在产品层面解决 token 浪费问题，谁就能在成本上建立竞争优势。 用户可能不知道自己在浪费 token，但他们知道账单太贵。

写在最后

MCP 是一个好协议。它统一了 AI 工具调用的标准，让生态可以互操作。但好协议不等于没有优化空间。

36 万 tokens 的隐藏成本，不应该是用户默默承受的代价。

mcp2cli 用一个简单的思路——”别广播，按需查询”——省掉了 96% 的浪费。这个思路不复杂，但它需要有人把问题量化出来、把解决方案做出来。

下次你看到 AI 编程工具的 token 账单时，想想：这里面有多少是真正用在写代码上的，又有多少是在反复念菜单？

参考链接：

• mcp2cli GitHub（146 pts / 101 comments on HN）^[4]
• Hacker News 讨论^[5]
• LTP — Lazy Tool Protocol（93% token reduction）^[6]

引用链接