MCP 工具数量爆炸后，如何高效做 Tool Selection？

MCP 工具数量爆炸后如何高效做 Tool Selection背景规模扩展带来的路由难题在 MCPModel Context Protocol架构中随着接入工具数量的增长一个问题会越来越突出LLM 开始选错工具。典型的场景是这样的你从 5 个工具扩展到 25早期还好路由基本准确。但随着工具数量继续增加特别是出现语义相近但实现不同的工具时误路由开始频繁出现。一个常见的应对方案是 RAG LLM 两阶段用 RAG 对工具描述做语义检索取 Top 5 候选让 LLM 从候选中选最终工具这个方案初期有效但扩展性有限——工具继续增长后混乱依然会回来。那么真正可扩展的 Tool Selection 策略是什么策略一两阶段精简描述法推荐这是目前社区中反馈最实用的方案思路简单清晰第一阶段粗筛给 LLM 提供所有工具的无参数 一行描述版本让 LLM 基于这个轻量信息快速过滤输出候选工具列表第二阶段精调对被初步选中的工具再提供完整定义和参数说明LLM 基于完整信息做最终决策精确调用用户输入 ↓ [第一阶段] 全量工具 × 一行描述 → LLM 粗筛 → 候选 2-3 个 ↓ [第二阶段] 候选工具 × 完整定义 → LLM 精调 → 最终调用优点减少 LLM 在第一阶段消耗的 token同时保留精确调用的能力。注意过度设计这种流程在工具继续扩展时仍有局限需要配合描述质量的持续维护。策略二渐进式工具披露Progressive Tool DisclosureMCP 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——适合任务流程固定、对稳定性要求高的场景工具越多越需要让每一步的选择空间尽可能小。