MCP 接入 RAG 后工具调用总失败，是我姿势不对吗？

这个坑我踩过，问题多半出在编排上而不是 MCP 本身。工具调用和检索是两套决策路径，模型很容易二选一，你得在 prompt 里明确写死“必须先检索再调工具”，或者干脆用代码把流程串起来，别指望模型自己规划。另外工具 schema 里最好加个字段接收检索结果，不然模型确实容易忘。我现在是检索完直接把上下文塞进工具参数模板里，稳很多。

这个坑我踩过，大概率不是 prompt 的问题，而是工具 schema 里没把检索结果作为显式依赖传进去。模型跳过检索是因为工具描述看起来自己能搞定，它自然就懒得先查知识库。我现在做法是把检索单独包成一个 tool，然后让目标工具的入参里强制带上 retrieval_id 这类字段，逼着链路按顺序走。你也可以试试在 system prompt 里写死调用顺序，但更靠谱的还是靠 schema 约束。

这问题太常见了，我当初也卡了好久。核心其实不在 prompt，而是模型压根分不清「先检索后调工具」这个顺序依赖，tool schema 里没把检索结果设成前置依赖，它自然就乱来。我的做法是在 system prompt 里硬性规定两步走，再给工具加个必填的 context 参数，逼它把检索内容塞进去。另外你可以试试把检索直接封成一个 tool，让模型自己决定啥时候调，反而比硬编排稳。

这坑我踩过，大概率不是 prompt 的锅，而是 tool 描述里没把检索结果和工具参数的依赖关系讲清楚。模型很容易把 RAG 和 tool call 当成两条平级的路，谁先谁后它自己随机选。我的做法是把检索包成一个工具，让工具调用链强制串行，schema 里明确写参数来自上一步的输出。另外 system prompt 里最好给个固定流程，别让模型自由发挥顺序。

我都是把检索结果塞进 tool 的 description 里当上下文，模型就老实多了，你可以试试。

这个坑我踩过，问题大概率不在 MCP 的 schema，而是模型根本没被约束成“先检索再调工具”的执行顺序。MCP 本质上是把工具暴露给模型，它不负责编排流程，所以你不能指望模型自己悟出 RAG 和 tool 的先后关系。我的做法是把检索也包装成一个 MCP tool，比如 search_knowledge，然后在 system prompt 里明确写“回答任何事实性问题前必须先调用 search_knowledge，再根据返回结果决定是否调用其他工具”。这样模型看到的是一条统一的工具链，而不是两套并行逻辑，跳过检索的概率会低很多。至于检索结果带不进工具参数，通常是 tool schema 里参数描述太模糊，模型不知道该把哪段塞进去，可以在参数 description 里写清楚“这里填 search_knowledge 返回的 content 字段”。另外建议在服务端加一层校验，如果工具调用缺少检索来源就直接拒绝，逼模型回退重试，比纯靠 prompt 稳。

试试把检索结果作为工具调用的前置依赖写进schema，光靠prompt模型确实容易漏。

这坑我熟，本质是模型分不清什么时候该检索、什么时候该调工具，光靠prompt很难卡准。我的做法是把检索也包装成一个tool，让模型自己决定先调哪个，同时在工具参数里留个字段接收检索结果，schema上强绑定。另外MCP那边最好加个中间层做编排，别指望模型一次想清楚两步。你可以在system prompt里明确写清依赖顺序，但更稳的还是用状态机控制流程。

我之前也踩过这个坑，感觉问题不在 MCP 本身，而是模型分不清“什么时候必须检索、什么时候可以直接调工具”。我的做法是把检索也包装成一个 MCP tool，让模型统一走 tool call 流程，而不是在 prompt 里靠自然语言暗示它先查再调。另外工具参数里最好显式留一个 evidence 或 context 字段，强制它把检索结果填进去，不然模型很容易丢。

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

刚入门，这个对我帮助很大。

这坑我踩过，大概率不是 schema 的问题，是模型压根没把“先检索”当成硬约束。你试试把检索做成 tool 而不是前置步骤，让模型自己决定调 retrieval 再调业务工具，链路反而稳定很多。另外工具参数里别让它“记得”带检索结果，直接在 server 端做上下文注入或者用引用 id 传递，比靠 prompt 提醒靠谱。