技术 · 熟练
工具接得越多，它怎么反而挑不对了？
不是模型变笨，是候选之间的差别被挤没了
工具选择准确率不是随数量线性下降的 —— 它更像一道断崖：目录从十几个涨到几十个的过程中，公开口径里的准确率会从四成多掉到一成多，而官方内部指引把「显著退化」标在 30~50 个工具之后。这一页给的是四步「工具目录体检」：先把可被选择的函数数清楚（不是数你接了几个应用），再把「同一件事有好几个工具都能做」的那批挑出来，然后按这次任务用得上哪些分组暴露，最后给目录设一条上限并定期复检。关键动作只有一个：把「一次全给」改成「按任务给」。
方法 · 一图看懂
1
数总数 — 数的是可被模型选择的函数个数（tools/list 的输出行数），不是接了几个应用
2
找重复能力 — 把「读文件 / 发请求 / 搜索」这几类里都能做的挑出来，它们才是误选的主力
3
按任务分组 — 按「这次任务用得上」分，⛔ 不按来源分（同一家 server 的工具也会互相干扰）
4
只暴露入口 — 先给名字 + 一句触发条件，正文与详细定义等命中再给（渐进式发现）
5
设上限并复检 — 目录过 30 就提示、过 50 就警觉；每次加工具都重跑一遍第 2 步
原理 · 为什么有效
让模型从一长串里挑一个，坏掉的地方不在「它读不懂说明」，而在候选之间的语义距离被挤没了：四十个工具里总有五六个都能「读写文件」「发个请求」，名字再清楚也挡不住长得像；更要紧的是挑错的代价远高于漏挑 —— 漏挑最多是不用，挑错会走一条看着成功的错路，你还得回头查。所以省 token 只是副产品，真正被治的是误选率：把候选按任务收窄之后，同一个任务要付的定义量能降到原来的约百分之一量级（公开口径里有个参考实现是 150000 降到约 2000 token），而准确率的回升比省下的钱更值。
适用场景
适用：手上接了三个以上 MCP server、或自己写了十几个可调用工具的人；出现过「该用 A 时它用了 B」；上下文里工具定义占了很长一截。
⛔ 不适用：只有两三个固定工具的场合 —— 分层与渐进本身也要维护成本，两三条直接写死更省事。
⚠️ 前提：你能拿到一份完整的「可被选择」清单，而不是靠印象估。
自测 · 5 问
我能说出此刻「可被模型选择」的工具一共几个吗（不是接了几个应用）
上一回它挑错工具，是「该用的没被描述清楚」，还是「不该用的描述太宽」
工具定义现在是一次全给，还是按当前任务给
同一件事（读文件 / 发请求 / 搜索）我有几个工具都能做
我最近一次整理工具目录，是什么时候
怎么上手 · 验证步骤
第一次别做全量重构。只做两步：第一步把当前 tools/list 的输出（或你自写工具的注册清单）打印出来，数总数，并按「这件事还有谁能做」把重复能力的挑出来列成一张小表；第二步只改最像的那一对 —— 把其中描述更宽的那个收紧，或干脆从这一轮的暴露清单里拿掉。隔一天再用同一个任务试一次，看它选的是不是变了。变了 ⇒ 方向对了；没变 ⇒ 问题多半不在描述宽度，而在两个工具的能力确实重叠，得考虑合并而不是改文案。
自检动作：随便点一个工具，不看它的说明回答两个问题 —— ① 什么时候该用它 ② 什么时候不该用它。第二个答不上来的那个，就是它会被误用的原因。