一个读者在讨论MCP和API的文章下面问了一个问题，作者当时答不上来：有没有实测过，实时发现工具的那一次往返，和提前把整理好的工具清单交给模型，token成本差多少？盈亏平衡点又在哪里？

当时作者只能从原理上推。现在这篇用数字来回答，测量工具放在配套仓库的 measure/ 目录下。

打开网易新闻 查看精彩图片

先纠正一个前提：发现那一步几乎不花钱

实时发现工具的往返成本接近于零。MCP客户端每个会话调用一次 tools/list，不是每一轮都调，返回的内容本质上就是你可以手工整理出来的那份清单。

真正花钱的地方在别处，而且更大：不管客户端最后拿到哪些工具，这些工具的定义会在每一次模型调用时被注入上下文。手工整理的清单同样要付这笔钱。

所以"发现还是清单"根本不是问题的轴。轴是：上下文里塞了多少个工具定义、这些定义写得多啰嗦、以及一个任务要调用多少次模型。

这件事不需要把大模型放进回路里就能精确测量，用分词器就行。

测量方法

测量工具把 tools 数组按它到达模型时的样子序列化——JSON格式，包含名称、描述、以及带每个参数说明的输入结构——然后统计 cl100k 分词数。

锚点是真实的：餐厅示例的三个工具，就是 Functions MCP 扩展实际提供的那三个。围绕这个锚点，工具生成了合成的企业级工具（search_invoice、approve_claim 之类，每个两到四个参数），描述分三档：精简（一个句子片段）、写实（用途加参数指引，参照示例里真实的描述写法）、啰嗦（使用指引、示例、以及每个东西的边界情况说明）。

一个诚实的提醒：不同的测量工具在重新格式化定义时会有细微差别，所以绝对数字只能算接近，相对差异才是可靠的。

数字本身

真实的三工具餐厅服务，每次模型调用消耗 277 个 token。这就是全部的常驻账单，也正是在这个规模上盈亏平衡点立刻就到——根本没有什么值得省的东西。

规模一上去，画面就变了。增长在工具数量上是线性的，大约每个工具精简档 64 token、写实档 111 token、啰嗦档 208 token。没有断崖，只有一条斜线。

描述风格本身就是一层乘数：在任何规模下，啰嗦档的成本大约是写实档的 1.9 倍，是精简档的 3.3 倍。

斜率是按任务复利，不是按会话

一百个写实档工具，每次模型调用要花 11,132 个 token。一个二十次调用的智能体任务，光工具定义就要付大约 223,000 个 token——这还没算一句对话、一个字节的工具输出。

那位读者问的整理版对照：从这一百个工具里挑出五个相关的，每次调用 542 个 token，省下 95%。

那盈亏平衡点到底在哪

像示例那样的服务，找不到平衡点，277 个 token 就是噪音。作者对这条曲线的判断是：工具数量低于大约十个，什么都别做。

再往上，省下来的钱才开始变得值得动手整理。而决定这条线位置的，不只是工具个数，还有你写描述时的手有多松。