dsh-mcp-client hardcodes listChanged.tools.autoRefresh: false — an existing session never observes MCP tool-list changes

[weiyuchen00-cmyk]

Summary

@deepseek-ai/dsh-mcp-client constructs its MCP Client with a hardcoded listChanged.tools.autoRefresh: false. The value is a literal in the connection code, not a config field, so a session that is already running can never pick up tools that an MCP server adds at runtime — even though the MCP protocol defines notifications/tools/list_changed for exactly this purpose, and the re-sync path inside dsh is present and working.

Evidence (from the shipped bundle)

1. The client options are a literal, not config. In dsh-mcp-client's connectGeneration():

const generation = new Client(
  { name: "dsh-mcp-client", version: "0.0.1" },
  {
    capabilities: {},
    versionNegotiation: { mode: "auto" },
    listChanged: { tools: {
      autoRefresh: false,          // <-- literal; not read from plugin config
      debounceMs: 0,
      onChanged: () => { refreshTools(); }
    } }
  }
);

2. The refresh path exists. refreshTools() logs `${label}: tool list changed, re-syncing` and calls enqueueSync(generation). The machinery is there; it is simply unreachable while autoRefresh is forced to false.

3. No config escape hatch. Searching the plugin's config schema for listChanged / autoRefresh finds no configurable field.

Reproduction (measured)

Environment: dsh 0.2.0-rc.2 (Windows, Electron), dsh-mcp-client 0.0.1.

1. Session A already exists.
2. Add a new tool to an existing MCP server, whitelist it, restart the MCP server process, restart DSH.
3. Calling the new tool from session A → unknown tool "mcp__<server>__<newTool>".
4. Create a new session B with the identical profile/config → the new tool is immediately available.

The same happens with an entirely new MCP server added to the profile: existing sessions keep their old tool list; only sessions created afterwards see it.

Expected behaviour (either would help)

• Preferred: expose listChanged.tools.autoRefresh (and debounceMs) as plugin config fields, so deployments that want runtime tool refresh can enable it. Alternatively default it to true and let the MCP server decide when to notify.
• Minimum: document that a session's MCP tool list is snapshotted at session creation, so that MCP server authors and operators know a reconnect / new session is required.

Why this is a general problem (not a niche request)

MCP defines notifications/tools/list_changed precisely so that servers can add or remove tools at runtime. With autoRefresh hardcoded off, that capability is unreachable in dsh no matter what an MCP server does — which makes dsh less MCP-conformant than the SDK it builds on.

For completeness: our own MCP server does not emit list_changed yet either; we intend to add it. But adding it today would change nothing, because the client cannot act on it.

Secondary observation (may well be by design)

The same "assembled at session creation" behaviour appears in the skill system: after adding new skill files and enabling dsh-skill / dsh-skill-filesystem / tool-skill / skill-badge, an existing session's available-skills list does not show them, while a newly created session sees them immediately. If that is intentional, one line in the docs would help.

Separately, the "preset chosen, session already started → locked" behaviour (agent-preset/locked, This session has already started) is visible in the source. We are not asking to change that; we only want to know whether it additionally gates the session's tool surface.

[argszero]

The literal is where you say it is, and the refresh machinery is wired — but I think the decisive variable in your reproduction is not that literal, and the restart in your steps is how you can see it.

The code, at packages/mcp/mcp-client/src/connection.ts:263-269:

listChanged: {
  tools: {
    autoRefresh: false,
    debounceMs: 0,
    onChanged: () => { void refreshTools() },
  },
},

with refreshTools at :296-302 logging `${label}: tool list changed, re-syncing` and calling enqueueSync(generation). Those are two separate switches: autoRefresh governs the SDK's automatic re-listing, while onChanged is the callback the SDK invokes when the notification arrives. Which of the two your missing tools depends on is therefore the first thing to settle, and the log line at :298 settles it — if the re-sync ran, that INFO line is in the dsh log at the moment the server's tool list changed.

But your reproduction restarts DSH as well as the MCP server, and that reconnect re-lists the tools independently of autoRefresh: a fresh connectGeneration queues a sync on connect (:323). So by the time session A is resumed the new tools are very likely already in the registry — and the interesting fact is that a new session sees them while an existing one does not. Connection state is identical for those two sessions; the difference is the session. That points at a second mechanism, and you have already recorded its fingerprint in your own secondary observation: newly added skill files are likewise invisible to an existing session. dsh does carry a per-session surface-change notice — when the request surface changes, the loop appends a developer/message with source.kind === 'tool-registry' holding { type: 'tool-addition' | 'tool-removal', toolName } (packages/core/agent-loop/src/agent.ts:651-664). So the discriminating check is: after resuming session A, does such a message appear in its session log when the tool list changes? If it does not, the failure is in the surface re-assembly rather than in MCP notification handling, and enabling autoRefresh would change nothing.

If it does turn out to be the client-side notification, the honest boundary is that a plugin cannot reach it: the Client instance is the closure-local generation inside startConnection (:127), and this plugin provides no service exposing it (inject = ['tools'] only — index.ts:34), so an out-of-tree plugin has no seam onto refreshTools. Our published @argszero/dsh-mcp-tool-filter@0.1.0 (npm) sits one layer above, on ctx.tools.register: it can decide what enters the registry at all, but it cannot make a session re-assemble a surface it captured earlier.

Your minimum ask — documenting that a session's MCP tool list is captured at session creation — is the right fallback either way, because that capture is the one thing both hypotheses share.

[weiyuchen00-cmyk]

Thanks — this is the most useful correction we've had, and the discriminating experiment you proposed settles it. We ran it. Results:

1. The notification mechanism is alive. We decompressed our session record (the file is multi-frame zstd, which took some work) and found 28 tool-registry notices over its lifetime. Recent ones include 17 mnemon tools added on 10-12, and the skill tool added then removed on 10-13. So "the loop appends a developer/message when the surface changes" is exactly what happens in practice.

2. Before the DSH restart, the two new MCP tools produced zero notices. We added them on the bridge side, restarted the bridge (not DSH), and the session log stayed silent about them. They never reached the registry.

3. After a DSH restart this morning, the record shows exactly one new notice (08:37 local): tool-addition for qq_read_ds_session and qq_search_ds_turns. And the call error changed from unknown tool to our bridge's own endpoint rejection ("console-only"), which is our server's authorization layer, unrelated to DSH. (We'll fix that on our side.)

So the discriminating variable turns out to be the restart — i.e. the reconnect that forces a sync at connection.ts:323 — which means the original complaint stands, with one correction: the session surface is not "frozen"; it's the MCP client that never re-lists because autoRefresh is hardcoded false. Your two-switch point is exactly right, and our reproduction conflated them.

What we still hope for (unchanged from the original post): make listChanged.tools.autoRefresh configurable. Restarting DSH is not an acceptable refresh mechanism for long-running sessions, and the MCP spec already provides the notification; dsh's client just refuses to act on it. The "document that the session captures its tool list at creation" fallback is also still worth a line, since it describes the default behaviour precisely.

Also noted and accepted: out-of-tree plugins cannot reach refreshTools (closure-local generation, inject = ['tools'] only). Thanks for the pointer to @argszero/dsh-mcp-tool-filter; we'll keep an eye on it, but it can't do what we need here.

Confirmed end-to-end: after opening our endpoint auth (the "console-only" guard was our own server's rule, not dsh's), the agent-side call to qq_search_ds_turns succeeds and returns real turn data. So the full chain is now verified: DSH restart → reconnect + forced sync → tools enter the registry → surface notice appended → agent callable.