RAG-MCP

定义或身份

RAG-MCP 是一种面向 模型上下文协议（MCP）工具生态的 LLM工具选择 优化框架，核心用途是在可用工具很多时，帮助主 大语言模型 先缩小候选工具集合，再进行最终调用决策。

它不是新的通用大模型，也不是对 MCP 的替代协议，更不是单纯的 MCP 工具接入实现；它解决的是“当工具库持续扩张后，模型如何高效、准确地发现并选择合适工具”的问题。

其基本思想借用了 RAG 的“先检索、后生成”范式，但把传统 RAG 中检索的对象从事实性知识、文档段落、百科内容，迁移为功能性工具描述。

要解决的问题

在函数调用和 MCP 工具接入成为主流后，开发者常把所有可用工具的功能定义、参数要求和说明一并放入提示中交给 LLM。工具数量较少时这种做法尚可接受，但当工具扩展到 50、100 甚至 1000 个时，会出现两个直接问题：

• 提示词膨胀：大量工具描述会占用上下文窗口，挤压用户查询、对话历史和推理空间。
• 决策复杂度上升：即使上下文足够，模型也要在大量功能相近、差异细微的工具中比较筛选，容易选错、选次优，甚至幻想出不存在的工具或接口。

RAG-MCP 的定位就是缓解这种“工具过载”场景下的选择失真问题。

核心思想

RAG-MCP 的核心思想可以概括为一句话：检索的目标不再是知识，而是工具描述。

在这个框架里，系统不会把整套工具列表完整塞给主模型，而是先维护一个外部工具索引；收到任务后，先根据任务语义去检索最可能相关的少量工具，再把这些候选工具提供给主 LLM 继续推理和调用。

因此，RAG-MCP 的关键不是让主模型“记住全部工具”，而是让检索器先做工具发现，主模型再做最终判断与执行。

索引内容

RAG-MCP 依赖一个外部语义索引来保存可检索的工具信息。文中明确提到，可被索引的内容包括：

• MCP 函数模式（schema）
• 工具描述
• 参数需求
• 使用示例

这些内容通常会被转换为向量嵌入，存入向量数据库或其他语义检索系统中，以便后续按任务描述进行相似度搜索。

这里的重点不是仅索引工具名称，而是索引能体现工具能力边界、输入要求和使用方式的语义材料。这样检索器才能区分看似相近、但参数约束或用途不同的工具。

基本流程

RAG-MCP 的典型流程可分为三个阶段。

1. 用户查询编码

用户以自然语言提出任务，例如预订航班、搜索网页、查询数据库等。系统首先对该任务描述进行编码，生成便于检索的语义表示。

文中提到，这一步的检索器可以由轻量级 LLM 实现，例如使用 Qwen 系列模型对任务描述编码，并用于后续语义搜索。

2. 语义检索 top-k 工具

编码后的任务表示会在工具索引中执行语义检索，从全部 MCP 工具中找出相关度最高的前 k 个候选工具。

这个阶段的输入是任务语义，输出不是答案，而是经过排序的候选 MCP 工具列表。也就是说，RAG-MCP 先解决“应该看哪些工具”，而不是直接替主模型完成调用决策。

3. 可选验证

在检索到候选项后，系统可以加入一个可选验证步骤。文中提到，验证方式可以是：为排名靠前的候选 MCP 生成合成示例查询，并在最终选定前评估其兼容性与响应能力。

这个验证层的作用是过滤“语义上相似、但实际上不兼容”或“接口存在但响应不理想”的候选工具，提升最终注入给主模型的候选质量。

4. 将候选工具提供给主 LLM 执行

最后，系统只把最优的一个或前几个工具的 schema、描述和参数信息，提供给主 LLM 的函数调用上下文。

主 LLM 在显著缩小的候选空间中完成最终推理、参数填写和工具调用。这一步仍由主模型负责，因此 RAG-MCP 并不替代主模型，只是为它做前置筛选。

关键架构特点：检索器与主 LLM 解耦

RAG-MCP 最重要的架构特点，是把“工具发现”与“任务推理/执行”从系统职责上分离开来。

• 检索器负责发现：理解用户任务语义，从海量工具中找出可能相关的候选项。
• 主 LLM 负责最终推理和调用：结合任务上下文、候选工具 schema 与参数约束，决定是否调用、调用哪个、如何填写参数。

这种解耦带来几个直接好处：

• 主模型不需要一次处理全部工具信息。
• 检索模块可以独立替换、迭代或增强，而不必重训主模型。
• 新工具的加入主要变成“索引更新”问题，而不是“模型再训练”问题。

从系统设计上看，这类似于让一个专门的检索代理先完成候选集缩减，再把高质量候选交给更强的主模型做最终判断。

角色职责

在一个典型的 RAG-MCP 系统中，各部分职责大致如下：

• 工具索引层：保存工具 schema、描述、参数需求、示例等，并提供语义检索能力。
• 检索器：对用户任务做编码、相似度搜索、候选排序，必要时执行验证。
• 主 LLM：在少量候选工具中做最终推理、函数调用和结果整合。
• 工具运行环境：真正执行外部服务调用，例如搜索、数据库访问、业务 API 访问等。

因此，RAG-MCP 本质上是工具选择层，而不是工具执行层，也不是底层协议层。

关键信息与性能表现

文中给出了较明确的实验结果，说明 RAG-MCP 不只是概念设计，而是在工具选择任务上有量化收益。

提示词开销

研究数据显示，RAG-MCP 在实验中将提示词 token 减少超过 50%。

在基准比较中：

• RAG-MCP 的平均提示词 token 为 1084.00
• 朴素方法的平均提示词 token 为 2133.84

这意味着它基本把需要送入主模型的工具上下文压缩到接近一半，直接缓解了提示词膨胀。

工具选择准确率

在 MCPBench 的网络搜索子集上，文中列出的对比结果为：

• RAG-MCP：43.13%
• 关键词匹配：18.20%
• 朴素全量注入：13.62%

也就是说，RAG-MCP 的工具选择准确率相对朴素基线提升了三倍以上。

完成 token

完成 token 方面，文中给出：

• RAG-MCP：78.14
• 关键词匹配：23.60
• 朴素全量注入：162.25