MCP tools/list_changed notifications do not refresh session-visible tool registry

MCP tools/list_changed notifications do not refresh session-visible tool registry

Summary

Kimi Code connects to MCP servers and discovers tools on connect/reconnect, but the active session tool registry does not refresh when a connected MCP server sends notifications/tools/list_changed.

This blocks same-session dynamic MCP workflows, including lazy MCP servers that initially expose a loader tool and then expose real downstream tools after the loader is called.

Reproduction

Local repro used a stdio MCP fixture and McpConnectionManager directly, without a model account or TUI:

1. Start a stdio MCP server that advertises capabilities.tools.listChanged: true.
2. Initial tools/list returns one tool: enable_extra_tool.
3. Call enable_extra_tool.
4. The server returns the tools/call response, then sends notifications/tools/list_changed.
5. A subsequent tools/list returns enable_extra_tool and dynamic_echo.

Before the local patch, the underlying client could re-list the server tools, but McpConnectionManager continued exposing only the old session-visible tools.

Expected

When a connected server advertises tools.listChanged and sends notifications/tools/list_changed, Kimi should refresh that server's tools and emit the existing MCP status update path so the active session sees the new registry.

Actual

Kimi discovers tools during connect/reconnect, but does not route MCP SDK listChanged.tools.onChanged results back into McpConnectionManager.

Source Locus

• packages/agent-core/src/mcp/client-shared.ts
• packages/agent-core/src/mcp/client-stdio.ts
• packages/agent-core/src/mcp/client-http.ts
• packages/agent-core/src/mcp/client-sse.ts
• packages/agent-core/src/mcp/connection-manager.ts
• packages/agent-core/test/mcp/connection-manager.test.ts

The installed MCP SDK already supports ClientOptions.listChanged.tools.onChanged in @modelcontextprotocol/sdk@1.29.0.

Related

• #965: schema-size pressure from many MCP tools; lazy loading is one mitigation path.
• #218: plugin reload hot-apply, related to MCP server lifecycle but not server-side dynamic tool list notifications.
• #383: reload commands, useful manual workaround but not same-session protocol notification handling.
• #286: MCP list display behavior, not the same refresh issue.

Local Validation Of Proposed Fix

Validated locally on branch fix/mcp-tool-list-changed-refresh, commit f2fd6249:

• pnpm --filter @moonshot-ai/agent-core exec vitest run test/mcp/connection-manager.test.ts passed: 30 tests.
• pnpm --filter @moonshot-ai/agent-core run typecheck passed.
• A local lazy MCP proxy end-to-end passed: after calling mcp_load_server_fake-lazy-server-1, Kimi received notifications/tools/list_changed, re-listed tools, and removed the loaded server's loader tool from manager state.

Proposed Fix Direction

Wire MCP SDK listChanged.tools.onChanged into the existing MCP client wrappers, then update McpConnectionManager only for the current connected attempt:

• ignore stale reconnect attempts;
• log refresh errors without dropping the existing tool registry;
• validate refreshed input schemas through the same path as startup discovery;
• update entry.tools and entry.enabledNames;
• emit the existing status update path.

Start by reading the MCP client wrappers in packages/agent-core/src/mcp/client-shared.ts, client-stdio.ts, client-http.ts, and client-sse.ts, then trace how connection-manager.ts receives startup tool discovery. Run test/mcp/connection-manager.test.ts first. Done means list-changed notifications refresh the session-visible registry, preserve existing tools on refresh errors, and pass the listed typecheck and test commands.