技术 · 熟练
工具装得越多，它反而越不会用？
描述是常驻预算，不是免费的前言
你接的每一个工具，它的名字、参数、说明都会在每轮对话开始前被送进上下文 —— 那不是「装的时候占一次」，是「每一轮都占」。所以一件事会反过来：工具越多，模型能分给任务的注意力越少，选错工具的几率越高。这一页做的是给工具描述做一次预算核算——先量你现在被吃掉了多少，再决定哪些描述该精简、哪些该改成「用到才加载」，哪些干脆不该接。一句话：工具描述是常驻成本，核它的单位不是「接了几个」，是「每轮吃掉多少字」。
方法 · 一图看懂
1
先量总量 — 把所有工具的描述字数加起来，看它占了多少前置预算
2
再分两类 — 每轮都要用的（留前置）· 少数时候才用的（改成按需加载）
3
精简写法 — 参数说明压到最短，把长例子挪出描述、放进你自己的说明文档
4
设两条红线 — 单条消息的体量上限、单条描述的长度上限，写进团队的接入规范
原理 · 为什么有效
模型选工具，靠的是描述文本本身 —— 它没有别的信息源。于是出现一个反直觉的结构：工具描述既是说明书、也是广告位，而它们的总量有天花板。旧口径下前置描述与服务器指令的默认上限是 2,048 字符，新口径提到 4,096；通过工具检索按需加载的那一路，单条描述截断上限 16,384 字符。这三个数字连起来读，含义很清楚：「前置」是稀缺位，「按需」是宽位。所以正确的动作不是「把描述写得更详细」，而是先把工具分流 —— 每轮都得用的留在前置，偶尔用的挪到按需那一侧，前置位才腾得出来。
适用场景
适合：自己写 MCP server 或给 agent 配工具的人 · 接了三五个以上外部工具、发现模型开始「选错工具」或「忘了用工具」的人 · 要给团队定一份「工具接入规范」的人。
自测 · 5 问
我把所有工具的描述字数加过了吗？占了多少前置预算？
这些工具里，有几个是「每轮都会用到」的？其余的是不是都在白占前置位？
有没有哪条描述长到被截断过？（截断之后模型看到的是半句话）
我设了单条消息体量上限吗？（超了不是报错，是连接直接断）
描述里是不是塞了本该放在我自己文档里的长例子？
怎么上手 · 验证步骤
最省事的第一步：把你现在的工具清单拉出来，给每个工具标一个「这周用过几次」。一周用不到一次的那些，先把它们的描述砍到一句话（做什么 + 什么时候用），参数说明只留必填项。然后找一条真实任务跑一遍 —— 如果模型仍然选对工具，说明你省下的前置预算确实是白花的。
改完描述之后做三件核对：① 拿一条「需要用到冷门工具」的任务跑一遍，看它还能不能找到那个工具（找不到 ⇒ 砍过头了，把触发词补回去）② 拿一条「不需要任何工具」的任务跑一遍，看它会不会硬调一个（会 ⇒ 描述里的触发词太宽）③ 把改动记一行（改了哪条 / 省了多少字 / 哪一轮验证的）—— 描述预算是会慢慢长回来的，没有记录就没有约束。