给AI装了30个MCP工具，它反而不会用了——实测工具数量的甜蜜点

MCP 生态越来越繁荣我一口气装了 30 个工具。然后发现模型开始频繁调错工具、漏调工具、甚至编造不存在的工具。做了一组对照实验找到了准确率的拐点。从 3 个工具到 30 个工具两周前我写了一个 SQLite 查询的 MCP Server3 个工具用着很顺。后来看到社区里各种 MCP Server 越来越多——文件操作的、GitHub 的、搜索引擎的、浏览器自动化的、Docker 管理的——手痒一口气装了一堆。到第 30 个工具的时候问题出现了。我问 Claude Code“帮我搜一下最近的 AI 安全论文。” 它没有调web_search工具而是调了query我的数据库查询工具在本地 SQLite 里搜 “AI 安全”——当然什么都搜不到。我又试“帮我看看 Docker 容器的状态。” 它调了list_files文件列表工具去/var/lib/docker/目录下列文件。这两次调用在技术上都不算错——模型选了一个它认为可能相关的工具。但它选的不是最合适的那个明明有专门的工具可用。我开始怀疑是不是工具太多了实验设计为了搞清楚工具数量和调用准确率的关系我设计了一个控制变量实验。测试集准备了 40 个固定的测试任务覆盖 8 个类别类别任务示例数量数据库查询“最近注册了多少用户”5文件操作“读取 config.json 的内容”5Web 搜索“搜一下 React 19 的新特性”5Git 操作“最近 5 条提交记录”5Shell 命令“查看磁盘使用率”5HTTP 请求“调用这个 API 获取数据”5代码分析“这个函数有什么性能问题”5文档生成“给这段代码写个 README”5每个任务都有一个明确的正确工具。比如搜一下 React 19 新特性的正确工具是web_search不是query也不是read_file。实验变量逐步增加可用工具的数量从 5 个到 30 个。每组测试跑 40 个任务记录工具选择准确率模型是否选了正确的工具首次命中率第一次就选对了不需要重试幻觉率模型尝试调用不存在的工具平均延迟从收到任务到开始执行工具的时间每组测试跑 3 次取平均消除随机性。模型用的 DeepSeek V4temperature 0.3。工具分组组别工具数包含的工具A5数据库查询、文件读写、Shell 基础B10A Web 搜索、Git、HTTPC15B 代码分析、Docker、日志D20C 邮件、日历、笔记、截图、PDFE25D 翻译、天气、计算器、图片生成、OCRF30E 数据库管理(DDL)、CI/CD、监控、K8s、消息队列实验结果工具数: 5 10 15 20 25 30 准确率: 95% 91% 84% 72% 61% 53%完整数据工具数选择准确率首次命中率幻觉率平均延迟595.0%93.3%0%1.2s1091.7%88.3%0.8%1.5s1584.2%76.7%2.5%2.1s2071.7%60.0%5.8%2.8s2560.8%48.3%9.2%3.4s3053.3%40.0%12.5%4.1s几个关键发现1. 拐点在 12-15 个工具之间。10 个工具时准确率还有 91.7%到 15 个掉到 84.2%——绝对值看下降不大但看首次命中率从 88.3% 掉到 76.7%意味着每 4 次调用就有 1 次需要重试。2. 幻觉率随工具数量指数增长。10 个工具时幻觉率不到 1%到 30 个工具飙到 12.5%。模型开始编造工具名称比如调一个不存在的analyze_code_security实际只有analyze_code。3. 延迟线性增长。每多 5 个工具延迟增加约 0.5-0.7 秒。30 个工具时延迟是 5 个工具时的 3.4 倍。这个很好理解——工具描述占用了更多上下文模型要花更多时间决策。为什么会这样翻了一些 Tool Use 相关的论文结合实验数据我认为有三个原因原因一工具描述的语义重叠当工具数量增加不同工具的描述会出现语义重叠。比如web_search“搜索互联网上的信息”query“查询数据中的信息”read_file“读取文件中的内容”三个工具都能查找信息。模型在面对帮我找一下 XXX时三个工具的匹配分数可能很接近选择就变得不确定。我做了一个验证手动改写工具描述让它们更加互斥——// 之前模糊描述server.tool(web_search,搜索信息,...)server.tool(query,查询数据,...)// 之后精确且互斥server.tool(web_search,在互联网上搜索公开网页适用于查找技术文档、新闻、开源项目,...)server.tool(query,在本地 SQLite 数据库中执行 SQL 查询只适用于查询 users/orders/payments 表,...)改完之后20 个工具的准确率从 71.7% 提升到了79.2%——提升了 7.5 个百分点光靠改描述。原因二上下文预算被工具描述吃掉了每个工具的描述名称 参数 schema 说明文字大约占 100-300 token。30 个工具的描述加起来就是 3000-9000 token。这些 token 是每次调用都会发送的因为模型需要知道有哪些工具可用。它们挤占了真正有用的上下文用户消息、历史对话、系统提示的空间。30 个工具的上下文构成 工具描述: ~6000 token (35-40%) ← 固定开销 系统提示: ~1000 token (6%) 历史对话: ~3000 token (18%) 当前消息: ~500 token (3%) 模型思考输出空间: ~6000 token (35%)35-40% 的上下文被工具描述占掉了。模型的思考空间被压缩。原因三决策树过深5 个工具时模型的决策是五选一。30 个工具时是三十选一。认知科学里有个希克定律——选项越多决策时间越长错误率越高。大模型也不例外。最佳实践怎么管理工具数量方案一分组——多个小 MCP Server 替代一个大的不要把 30 个工具塞进一个 MCP Server。按领域拆成 3-4 个 Server每个 8-12 个工具{mcpServers:{dev-tools:{command:node,args:[dev-tools-mcp/index.js]// 包含git, shell, code_analyze, docker (8个工具)},data-tools:{command:node,args:[data-tools-mcp/index.js]// 包含sqlite_query, http_request, csv_parse (6个工具)},search-tools:{command:node,args:[search-tools-mcp/index.js]// 包含web_search, doc_search, file_search (5个工具)}}}每个 Server 的工具在语义上内聚——开发相关的放一起数据相关的放一起。模型的决策变成先选哪个领域再选哪个工具两次五选一比一次三十选一容易得多。实测拆成 3 个 Server总工具数不变后20 个工具的准确率从 71.7% 提升到83.5%。方案二工具描述要互斥不要重叠上面已经展示了效果。补充几条写描述的原则// 1. 说清楚只适用于什么不只说能做什么在本地 SQLite 数据库中执行 SQL 查询只适用于查询本地业务数据// 2. 说清楚不适用于什么搜索互联网公开信息。不能用于查询本地数据库或文件系统// 3. 给具体的例子适用场景查找技术文档、搜索开源项目、获取新闻资讯方案三动态加载——按需注册工具不需要一次把所有工具都注册上。可以根据对话上下文动态加载// 根据用户消息的关键词动态决定加载哪些工具functionselectToolsForContext(userMessage:string):string[]{consttoolGroups{data:[query,csv_parse,http_request],dev:[git_log,shell_exec,code_analyze],search:[web_search,doc_search],ops:[docker_ps,k8s_pods,monitor_metrics],};constkeywords{data:[数据,查询,SQL,表,统计],dev:[代码,提交,git,分析,运行],search:[搜索,查找,论文,文档],ops:[容器,部署,监控,服务],};constmatchednewSetstring();for(const[group,words]ofObject.entries(keywords)){if(words.some(wuserMessage.includes(w))){toolGroups[group].forEach(tmatched.add(t));}}// 兜底如果没匹配到加载基础工具if(matched.size0){return[web_search,query,read_file];}return[...matched];}这样每次对话实际可见的工具只有 5-8 个准确率保持在 90% 的区间。不同模型的差异补充测了两个模型20 个工具场景模型选择准确率幻觉率延迟DeepSeek V471.7%5.8%2.8sQwen3.5-Plus68.3%7.5%3.2sClaude Sonnet78.3%3.3%2.3sClaude Sonnet 在 Tool Use 上明显更强——准确率高 6-10 个百分点幻觉率低一半。如果你的 Agent 工具多且复杂模型选型很重要。当然不同模型擅长不同场景。如果你同时用多个模型可以通过 API 网关做统一路由——复杂的工具调用走 Tool Use 能力强的模型简单的问答走轻量模型。一个 Key 搞定按需切换。总结工具数量体感建议1-8很准基本不出错理想状态9-12偶尔选错可接受甜蜜点13-18经常需要重试该拆分了19-25幻觉开始出现必须拆分25基本不可用严重过载一句话结论单个 MCP Server 的工具数量控制在 12 个以内。超过了就拆分成多个专用 Server并且把工具描述写得互斥、精确。多不等于好。工具越多模型的决策负担越重出错概率越高。这个道理跟人一样——桌上放 5 个按钮你能分清放 30 个你也会按错。TheRouter — 多模型 API 网关一个 Key 调 30 模型。不同 Agent 可以路由到 Tool Use 能力最强的模型提升工具调用准确率。