DSH rc.3 MCP peer-gate diagnosis

DSH rc.3 MCP Tools Missing: Peer Gates & Profiles

Author
DeepSeekAgent.io Editorial Team
Published
Updated

After DeepSeek Harness Desktop upgrades to v0.2.1-rc.3, MCP servers may remain in cordis.patch.yml while every mcp__<server>__* tool disappears. A community reproduction from October 25, 2026 traced the failure to the Profile dependency tree: the application had moved to rc.3, but the transitive @deepseek-ai/dsh-mcp-client dependency remained on rc.2 and was rejected by the boot-time compatibility gate.

The decisive signal is that no MCP child process starts. Playwright, Telegram, or another MCP server never reaches connection handling; stdio does not fail because the plugin is excluded before a connection exists. Network, command-path, and sandbox debugging therefore cannot reach the cause.

Where the tools disappear

The reported environment used Windows 11 and Desktop rc.3, with MCP plugins registered in the desktop Profile through cordis.patch.yml. The upgrade reinstalled the Profile tree, while lockfile and range resolution kept the MCP Client on rc.2.

That plugin did not declare an accepted DSH range through engines.dsh. Instead, it exactly pinned several @deepseek-ai/dsh-* peers to 0.2.1-rc.2. During rc.3 boot, dsh-app-boot called evaluatePluginCompatibility, detected unmet peers, and rejected the plugin during loading.

The sequence is:

  1. Desktop and core packages advance to rc.3.
  2. A transitive Profile dependency still resolves to rc.2.
  3. Exact peer requirements no longer match the running core.
  4. The boot compatibility gate rejects the plugin.
  5. No stdio child process is created and no MCP server connects.
  6. Every tool registered by that plugin vanishes from the Agent capability set.

Why the UI and logs can stay quiet

Once an MCP server has started, diagnostics can inspect its command, environment, stderr, handshake, and timeout. This incident stops at the earlier compatibility decision. failOnStartupError does not participate because there is no connection attempt to fail.

That distinction explains three confusing observations:

  • retained configuration does not prove that its plugin loaded;
  • an absence of MCP connection errors does not prove the path is healthy;
  • all tools disappearing together points toward a shared plugin rejection rather than simultaneous server failures.

In the reproduction, exactly installing @deepseek-ai/[email protected] restored 23 MCP tools. This also ruled out the Windows sandbox, Playwright/Chrome dependencies, and lost configuration.

A more efficient diagnostic order

When an upgrade removes all MCP tools:

  1. record the actual DSH, Desktop, Profile, and MCP Client versions;
  2. determine whether the MCP Client is direct or transitive;
  3. inspect whether the lockfile still resolves an older release candidate;
  4. compare engines.dsh and peer dependencies, including exact pins;
  5. verify that the plugin reached a loaded state before inspecting stdio;
  6. only after the child process starts, debug its command, environment, handshake, and tool discovery.

Restarting servers, reinstalling a browser, or editing server commands cannot repair a plugin rejected at the boot gate.

Why prereleases expose exact-peer problems

SemVer treats prerelease identifiers precisely: 0.2.1-rc.2 and 0.2.1-rc.3 are distinct versions. An exact peer pin can make every candidate update incompatible.

Exact versions are justified when a plugin is tightly coupled to private interfaces. In that case, the updater must treat the compatible package set as one unit rather than updating only the top-level application. Plugins that work across candidates can publish a tested engines.dsh range, and Profile installation can run a dependency-consistency check before restart.

The product should also expose compatibility rejection in the Plugin Manager or startup diagnostics, including the plugin name, installed version, required DSH range, and recovery action. Silent tool removal makes capability changes hard to audit and can let an MCP-dependent task continue without the tools it expected.

This article covers why tools never register. For tools that load successfully but create excessive schema overhead, see DSH large MCP catalogs, Deferred Tools, and token cost.

References

FAQ

Why do all MCP tools disappear while the configuration remains?

The configuration can persist while the plugin responsible for loading it is rejected. No server starts and no tools enter the Agent capability set.

Does the absence of a stdio error clear the MCP Client?

No. The plugin can fail compatibility evaluation before a stdio child is created. Check plugin load state and dependency versions first.

What should I inspect first when every MCP server disappears?

Inspect the shared Profile, MCP Client version, lockfile resolution, and compatibility gate before debugging individual servers.