DSH plugin vs skill vs MCP: DeepSeek Harness extensions

A DSH plugin, a skill, and MCP are three extensions at different levels, not competitors at the same layer: a plugin is an installable unit, a skill is an instruction the model loads on demand, and MCP is a protocol that links external tools and data sources (source). This guide is a side-by-side comparison across three directions: what each one is, where the boundaries overlap, and the rule for choosing plus where each one lives.

Overview: one table to tell a DSH plugin, a skill, and MCP apart

Hold on to a single thread: a plugin is what gets installed, a skill is what gets written for the model, and MCP is the door that connects outward. Positioning at a glance:

Once this table clicks, the other two directions—where the boundaries are and how to choose—follow naturally.

What each DSH plugin, skill, and MCP is: the carrier, the instruction, the connection

Give each a single sharp label first, then talk about overlap.

1. DSH plugin = the installable extension unit. It registers tools and commands in apply, declares its own settings namespace, and carries its dependencies; dsh plugin installs it into a profile, and it stays uninstallable, updatable, and attributable (source). Expected: a manageable entry appears in the installed list. For what is inside one, see What is inside a dsh plugin.
2. skill = an instruction the model loads on demand. The key fact is that it is an optionally loaded instruction, not a session event, so its type definition is not in core; providers register local or bundled skills into ctx.skills, and the model-facing skill tool loads them by working directory (source). Expected: the model pulls the instruction when needed instead of keeping it pinned in context. For usage details, see How to use DeepSeek Harness Skills.
3. MCP = a protocol link to external tools and data sources. DeepSeek Harness consumes MCP servers through the @deepseek-ai/dsh-mcp-client package: locally via transport: stdio with a command, remotely via streamable-http with a URL, and every server tool is exposed as mcp__<serverName>__<tool> (source). Expected: tools prefixed with mcp__ show up in the tool list. For configuration, see How to add a memory plugin via MCP.

Where the boundaries overlap: what to build as a DSH plugin, a skill, or MCP

When you are unsure, cut along one axis—does it actually execute or connect—and the boundary becomes obvious.

• It must register tools or commands, be reused, and be installable by others → make it a DSH plugin. It is the only one with a distribution shape: a package name, a version, install and uninstall.
• It only needs the model to remember "when you hit this kind of work, follow this" → write a skill. It adds no process, is light, travels with the workspace, and suits codifying operating rules and team conventions.
• You already have an external service, database, or API to reach → go through MCP. Do not rewrite an existing service into a plugin; wiring it in by protocol is less work, and its tools attach to the model side automatically.

The three are not mutually exclusive. In practice a plugin is the shell and skills and MCP are the content: one plugin can register tools in apply, ship a bundled skill, and act as an MCP client to reach a service. What you install from the marketplace is a plugin; it may bring you a skill and may connect you to an MCP server. The reverse does not hold—a skill or an MCP server is not an independently installable distribution unit (skills come with a provider, MCP with client config), which is exactly why they sit at different levels.

How to choose between a DSH plugin, a skill, and MCP: one rule and where each one lives

The rule: to add a capability look for a plugin, to add an instruction write a skill, to connect outward use MCP. In practice:

1. A reusable tool or command → find a plugin. Search DSH Plugin Hub for an existing implementation and install it rather than writing your own. Expected: an entry shows up in the marketplace and installs in one click.
2. A "how this kind of work is done" instruction → write a skill. Turn the steps and conventions into a document the model loads on demand, so you never restate it. Expected: the model pulls it in when needed, without pinning context.
3. An external service or data source → configure MCP. Prefer an existing official or community server and add an entry in plugin config. Expected: mcp__-prefixed tools appear in the tool list.

Management actually converges in one place: plugins are installed and configured in the marketplace and settings, skills are usually viewed in plugin settings or the workspace directory, and MCP servers appear as entries in plugin config—all under the plugin system, so you do not need three separate UIs.

Notes on using a DSH plugin, a skill, and MCP

1. Do not treat MCP as a plugin: MCP is a protocol link, not a distribution unit; what you install is the client plugin that carries it, not "an MCP".
2. A skill is not a plugin: a skill comes with a provider or workspace and cannot be installed or removed on its own, so do not expect to find it alone in the marketplace.
3. Keep the core term intact: in English write DSH plugin or "DeepSeek Harness plugin"; avoid dropping DSH in as a standalone noun.
4. Check permissions: MCP spawns a child process or connects to a remote address, so confirm its command and network boundary before installing and never allow an unknown server.
5. Ask about the need before choosing: capability, instruction, and connection needs belong to different layers, and picking the wrong one multiplies maintenance cost later.

Sources: DeepSeek Harness Docs - Your first plugin, DeepSeek Harness Docs - Skills, DeepSeek Harness Docs - MCP memory