你有没有算过，用 MCP（Model Context Protocol）到底烧了多少 token？

答案可能比你想的夸张：如果你有 120 个工具，跑 25 轮对话，光是工具定义就要吃掉 36 万 token。

MCP 的隐形成本

问题出在哪？MCP 的设计是把所有工具的完整 schema 注入到每一轮对话的上下文里。

• 30 个工具 = 每轮 3600 token
• 120 个工具 = 每轮 14400 token
• 跑 25 轮？36 万 token 没了

不管你用不用这些工具，它们都在那儿占位置。

这就像你去餐厅点菜，服务员非要把整本菜单背给你听一遍，每次点菜都背一遍。你只想要个炒饭，但他得从头到尾念完 120 道菜。

mcp2cli：按需加载，用多少拿多少

有人受不了了，做了个工具叫 mcp2cli。

核心思路很简单：把 MCP 服务器变成 CLI，让 LLM 需要的时候再去查。

# 列出所有工具（每个工具只要 16 token）
mcp2cli --mcp https://mcp.example.com/sse --list

# 查看某个工具的帮助（120 token，只查一次）
mcp2cli --mcp https://mcp.example.com/sse create-task --help

# 直接调用
mcp2cli --mcp https://mcp.example.com/sse create-task --title "修 bug"

不需要生成代码，不需要重新编译，服务器更新了也不用管。对 LLM 来说，这就是个普通的命令行工具。

数据说话

作者用 cl100k_base tokenizer 实测了一下：

• 30 个工具，15 轮对话：节省 96%
• 120 个工具，25 轮对话：节省 99%

这不是理论值，是真实跑出来的数字。

为什么这个思路有意思？

1. 回归本质：LLM 本来就会用命令行，为什么非要把工具定义塞进上下文？
2. 按需加载：需要的时候再查，不需要的时候不占地方
3. 兼容性强：支持 MCP 服务器和 OpenAPI spec，本地文件或远程 URL 都行
4. 零侵入：不用改你的 MCP 服务器，也不用改 LLM

适合谁用？

• 工具多的场景（超过 20 个工具就值得试试）
• 长对话场景（轮次越多，省得越多）
• 在意 token 成本的团队
• 用 Claude Code、Cursor、Codex 这类 AI 编程工具的开发者

作者还做了个 skill 包，可以直接装：

npx skills add knowsuchagency/mcp2cli --skill mcp2cli

一个更大的问题

这个工具背后其实在问一个问题：我们是不是在用错误的方式集成工具？

MCP 的初衷是好的——标准化工具接口，让 LLM 能调用各种服务。但它的实现方式有点像"把整个工具箱都背在身上"，而不是"需要的时候去工具箱拿"。

mcp2cli 证明了另一条路是可行的：工具发现可以是动态的，不需要预加载所有定义。

这让我想起早期的 Web API 设计。最开始大家也是把所有接口文档都塞进客户端，后来才有了 HATEOAS（超媒体驱动的 API），让客户端按需发现资源。

也许 AI 工具调用也会走类似的路：从"全量注入"到"按需发现"。

值得一试

如果你在用 MCP，或者在做 AI agent 相关的东西，这个工具值得看看。

不一定要全面切换，但至少可以测一下你的场景能省多少 token。毕竟 token 就是钱，省下来的都是利润。

项目地址：github.com/knowsuchagency/mcp2cli

你的 MCP 工具有多少个？算过 token 成本吗？