[Bug] ToolSearch 激活的 MCP 工具跨轮调用间歇性失效（Tool not found / TOOL_NOT_FOUND），需反复重新搜索 / On-demand MCP tools activated via ToolSearch intermittently fail with Tool not found across turns

[Alonso-li]

Problem / 问题

通过 ToolSearch 激活的 on-demand MCP 工具（尤其 stdio 型，如 fastctx）经常跨轮调用失败：ToolSearch 明明成功返回"已激活"，但模型在下一轮（或隔几轮）调用 mcp_fastctx_* 时收到 Tool not found / errorCode=TOOL_NOT_FOUND，需要反复重新 ToolSearch 才能再用。高频使用 fastctx 读/跑命令时几乎每几分钟就要重搜一次，严重影响正常 agent 工作流。

复现（本次会话实测，fastctx 为 stdio MCP）

同一会话，fastctx server 连接一直正常，但调用却间歇性失败：

06:44:10  mcp_fastctx_run … ok=true          (execute 179ms)
06:47:54  mcp_fastctx_run … ok=true
06:48:56  mcp_fastctx_run … ok=true
06:58:31  mcp_fastctx_run … ok=true          (execute 72ms)
06:59:50  mcp_fastctx_run … isError=true     ← Tool not found（未见 mcp.call，连接层未命中）
06:59:57  ToolSearch（再次激活）
07:00:16  mcp_fastctx_run（恢复可用）

链条：工具调用成功 → 下一次同工具直接 TOOL_NOT_FOUND（宿主日志里连 mcp.call 都没有，说明在 UserMcpRuntime.findTool 就已失败）→ 重新 ToolSearch 又恢复。MCP server 本身一直健康（plugin.log 中 mcp.call ok=true 一直持续），不是 server 端问题，是宿主侧的工具激活/连接缓存与工具集名脱节。

期望行为 / Expected behavior

1. 激活的 on-demand MCP 工具在本会话内保持可用，不应出现"搜索成功、下轮即失效"；
2. findTool 未命中时若记录/连接仍存在，应尝试**惰性重建连接（like connect()）**而不是直接抛 TOOL_NOT_FOUND；
3. 若确实因为 server 未启用/scope 不匹配而失效，错误信息应说明是 mcp server X is not active，而不是笼统的 Tool not found，便于用户区分"工具没激活"与"server 连接断了"；
4. 失败后的事件留痕：当前 tool.log 只有 isError=true，没有 errorCode 与 toolName 之外的原因字段。

相关代码线索（0.14.1）

• UserMcpRuntime.callTool()：findTool() 未命中 → throw { errorCode: "TOOL_NOT_FOUND" }
• UserMcpRuntime.findTool()：仅遍历 this.entries（已连接缓存的 client），连接建立是 lazy 的（connect() 在调用/预取时才发生），entries 中连接一旦失效/被回收，工具即"消失"；
• ToolSearch 走 host 的 on-demand tools 注入，注入的是工具清单，与 entries 的连接实际状态不同步。

版本

• PI-Desktop 0.14.1（macOS，Apple Silicon）
• fastctx：stdio MCP（~/.agents/servers/fastctx.json，/Users/arm/.fastctx/bin/fastctx serve --enable-shell）

Additional / 补充

• 在 Pi CLI（terminal）里 fastctx 无此问题，说明是该桌面宿主 tool-search / 连接缓存逻辑引入的产物。
• 复现频度：50+ 次调用中至少 2~3 次（约 4-6%），间隔从数十秒到数分钟不等；Compaction / 长回合后更容易出现。

[vastsa]

The originally reported “ToolSearch activated the MCP tool, next turn it is TOOL_NOT_FOUND” path is fixed on current main by two landings:

1. PR fix(mcp): recover discovered tools after transport loss #198 (51120914): UserMcpRuntime keeps previously discovered names across transport close and reconnects on demand, instead of throwing while the server is still in scope.
2. PR fix(agent-runtime): restore on-demand tool activations still in context #231 (eafe2763): on-demand activations still present in the transcript are restored on a new turn, so ToolSearch history is not left dangling after the live tool set is rebuilt.

Regression coverage includes stdio process recovery in the user-mcp suite and restores deferred tool activation markers from persisted results.

Closing this report. If a later log shows a healthy connection rejecting a name the server no longer advertises, please open a new issue with that trace.

原先「ToolSearch 已激活、下一轮却 TOOL_NOT_FOUND」的路径已在 main 修好，关闭。