名称与描述就是全部可发现性界面——模型用不了它找不到的工具。
在一个工具被正确调用之前，它得先被正确选中，而选择纯粹发生在名称、描述、以及模式里那些范例上，并且是对着每一个竞争同一个位置的其他工具来读的。一个工程上完美却名字含糊的工具是隐形的；一个精确的名字加一段说清「究竟何时该取用它」的描述，就是一个能找到对的能力的智能体与一个乱抓的智能体之间的区别。本文讲的是这个发现界面，以及那个正在全生态拖垮它的「工具太多」问题。
工具选择是一个模型仅凭文本求解的检索问题。
面对一个任务和一份工具列表，模型在做检索：把意图对着描述匹配。它没有遥测、没有使用统计、也没有「便宜地试一个看看」的能力——它只从字里行间挑。这意味着名称与描述不是元数据，它们就是索引。如果两个工具的描述近乎同义，模型就会混淆它们；如果一段描述说了工具做什么却从不说何时用它，模型就分不清眼前这个任务是不是那个。写描述要对着列表其余部分去消除歧义，而不是孤立地写。
名称承载了大部分选择信号——把它花好。
名称被最先读到、权重也最重。好的工具名说清动作与对象，并与邻居区分开：refund_order 胜过 process；search_customers 胜过 lookup。当一个系统有很多工具时，按服务与资源做命名空间，是单一最有效的消歧器——Anthropic 的指南明确推荐用 asana_search 对 jira_search、以及 asana_projects_search 对 asana_users_search 这样的前缀，因为共享前缀在模型读描述之前，就告诉了它身处哪个家族。
# Unnamespaced: model confuses which 'search' is which search(q) lookup(q) find(q) query(q) # Namespaced by service + resource: selection is obvious asana_projects_search(q) asana_users_search(q) jira_issues_search(q)
描述必须说清何时用它，也说清何时不用。
最常见的描述缺陷，是说完能力就打住。模型需要边界：「用它来给一个已完成的订单退款。不要用于取消一个尚未发货的订单——那种情况用 cancel_order。」否定的那一半，正是阻止自信地选错的东西。一段只说它做什么的描述，是一个会在它从未被设计去处理的相邻情形里被调用的工具。
给每一个可能与邻居被混淆的工具，加上一句「何时用……何时不用」。这一句话对选择准确率的提升，胜过任何关于工具内部的细节。
一个具体范例胜过一段散文。
模型做模式匹配。描述里一个完整的调用范例——「示例：要给订单 8f3a 因缺陷退款，传 order_id="order_8f3a", reason="defective"」——比抽象解释参数的三句话更能产出正确调用，因为它展示了形状，而不是描述形状。范例也是你编码非显然之物的地方：单位、ID 格式、那个属于常见情形的唯一组合。把描述预算先花在范例上，再花在解释上。
工具太多会摧毁可发现性——这如今是测出来的，不是理论。
每个工具的描述都摆在上下文窗口里争夺选择，所以发现界面会随规模退化。2025–2026 的证据很具体：正确工具选择的准确率被测出从聚焦工具集的约 95% 跌到加载完整 GitHub MCP 服务器后的约 71%，而一套标准 MCP 栈在工作开始前就吃掉 20% 以上的上下文。奏效的修法是策展与加载纪律：GitHub Copilot 从 40 个工具减到 13 个、Block 从 30 多个减到 2 个，以及 Anthropic 在 2025 年末的延迟工具加载，让模型按需发现工具，而非全程背着所有工具。可发现性与库存量成反比。
在大约十几个工具之后，再加一个工具「来帮模型」往往会损害每一次选择，包括与新工具无关的任务，因为它稀释了索引、并烧掉每次调用都要读的上下文。工具更多是可发现性成本，不是免费的能力增益。
何时打磨文档不是瓶颈。
描述质量有上限：没有任何措辞能拯救一个形状就错了（K1–K3）、或根本就不该出现在列表里（K2）的工具。如果描述已经清楚说了何时用、何时不用，智能体还在错选，问题就是重叠工具太多或粒度边界划错了——修库存，别修文案。