DeepSeek Harness MCP client: vanishing tools, no reconnect

When DeepSeek Harness (DSH) connects to MCP servers, almost all failures happen in "the second stage after connecting" — registration and refresh, not the connection itself. This batch of threads has four typical forms, and each has a very recognizable log criterion: an entire family of tools vanishes (during the registration generation switch the rollback is incomplete, and "contains" semantics swallow the error, so some server ends the round with 0 tools while the old generation is already destroyed, recoverable only by restarting the host); session invalid without reconnect (the reconnect logic hangs off the transport-close callback, and "session expiry" does not close the transport — it only goes through the error callback, so every call reports No valid session ID provided); new tools invisible (the auto-refresh switch is written as a literal, off, and list_changed notifications are wasted); a pagination cursor never obtainable (a call without a cursor is handed to the SDK's auto-aggregation path, which merges multiple pages and deletes nextCursor) (#9864, #9740, #9625, #9374).

DSH plugin entire families of tools vanish: incomplete registration rollback

The one-line conclusion: at the generation switch the old generation is destroyed before the new one is registered; once registration throws, the rollback covers only the new generation, and the config uses "contains" semantics — the error is swallowed and an empty set returned, so this server ends the round with zero tools while its old generation is already gone. The symptom is "the server process is alive, resources list, a bare handshake lists 14 tools, but there is not a single mcp__<server>__* in the agent tool surface", recovering only after a host restart (#9864).

DSH plugin three steps to locate it: judge the stage by searchable log lines

1. Do the bare-handshake comparison first: connect to that server directly with an MCP client and list tools — being able to list them means the server side is fine and the problem is in the host-side registration stage (#9864).
2. Tell the stage apart by log line. The thread gives two grep-able log kinds: one is "registration failed, no tools registered" (the generation-switch/registration stage), the other is "resync failed" (the reconnect stage). The two have different causes and different handling (#9864).
3. Confirm the consequence of "contains" semantics: if the log shows the server registered 0 tools this round rather than "a few missing", this is the case (#9864).

DSH plugin handling

1. Immediate recovery: restart the host (the only effective means) (#9864).
2. Reduce the trigger: make the same server not provide same-named tools on two tool surfaces at once, avoiding a registration conflict (#9864).
3. The plugin-side approach and its cost: you can patch the tool registration interface to downgrade a conflict to non-fatal — but that trades "roll back the whole generation" for "drop only the conflicting name", a consistency-for-availability trade-off (#9864).

DSH plugin session invalid without reconnect: the error only goes through onerror, the transport is not closed

The one-line conclusion: the reconnect logic hangs only off the transport close event, and "session invalid" does not close the transport — the SDK reports it only through the error callback, so reconnect is never triggered and the tool closure stays bound forever to the dead generation of the connection. The symptom is every call reporting Bad Request: No valid session ID provided or 404 Session not found, recovering only after restarting DSH (#9740).

DSH plugin criterion and one easily missed trigger

1. Criterion: the error clearly mentions an invalid session (400 or 404), and the server process may have restarted; restarting DSH recovers it immediately (#9740).
2. Do not stare only at "the server restarted": the thread later corrected the trigger — session expiry from long idleness triggers it too (the magnitude mentioned in the thread is 12 hours idle), so "I did not restart anything" does not rule this out (#9740).

DSH plugin three ways to handle it

1. Immediate recovery: restart the host process (the bridge is shared at the process level, which is also why a single session cannot self-heal) (#9740).
2. Community patch: MaxHou-infinity/dsh-mcp-session-recovery subscribes to the error callback, does a narrow match on "session lost"-style errors, then reuses the existing connection-offline flow to trigger a reconnect — the key is the narrow match, to avoid treating every error as a disconnect (#9740).
3. Mitigate the idle trigger: avoid letting a stateful server be completely idle for a long time (for example, keep light periodic interaction), or prefer servers with a stateless transport form (#9740).

DSH plugin new tools invisible: list_changed auto-refresh is hardwired off

The one-line conclusion: at construction the client hardcodes "auto-refresh of tool-list changes" to off (a literal, not a config item); although the machinery that "refreshes on a change notification" still exists, it never fires because the switch is off. The symptom is that a running session never sees tools added to a server at runtime, reporting unknown tool "mcp__<server>__<newTool>", while a new session sees it immediately (#9625).

DSH plugin four steps to handle it

1. Confirm the criterion: for the same server, the current session cannot see the new tool while a new session can; that is this case (#9625).
2. Distinguish the two switches: the thread specifically warns that "auto-refresh" and "the refresh callback after a notification" are two switches — the presence of the latter does not mean the former is on; do not conclude "the logic is there, it just did not fire" from seeing the callback (#9625).
3. Workaround: restart DSH (the reconnect path forces a sync once) (#9625).
4. Mind the plugin's boundary: a developer notification is emitted when the session tool surface changes, but an out-of-tree plugin cannot reach the generation of the connection inside the closure, so it cannot turn it on from outside (#9625).

DSH plugin pagination cursor: a call without a cursor is swallowed by auto-aggregation

The one-line conclusion: when the caller passes no cursor, the request is handed to the SDK's auto-aggregation path — it merges all pages and deletes the nextCursor field, so the contract's "one page plus a cursor" is never obtainable; when the page count exceeds the internal cap of 64 it errors outright. The symptom is list_mcp_resources / list_mcp_resource_templates never returning a cursor, and servers with many pages reporting exceeded listMaxPages (64); server pagination did not terminate (#9374).

DSH plugin four steps to handle it and one contract change to note

1. Confirm the criterion: the result never has a nextCursor field; with many pages it reports the above error (#9374).
2. Temporary detour: reduce the amount of data in play (shrink the server-side per-page size or reduce the resource count), or use a client that talks to the server directly to fetch the resource list (#9374).
3. The fix (given in the thread): request one page at a time and return the cursor verbatim; the author provides a branch that changes only the connection layer (#9374).
4. Be aware of the contract change: after switching to "one page + cursor", the call's returned volume goes from "all pages" to "one page" — this is a behavior change, and downstream consumers that depend on it need to adjust accordingly (#9374).

DSH plugin troubleshooting notes

The MCP troubleshooting mantra is: do a bare handshake to confirm the server side first, then use the logs to judge "registration stage or reconnect stage", and only then suspect the server implementation. Eight points:

1. The bare-handshake comparison rules out half the possibilities in one shot, at the lowest cost (#9864).
2. "A whole family drops to zero" and "a few are missing" are two causes: the former is a rollback defect, the latter is usually conflict downgrading (#9864).
3. Session invalidation does not close the transport, so a reconnect never happens (#9740).
4. Idleness also invalidates a session, not only a server restart (#9740).
5. "A new session sees it but the current one does not" = a refresh-switch problem, the easiest criterion here (#9625).
6. Do not conflate the two switches: auto-refresh ≠ change callback (#9625).
7. A missing pagination cursor is eaten by the middle layer, not withheld by the server (#9374).
8. State the fix status honestly: all four are unfixed in the versions discussed (0.2.0-rc.2~0.2.1-alpha.*); the session reconnect and the pagination cursor have community patches/branches to reference, but none are merged, so they remain user-side workarounds.

MCP problems like "tools that come and go" most need a clear view of "which servers are actually connected and what the tool surface looks like". Instead of typing commands everywhere, use a visual marketplace like DSH Plugin Hub: the installed list, install/uninstall history, and system logs sit in one panel, so you can see the environment clearly first.

Source: Discussion #9864, Discussion #9740, Discussion #9625, Discussion #9374.