[BUG] tools/list_changed doesn't refresh the deferred-tool / ToolSearch index in interactive sessions (still repros on 2.1.165; carve-out from #4118 / #60626)

Open 💬 3 comments Opened Jun 7, 2026 by LudaThomas

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When an MCP server registers a new tool at runtime and emits notifications/tools/list_changed, the new tool never becomes invocable in the active interactive session. Specifically, it does not appear in the deferred-tool index that ToolSearch queries, so the model cannot load its schema and cannot call it. A full /mcp reconnect or session restart is the only workaround.

This is the same root cause raised in #60626, which was closed as not_planned (duplicate) and consolidated into #4118 — but #4118 was then closed as completed on the strength of the v2.1.0 handler work. The v2.1.0 fix wired up the notification handler for the /mcp capability list, but did not update the deferred-tool / ToolSearch surface used during an active conversation. So the specific #60626 bug is effectively untracked: folded into an issue that was simultaneously marked done. Multiple post-closure comments on #4118 report the same thing on 2.1.86 and 2.1.146; this report confirms it still repros on 2.1.165.

What Should Happen?

After tools/list_changed, the deferred-tool index backing ToolSearch should refresh before the next tool invocation (or the model should be able to force a refresh), so runtime-registered tools become loadable without a reconnect.

Error Messages/Logs

Steps to Reproduce

  1. Connect an MCP server that supports runtime tool registration (reproduced here with a WebMCP bridge on ws://localhost:4797).
  2. In an active interactive session, trigger the server to register a new tool. Server logs confirm registration and the server emits notifications/tools/list_changed:
  3. Registered channel: /localhost_8080
  4. Received message: registerTool on /localhost_8080
  5. Tool registered: localhost_8080-get_current_mel
  6. Ask the model to search for / use the new tool. ToolSearch returns no match for the tool by exact name (select:mcp__webmcp___localhost_8080-get_current_mel), partial name (localhost_8080), or semantic query.
  7. The tool stays uncallable until /mcp reconnect or a session restart.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.165 (native binary, built 2026-06-04)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The deferred-tool index is populated at server connect/init time and is not refreshed mid-session. ToolSearch searches a stale snapshot; the runtime-registered tool is invisible. The two WebMCP tools present at connect (get-token, define-mcp-tool) are searchable; the one registered after connect is not — which points to a connect-time snapshot rather than a live/list_changed-driven refresh of the deferred surface.

Why this isn't covered by existing issues
#4118 — closed completed; the v2.1.0 fix covered the /mcp handler, not the deferred-tool / ToolSearch surface. Post-closure comments (2.1.86, 2.1.146) report ToolSearch still doesn't pick up newly promoted tools.
#60626 — closed not_planned as a duplicate of #4118; this was the deferred-tool case, and it got absorbed into an issue that was then closed as done.
#62844 — open, but scoped to headless --print --output-format stream-json mode only.
#65569 / #64909 — adjacent (skill-backing deferred tools / sub-agent empty registry), not the interactive runtime-registration case.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