DSH plugin vs MCP: what is the difference?

The core distinction

A DSH plugin runs as part of the Cordis plugin tree and can participate in services, events, interfaces, policies, and lifecycle. An MCP server is a separate process or HTTP service that advertises protocol capabilities to a client.

Question	DSH plugin	MCP server
Where does it run?	Inside the DSH composition.	As a separate stdio process or remote HTTP service.
What can it extend?	Tools, services, UI, models, policy, storage, jobs, session state, and more.	Protocol capabilities exposed by the server.
How does DSH load it?	Cordis module or installed DSH bundle.	The @deepseek-ai/dsh-mcp-client bridge plugin.
Lifecycle owner	Cordis mounts and disposes the plugin.	The MCP client connects, discovers tools, and manages reconnects.
Portability	Specific to DSH and its extension seams.	Reusable with any compatible MCP client.

What the current DSH MCP bridge supports

The official MCP client plugin connects to stdio or Streamable HTTP servers and registers discovered tools on the native DSH tool registry using server-qualified names.

Tools are bridged into ctx.tools.
Tool-list changes can resynchronize registrations.
Stdio crashes can reconnect with bounded exponential backoff.
MCP Resources and Prompts are not currently bridged because DSH has no consumer for them.

Choose a DSH plugin when

Use a native plugin when the feature must participate deeply in the Harness lifecycle or replace a DSH service seam.

You need a Web, terminal, or conversation interface extension.
You need session events, durable state, model adapters, policy, or sandbox providers.
You need reversible registrations tied to a profile and Cordis dependencies.
The capability is intentionally DSH-specific.

Choose MCP when

Use MCP when an independent service should expose tools to several compatible hosts or remain operationally separate from DSH.

The same tools should work in DSH and other MCP clients.
The service already has an MCP implementation.
Remote deployment, language independence, or process isolation is valuable.
A tool boundary is sufficient and no DSH-specific UI or lifecycle extension is needed.

The combined pattern

Many integrations use both: the DSH MCP client is itself a native plugin, while each connected MCP server supplies portable tools. Configure one bridge instance per server and give each a unique serverName.

cordis.yml

- id: mcp-example
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: example
    transport: stdio
    command: npx
    args: ['-y', '@example/mcp-server']

Security is not automatic at either boundary

A native plugin is trusted code in the DSH process. The official CLI reference also warns that an MCP server command is trusted executable code outside the agent sandbox. Review the package, pin versions, restrict credentials, and expose only the tools you need.

DeepSeek Harness is in developer preview. Recheck official documentation and plugin evidence when the host version changes.

Official sources

These primary sources were used to verify the technical details in this guide.