MCP 工具数量爆炸后，如何高效做 Tool Selection？
MCP 工具数量爆炸后，如何高效做 Tool Selection？
背景：规模扩展带来的路由难题
在 MCP（Model Context Protocol）架构中，随着接入工具数量的增长，一个问题会越来越突出：LLM 开始选错工具。
典型的场景是这样的：你从 5 个工具扩展到 25+，早期还好，路由基本准确。但随着工具数量继续增加，特别是出现语义相近但实现不同的工具时，误路由开始频繁出现。
一个常见的应对方案是 RAG + LLM 两阶段：
- 用 RAG 对工具描述做语义检索，取 Top 5 候选
- 让 LLM 从候选中选最终工具
这个方案初期有效，但扩展性有限——工具继续增长后，混乱依然会回来。
那么，真正可扩展的 Tool Selection 策略是什么？
策略一：两阶段精简描述法（推荐）
这是目前社区中反馈最实用的方案，思路简单清晰：
第一阶段：粗筛
- 给 LLM 提供所有工具的无参数 + 一行描述版本
- 让 LLM 基于这个轻量信息快速过滤，输出候选工具列表
第二阶段：精调
- 对被初步选中的工具，再提供完整定义和参数说明
- LLM 基于完整信息做最终决策，精确调用
用户输入 ↓ [第一阶段] 全量工具 × 一行描述 → LLM 粗筛 → 候选 2-3 个 ↓ [第二阶段] 候选工具 × 完整定义 → LLM 精调 → 最终调用优点：减少 LLM 在第一阶段消耗的 token，同时保留精确调用的能力。
注意：过度设计这种流程在工具继续扩展时仍有局限，需要配合描述质量的持续维护。
策略二：渐进式工具披露（Progressive Tool Disclosure）
MCP SDK 现已原生支持这个模式：不要一次把所有工具都暴露给 LLM，按需动态披露。
核心思路：
- 根据当前任务上下文，只暴露与当前步骤相关的工具子集
- 随着对话推进，逐步解锁更多工具
- 避免 LLM 在无关工具中"迷路"
这个方案的本质是上下文收窄：给模型看到的选项越少，它出错的概率越低。
策略三：单端点 + 逐步上下文暴露
另一种经过实践验证的架构是：只暴露一个 MCP 入口，在每一步动态传入精确的上下文和工具范围。
具体做法：
- 将整个任务拆成 step-by-step 的 workflow
- 每一步只执行一个工具调用
- 基于上一步的结果做分支判断，决定下一步的工具范围
Step 1: 只看工具 A → 执行 → 结果 ↓ Step 2: 基于结果，只看工具 B/C → 执行 → 结果 ↓ Step N: ...这个方案在 Sonnet 级别的模型上执行稳定性非常高，也适用于 Haiku 这类轻量模型。
最被忽视的优化：工具描述质量
所有技术方案的底层，都依赖一个前提：工具描述要短、准、可区分。
几个实操建议：
- 每个工具只做一件事，描述只说这件事
- 避免模糊动词：不要写"处理"、“管理”，要写"创建"、“查询”、“删除”
- 语义边界要清晰：两个功能相近的工具，描述里要明确说明区别
- 描述长度控制：一行到两行，超过三行就要考虑是不是工具职责不清
工具描述质量越低，任何路由策略的效果都会打折扣。这是最便宜、最直接的优化手段。
策略对比
| 策略 | 适用场景 | 复杂度 | 扩展性 |
|---|---|---|---|
| 两阶段精简描述法 | 工具数量 10-50+，有语义重叠 | 中 | 好 |
| 渐进式工具披露 | 任务流程清晰，上下文可预测 | 低 | 好 |
| 单端点逐步暴露 | 复杂 workflow，步骤明确 | 高 | 很好 |
| 优化工具描述 | 所有场景 | 低 | 必做 |
总结
MCP 工具路由问题的本质，是给 LLM 的选择空间太大。所有有效的策略，都在做同一件事：收窄上下文，减少无关干扰。
如果你的 MCP 项目开始出现误路由：
- 先检查工具描述——最快见效的手段
- 引入两阶段路由——适合工具数量已经较多的情况
- 考虑渐进式披露——MCP SDK 原生支持，不需要额外开发
- 拆分 workflow——适合任务流程固定、对稳定性要求高的场景
工具越多，越需要让每一步的选择空间尽可能小。