把RAG接进MCP server后，召回效果反而变差了是怎么回事？

大概率是MCP把query做了截断或编码转换，试试在tool里显式传原始字符串参数，别走description。超时那块建议直接同步调用，异步回调在MCP里特别容易丢。

我之前也踩过类似的坑，查了半天发现是MCP的tool description里塞了太多示例，结果模型把示例里的关键词当成查询条件去匹配了，后来把description精简到只剩必要参数说明就正常了。超时那边建议你检查下MCP的默认timeout配置，我这边之前设了300ms，结果RAG服务那边embedding还没算完就断了，最后只能同步改成异步轮询才解决。

大概率是你MCP工具里query参数没透传，被模型按语义重写了吧，试试把description写短点强制原样传参。

遇到过类似情况，大概率是MCP那层把query里的特殊字符或者空格做了转义，导致向量化前的文本跟你单独调RAG时对不上。你可以先在MCP的handler里打个日志，对比下收到的原始参数和传给RAG的最终字符串，编码问题一眼就能看出来。另外tool description确实别写太长，Claude有时候会过度解读，把用户原话揉进去反而干扰了检索。超时那个我建议把MCP的timeout调大点，或者RAG那边改成同步模式，不然异步任务一断，召回结果就会缺胳膊少腿。

我之前也踩过类似的坑，多半不是MCP转发本身改了query，而是tool description里塞了太多示例和约束，Claude在构造工具调用参数时反而会“脑补”出一些语义，把原始query带偏了。你可以试试把description精简到只留必要说明，并且显式标注“直接透传用户输入，不要改写”。超时那个问题更常见，MCP默认超时时间短，RAG异步任务还没跑完连接就断了，建议把超时调大，或者改成同步等待加缓存结果。另外检查一下参数编码，如果走的是JSON-RPC，中文query容易被转义成unicode，某些RAG服务端解析不一致也会导致乱码。

大概率是MCP的tool schema里description干扰了query的意图提取，试试把参数描述精简到最简。超时中断也遇到过，建议把RAG调用改成同步阻塞模式。

遇到过类似的情况，我猜大概率不是MCP本身改了你的query，而是tool description和参数schema在起作用。Claude在调用tool的时候，会先把你的query和description做语义匹配，如果description里塞了太多业务术语或者示例，反而会干扰它对当前问题的理解，导致它把原始query“翻译”成它认为更符合tool语义的表述，结果就偏了。你可以试试把description精简到只讲功能，参数描述里明确写“原样传递用户输入”，看召回会不会回来。

另外你说的超时中断问题，我这边也踩过坑。MCP server默认超时时间很短，RAG如果涉及向量检索加重排，很容易超过阈值，但更隐蔽的是，超时后客户端会重试，重试时如果带了不同的request id，服务端可能把两次任务搞混，返回了旧的或者不完整的结果。建议你在MCP server层加个显式的同步等待机制，或者把超时时间调大，同时检查一下是不是有连接池复用导致上下文串了。

还有个细节，你对比一下MCP转发前后的query编码，尤其是有中文或者特殊符号时，URL编码或JSON转义可能会把空格、引号变成奇怪的字符，模型拿到这种“脏”query，召回自然就飘了。可以在MCP server里打一行日志，把最终传给RAG的raw string打印出来，和直连时对比下，一眼就能看出来。

大概率是MCP把query里的特殊字符转义了，试试在tool里直接透传原始参数别走schema校验。

遇到过类似的坑，大概率是MCP server在转发时对query做了隐式改写，比如自动补全或截断，你可以抓一下MCP handler入口的原始参数和最终传给RAG的payload比对下编码。tool description太长确实会影响Claude的意图提取，我一般控制在50词内，把关键参数名和示例query写清楚就够了。超时中断那个我也踩过，建议把RAG调用改成同步阻塞模式，或者加个重试队列，别让异步任务裸奔。你可以在MCP层加个日志中间件，把所有进出参数打印出来，对比一下单独调RAG时的输入，基本就能定位是改写还是编码问题了。

遇到过类似情况，多半是MCP层把query里的特殊字符或空格做了编码转换，导致RAG那边的分词逻辑崩了，建议抓一下原始请求和转发后的请求对比看看。另外tool description写得长一般不影响query理解，但如果你在description里塞了太多示例，模型可能反而会提取出奇怪的关键词。超时那个也坑，MCP默认超时短的话RAG异步任务确实容易被掐断，试着调大超时时间或者改成同步等待试试。

