DSH Plugins vs Skills vs MCP

Three different extension points

The names are often used interchangeably because all three can make an agent more capable. The practical difference is where the behavior lives. A plugin is a runtime package managed by a DSH profile. A Skill is guidance that shapes how an agent performs a task. MCP is a transport and capability protocol between an MCP client and an external server.

A useful rule is to start with the smallest boundary that can own the behavior. Use instructions for judgment and procedure, a protocol for a service that should be shared by multiple clients, and a plugin when DSH itself needs a packaged runtime capability.

The boundary affects more than installation. It determines who owns versioning, where credentials live, how failures are observed, and which other clients can reuse the capability. Naming that owner before you build prevents a local instruction from quietly becoming an unmaintained service.

Plugins: packaged runtime capability

A DSH plugin is installed into a profile and discovered through its dsh.bundle manifest. It can register model providers, tools, memory backends, interfaces, or lifecycle hooks. Because it runs inside the harness boundary, it can participate in startup, configuration, and the agent loop.

Choose a plugin when you need a reusable implementation with a version, dependency boundary, and predictable activation step. Plugins are a good fit for functionality that should be available to every task in a profile, not only when a particular instruction is present.

A plugin also gives DSH a place to report compatibility and startup state. That is useful when a capability has dependencies or needs an initialization hook. The trade-off is real: code that runs inside the harness can see the permissions granted to that profile, so package review belongs in the installation workflow.

• Best for Runtime integrations, packaged UI, model adapters, memory, and capabilities that need lifecycle hooks.
• Trade-off Installation and permissions are broader because code becomes part of the running harness.

Skills: reusable instructions

A Skill is a set of instructions, examples, and decision rules that an agent can apply to a task. It changes behavior through context rather than by loading new runtime code. A Skill can teach an agent how to review a pull request, format a report, or call an existing tool safely.

Choose a Skill when the capability is primarily procedural or editorial. Skills are easy to version and review as text, and they usually have a smaller permission surface. They cannot create a new network service or replace a runtime implementation on their own.

A useful test is to remove the Skill and ask whether the runtime still has the necessary tool. If the answer is yes and only the decision process changes, a Skill is probably the right first move. Keep instructions concrete: name the tool, the inputs, the approval rule, and the evidence that should be returned.

• Best for Workflow guidance, domain conventions, checklists, and repeatable reasoning patterns.
• Trade-off The agent can only use capabilities that already exist in its runtime or connected tools.

MCP: a protocol boundary

Model Context Protocol (MCP) gives an agent a standard way to discover and call tools, read resources, and use prompts exposed by an external server. The MCP server owns the integration; the client owns the conversation and decides when a capability is available.

Choose MCP when a service should be shared by more than one agent or editor, or when you want the integration to run outside the DSH process. The protocol boundary can improve isolation, but it also adds a server lifecycle, authentication, network, and compatibility surface to operate.

MCP is strongest when the data or action already has a service owner. The server can enforce authorization, rate limits, and audit logs for every client, while the DSH profile only decides whether to connect. That separation is valuable, but only if the endpoint, transport, and credential rotation are treated as production concerns.

• Best for Shared services, remote data, external systems, and integrations used by multiple MCP-capable clients.
• Trade-off You operate another process or endpoint and must secure its transport and credentials.

Side-by-side comparison

How to choose

Answer these questions in order. The first clear answer usually points to the right boundary.

For example, a checklist for reviewing pull requests is a Skill; a shared issue tracker integration is an MCP server; a memory backend that must load during DSH startup is a plugin. If the answer is still unclear, write down the data flow and failure owner before selecting a package.

• Is the missing piece an instruction? Start with a Skill when the agent knows the tools but needs a better procedure or domain rule.
• Must another client use it? Prefer MCP when the capability belongs to a shared service rather than one DSH profile.
• Does DSH need new runtime behavior? Use a plugin when the integration must participate in startup, configuration, or the agent loop.
• Could two boundaries work together? Combine them deliberately: a plugin can expose a local capability, an MCP server can provide remote data, and a Skill can teach the agent when to use either one.

They can work together

These are not mutually exclusive technologies. For example, a DSH plugin can install an MCP client, an MCP server can expose a database tool, and a Skill can describe the approval steps before that tool is called. Each layer should still have one clear owner.

When a system feels complicated, draw the boundary before adding another extension. Name the process that owns the code, the data that crosses the boundary, the credentials required, and the way you will verify a failure. That small design exercise prevents a Skill from becoming an undocumented plugin and prevents an MCP server from becoming a hidden monolith.

A practical rollout can be incremental: start with a Skill to validate the procedure, move stable runtime work into a plugin, and expose a shared dependency through MCP only when another client needs it. At each step, keep the smallest working boundary and record what changed.

Use the catalog's plugin pages for the runtime layer, the installation guide for profile and bundle checks, and your MCP server's own documentation for transport and authentication. The technologies compose well when the hand-off between them is visible to the person operating the agent.