Claude Desktop does not register tools from a tools/list refresh triggered by notifications/tools/list_changed

### What happened?

I requested this issue report from Claude (Opus 5) arising from working on a PCB layout project.
I am a hardware designer and low level firmware coder, so this is well outside my personal skill set.
Also, I am new to using AI based tools. Apologies if I am doing this incorrectly.

_Claude reports:_

**Summary**

A local stdio MCP server that loads tools dynamically sends notifications/tools/list_changed. Claude Desktop responds correctly by requesting tools/list, and the server returns a complete, well-formed response containing the newly added tools. Claude Desktop then behaves as though those tools do not exist: invoking one returns "Tool not found", and the tools cannot be surfaced by name through the client's own internal tool search.

The tools are received and discarded. Only tools present in the initial handshake tools/list are ever usable.

**Environment**

- Kubuntu 24.04.4
- Claude Desktop (Linux), current as of 2026-08-30
- MCP server: Konnect v0.11.0 (KiCad plugin, Rust), local stdio transport
- KiCad 10.0.6

The server groups its ~200 tools into toolsets and exposes only a 14-tool starter kit at startup, loading the rest on demand via a load_toolset meta-tool. That design is what surfaces this bug — a server exposing everything up front would never hit it.

**Reproduction**

1. Start a clean session. Confirm the starter set is present (here: 14 tools).
2. Call the server's load_toolset("sch_components") meta-tool. It reports 20 tools added, no errors.
3. The server emits notifications/tools/list_changed.
4. Claude Desktop sends tools/list (id=4) ~7ms later.
5. The server responds with 40 tools, including all 20 newly loaded ones, each with a complete inputSchema.
6. Ask Claude to call one of the new tools, e.g. list_schematic_components.

**Expected:** the tool is callable. **Actual:** Tool 'konnect:list_schematic_components' not found. No tools/call request reaches the server. A search of the client's internal tool index for that exact name returns only starter-kit tools.

**Evidence**

From the server's debug log, single run, timestamps 2026-08-30T13:32:18:

.818 STDIO send notification: {"jsonrpc":"2.0","method":"notifications/tools/list_changed"}
.824 STDIO recv: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":4}
.824 Handling method: tools/list
.8248 STDIO send: {"jsonrpc":"2.0","id":4,"result":{"tools":[ ... 40 tools ... ]}}

The id=4 response body was captured in full. It contains, among others:

json
{"description":"List all symbol instances in a schematic with their positions,
values, footprints, and pin locations.",
"inputSchema":{"properties":{"schematic":{"type":"string"}},
"required":["schematic"],"type":"object"},
"name":"list_schematic_components"}

Composition of the 40: 6 meta-tools + 14 starter kit + 20 from the loaded toolset. Nothing is missing or malformed.

The subsequent invocation attempt produced no tools/call entry in the server log, confirming the request never left the client.

This was verified as a server-side non-issue by the MCP server's maintainer, who asked for exactly this capture to distinguish the two possible failure locations. The server is behaving to spec.

**Impact**

For servers using dynamic tool loading, the entire mechanism is unusable in Claude Desktop. The user-visible symptom is confusing: the meta-tool reports success, the server's own introspection confirms the tools are active, and the model then insists they don't exist.

**Workaround**

The server offers an eager_toolsets = true option that loads everything before the handshake, so all tools appear in the initial tools/list. That works reliably. The cost is ~200 tool definitions in context instead of 14, which is the exact overhead the on-demand design existed to avoid.

**Notes**

- Reproduced on **stdio**, a local server — not a remote/hosted connector.
- The failure is consistent, not intermittent: it reproduced across multiple sessions, several server versions (v0.7.0 through v0.11.0), and both KiCad 10.0.5 and 10.0.6.
- Behaviour is identical whether the tools are loaded singly or as an array in one call.

**Possibly related**

During the same work I twice hit a tool call that returned "No result received from the Claude Desktop app after waiting 4 minutes" — matching the hard four-minute timeout described in anthropics/claude-code#64614. That issue is scoped to Anthropic-hosted remote connectors; this occurred on a **local stdio server**, so it may be a different path, or the timeout may be broader than that report suggests. Mentioning it in case the two are related; happy to file separately if preferred.

### What did you expect to happen?

Not sure what to write here: Expect tools defined can be loaded and accessed?

### Steps to reproduce

1. Start a clean session. Confirm the starter set is present (here: 14 tools).
2. Call the server's load_toolset("sch_components") meta-tool. It reports 20 tools added, no errors.
3. The server emits notifications/tools/list_changed.
4. Claude Desktop sends tools/list (id=4) ~7ms later.
5. The server responds with 40 tools, including all 20 newly loaded ones, each with a complete inputSchema.
6. Ask Claude to call one of the new tools, e.g. list_schematic_components.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Again, don't know if this is right answer. Konnect?

### Error messages or logs

```shell

```

### Additional context

Please let me know what additional information you would like to know.
Thanks.

Start with the MCP Connector handling for notifications/tools/list_changed and the subsequent tools/list refresh. Compare the returned tool definitions with the client's internal tool registry or search index, using the supplied 14-tool to 40-tool reproduction. Done means tools loaded after the initial handshake can be found and invoked through Claude Desktop.

Scritto dal modello di indicizzazione a partire dal testo della issue.