RAG系统接MCP工具后反而变笨了，有人遇到同样问题吗？

我这边也踩过类似的坑，MCP把简单查询拆成多步工具调用后，反而放大了模型在任务分解上的不稳定。现在我的做法是给工具加了个“直接回答”的优先级提示，并在描述里写清楚“仅当用户明确提及XX时再调用”，不然就让模型先走普通检索。另外，上下文一旦超过三轮工具调用，确实容易丢东西，我会在系统提示里强制要求模型每轮先总结当前已知信息再决定下一步。

我们踩过一模一样的坑，后来发现关键在工具描述上。MCP工具如果把“什么时候该用我”写得太宽泛，模型就会见缝插针地调，简单query也给你走一遍流程。我现在的做法是给每个工具加一句明确的负向说明，比如“仅当问题涉及多跳或聚合时才调用”，绕路明显少了。另外路由层可以做个轻量分类，先判断问题复杂度再决定给不给工具，别一股脑全塞进上下文里。

工具别全塞给模型，简单问题直接走原检索，复杂查询再让它调MCP，不然纯属自找麻烦。

这个坑我们也踩过，后来发现关键是模型分不清啥时候该直接检索、啥时候该调工具，默认就爱走工具那条路。我们试过在系统提示里写死优先级，简单事实类问题强制走RAG，只有涉及聚合统计或者实时数据才允许调MCP，效果好了不少。另外工具描述别写太细，参数一多模型反而容易选错，精简到两三个核心参数就够。你们可以先用规则路由兜底，别一上来全交给模型自己判断。

工具描述写太细反而让模型纠结，不如加个路由先判断该不该调工具。

这问题太真实了，我上周刚踩过一模一样的坑。后来把工具描述从“查询数据库”改写成“仅当问题涉及具体数值或时间范围时才调用”，路由准确率一下上来了。另外别让模型自己决定要不要走工具，简单意图先用小分类器拦一道，能省掉好多无谓的来回。MCP本身没问题，问题是把决策权全甩给模型了。

RAG不适合硬套MCP，工具描述太细反而让模型过度决策，不如先路由再决定是否调工具。

我们之前也踩过这个坑，后来把工具描述写得更“死”了一点，明确告诉模型什么情况下只能走检索、不准调工具，绕路情况少了很多。MCP不是不能用，但得先判断问题类型，简单事实类直接锁死检索路径，复杂多跳的再放开工具。你可以在系统提示里加个轻量路由，别让模型自己瞎选。

我们也踩过这坑，后来发现关键是工具描述写太细反而让模型过度思考。简单问题其实不该给太多工具选项，得加个前置判断：能直接检索就别调工具。另外工具返回值要精简，元数据全塞回去上下文直接爆炸。

我们之前也踩过这个坑，后来发现核心问题是工具描述写得太“全”了，模型一看能查元数据、能过滤，就忍不住多走几步。后来把简单查询场景的路由收窄，只在问题明确需要多源聚合时才放MCP，效果就正常多了。另外工具返回别塞太多字段，上下文一膨胀模型就开始丢重点。你们现在工具调用是模型自己决策，还是前面加了一层轻量意图判断？

我也踩过这个坑，感觉就是工具给太多了，模型反而不知道怎么选。后来我把工具描述写得更“窄”一点，明确啥时候该用、啥时候别用，还加了个简单的路由判断，简单query直接走检索，复杂才走工具，效果好了不少。MCP不是不能用，但得让模型知道“偷懒”也是对的，不然它老想秀操作。

这个思路不错，收藏了。

我之前也遇到过类似问题，后来换了方案。

学到了，感谢分享！