[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)

if I do kill the session and start a new one the deferred-tool index is up to date and claude can use the tools.

+1 — confirming this reproduces with a different MCP and across two transports, which rules out WebMCP-specific and transport-specific causes. The trigger isn't "new tool registered at runtime" — it's "tools published after the deferred-tool snapshot is taken at connect/init time," which the OP's last paragraph already nails. Adding our repro for the case-coverage record:

Setup (Linux, Claude Code 2.1.x interactive session):

mcp-toggle is a runtime MCP-proxy MCP. Its mcp_enable("foo") tool spawns a child MCP, dynamically publishes the child's tools under the prefix foo__, and emits notifications/tools/list_changed via session.send_tool_list_changed(). mcp_disable does the reverse.

Symptom (identical to OP):

mcp_enable("context7")
  → { tools_loaded: 2, tool_prefix: "context7__" }            ✓ proxy did its job
context7__resolve-library-id(libraryName: "Astro middleware")
  → "No such tool available: context7__resolve-library-id"   ✗
ToolSearch(select:context7__resolve-library-id)
  → "No matching deferred tools found"                        ✗

Same failure for an HTTP-transport child (playwright, 23 tools loaded per enable result; playwright__browser_navigate → No such tool available). So the bug is transport-agnostic on the client side — both stdio child MCPs and Streamable-HTTP child MCPs fail identically.

Confirmed mcp-toggle is doing its end correctly:

Driven directly as a stdio child via a fresh ClientSession in a Python test (tests/test_proxy_live.py in the repo), the exact same mcp_enable call followed by list_tools returns the newly-published tools, and forwarding a call returns real upstream data. So the JSON-RPC notification is emitted and the MCP-SDK side honors it correctly — the gap is on the Claude Code host, exactly as OP describes.

Why this matters for catalog-style on-demand MCPs. The whole value prop of mcp-toggle and similar runtime-management tools (context-window discipline by spawning MCPs only when needed) is dead-on-arrival in Claude Code interactive sessions until this is fixed. Today the pragmatic workaround is to register everything claude mcp add --scope user, paying the context cost of all tools at session start — which is what mcp-toggle v2 was built to avoid.

Happy to provide additional repro detail (mcp-toggle source, session transcript, SDK versions) if it helps narrow down the deferred-tool-snapshot path on the host side.

Can confirm the split you're describing from the other side. I've been driving notifications/tools/list_changed at runtime from a gateway (mcp-salad — Unix socket, enable/disable mutates the server pool and fires the notification), and the behavior tracks exactly what you wrote: the /mcp capability list reflects the change, but the tool doesn't become invocable in an active interactive session until a reconnect.

In a ToolSearch/deferred-tool setup the failure is even quieter — the newly-registered tool isn't in the searchable index, so the model can't even surface its schema to load it, let alone call it. So from the user's seat it looks like the notification silently did nothing, when really the capability side updated and the deferred-tool surface didn't. Enabling then disabling a server round-trips fine on the /mcp list but the call path stays stale until /mcp reconnect.

Net: the v2.1.0 handler wired the notification to the capability list but not to the deferred-tool index the conversation actually dispatches through, which is the carve-out you're pointing at. Happy to share repro logs from the gateway side if a minimal reproduction helps — it exercises this path on every enable/disable.