大概率是MCP把query截断或加了额外参数，先抓原始请求比对下两端实际收到的文本再说。

超时这个坑我也踩过，RAG那边最好改成同步等待或者加个重试机制。

八成是MCP工具描述里的query示例干扰了模型改写，试试把description精简只留必要参数。

超时那个也遇到过，RAG异步任务直接断了，后来改成同步加长超时才稳定。

我之前也踩过类似的坑，重点查一下MCP server那边是不是对query做了隐式的改写或截断，比如转义、编码或者默认加了个system prompt。tool description写太长确实会影响模型对意图的提取，尤其当它把多余描述也塞进embedding时。超时中断那个更常见，建议把RAG调用改成同步阻塞模式，别依赖异步回调。你可以先抓一下MCP转发前后的原始query字符串，对比下字节级差异，大概率问题就出在这。

八成是query在MCP层被序列化时加了额外上下文，Claude拿到的检索词早变味了，建议直接打印传参对比看看。

超时那个大概率是同步转异步搞的鬼，试试把tool设成streaming模式，别让RAG等太久。

遇到过类似情况，最后定位到是MCP server在序列化query时把数组参数给拆了，比如top_k这种带下划线的字段名到了Claude那边变成了驼峰，模型按错误字段名传参，RAG那边拿到的实际是默认值，召回自然就飘了。建议你先抓一下MCP转发前后实际收到的query内容，对比编码和参数结构，大概率不是description太长的问题，那玩意儿影响的是模型选tool，而不是tool内部执行。

另外超时中断那个坑我也踩过，MCP默认请求超时可能比RAG的异步处理时间短，导致客户端那边已经报错重试，但服务端任务还在跑，最后返回的结果和当前请求对不上。解决方式是给MCP server单独配置更长的超时时间，或者在RAG接口里改成同步等待，或者把MCP这边的请求改成fire-and-forget再轮询结果。还有个隐蔽点，检查下MCP server是不是默认对query做了分词或去停用词，有些框架为了“优化”会预处理输入，反而破坏了RAG原有的query理解逻辑。你可以先绕过MCP直接调RAG接口，再用同样的参数走MCP，两边日志对拍一下，很快能看出差异在哪。

八成是tool description里塞太多示例把query带偏了，试试精简下描述只留必要参数。超时那个建议把RAG改同步或者加个重试机制。

之前调MCP接入别的服务也踩过类似的坑，建议先抓包看下MCP转发时query有没有被URL encode或者截断，我之前就是空格被编码成%20导致语义跑偏。tool description写得长确实会影响Claude的理解，试着把描述精简到一句话，重点强调“直接使用原始query”试试。超时那个大概率是MCP默认超时设得太短，RAG异步任务还没跑完就断连了，把timeout调到30秒以上应该能解决。

我之前也踩过类似的坑，大概率不是MCP转发本身改了query，而是tool description和参数schema在起副作用。Claude在调用tool前会先根据description做意图路由，如果你把RAG的prompt模板或者业务背景写得特别详细，它反而会“脑补”出一堆过滤条件，导致实际传过去的query已经被语义改写过了。你可以试试把description压到一句话，参数里只留query和top_k，看看召回是否恢复。另外，编码问题确实存在，特别是中文query，建议在MCP server端加一层严格的UTF-8校验，对比一下原始字节流。超时中断那个我更倾向于不是MCP的问题，而是你RAG服务自身没有做异步任务的状态持久化，MCP只负责发请求，如果下游处理超时，客户端那边会直接断开，但任务可能还在跑，只是结果丢了。你可以给RAG加个任务ID轮询机制，或者把超时时间调大，同时检查一下MCP的streamable HTTP配置，有时候是keep-alive连接被复用导致的问题。还有个细节，看看你的MCP client是不是默认给query加了embedding模型的temperature参数，有些封装会偷偷改采样参数，这也会让chunk分布变飘。先按这个思路排查，大概率能定位到具体环节。

八成是MCP那层把query里的特殊字符或编码搞坏了，建议先抓包对比下原始请求和转发后的参数。

超时中断这种我也踩过坑，把RAG调用改成同步等待或者加大超时阈值试试。

八成是tool description太长把query带偏了，试试缩短到一句话再测测召回率。超时那个也见过，建议把RAG改成同步等待别丢任务。