-
提示膨胀问题：随着可用的MCP（Model Context Protocol）服务器数量增加，将所有工具描述包含在单个提示中会导致提示过长，消耗大量token，并降低模型区分和回忆正确工具的能力。这种现象类似于“针在草堆中”（Needle-in-a-Haystack, NIAH）测试，即在长上下文中检索关键信息的能力会随着上下文长度增加而显著下降。
-
MCP压力测试设计：为了量化工具选择能力随工具池大小的变化，作者设计了一个MCP压力测试。测试中，候选MCP服务器的数量从1增加到11100，每次试验中随机选择一个“真实”MCP（唯一能满足任务需求的工具）和若干干扰项（distractors）。模型需要从这些候选中选择正确的MCP并执行任务。通过改变候选工具的数量和位置，测试模型在不同工具池规模下的选择准确性和任务成功率。
RAG-MCP 框架
-
框架设计：RAG-MCP框架通过检索增强生成（RAG）技术解决提示膨胀问题。它不将所有工具描述一次性提供给LLM，而是将工具描述存储在外部向量索引中，并在查询时动态检索与用户任务最相关的工具描述。
-
工作流程：
-
检索（Retrieval）：使用轻量级LLM（如Qwen）对用户任务描述进行编码，并在MCP索引中执行语义搜索，返回与任务最相似的前k个候选工具。
-
验证（Validation）：对每个检索到的MCP，生成少量示例查询并测试其响应，以确保其基本兼容性（可选步骤）。
-
调用（Invocation）：仅将最佳MCP的描述（包括工具使用参数）注入LLM提示中，LLM随后通过函数调用接口执行任务。
-
框架优势：
-
减少提示大小：避免上下文窗口过载，即使工具库很大也能保持高效。
-
降低认知负担：LLM无需筛选数百个干扰工具，从而提高选择准确性和减少幻觉（hallucinations）。
-
资源效率：与传统MCP客户端相比，RAG-MCP仅激活选定的MCP，降低了启动成本，并支持任意大小的工具集，而无需担心基础设施瓶颈。
-
多轮对话鲁棒性：在多轮对话中，LLM无需重复包含所有MCP提示，RAG-MCP的检索器可以动态处理工具回忆，释放上下文空间用于任务特定推理。
三步流程图
-
流程图总结：RAG-MCP的操作流程分为三个核心步骤：
-
用户任务输入：用户的自然语言任务被编码并提交给检索器。
-
检索器选择和验证MCP：检索器在MCP索引中搜索，按语义相似性对候选工具进行排序，并通过合成示例测试每个工具的兼容性（可选）。
-
LLM执行任务：LLM仅接收选定MCP的描述和参数，并通过函数调用接口执行任务。
-
性能提升：RAG-MCP在工具选择的准确性上显著优于基线方法。在基准任务中，RAG-MCP的工具选择准确率达到了43.13%，而基于关键词匹配的“实际匹配”方法和直接提示所有工具的“空白条件”方法的准确率分别为18.20%和13.62%。
-
提示大小减少：RAG-MCP显著减少了提示中使用的token数量，平均为1084个token，而“空白条件”方法需要2133.84个token。
-
生成token数量：RAG-MCP的完成token数量略高于“实际匹配”方法（78.14 vs 23.60），但这种增加与更高的准确性和整体任务成功率相关。
https://arxiv.org/pdf/2505.03275RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation
（文：PaperAgent）