Cordis, MCP and Skills

How the three concepts differ, and the DeepSeek Harness support matrix for MCP, Skills and Plugins

People often compare Cordis, MCP and Skills with each other. They are actually concepts at three different layers, each with a clear role inside DeepSeek Harness. This page first compares the concepts, then gives the DSH support matrix.

One-line positioning

Concept	What it is	Problem it solves
Cordis	A plugin framework (meta-framework)	How to split software into composable, replaceable plugins with managed lifecycles
MCP	An open protocol standard (Model Context Protocol)	How model apps talk to external tools and data sources over a uniform protocol
Skills	Reusable instruction and capability packs	How to package domain best practices into on-demand "skills"

An analogy

Cordis is the socket-and-circuitry standard — how each part plugs in and unplugs; MCP is the USB protocol — how peripherals communicate; Skills are toolkits — a packaged set of practices you pull out when needed. They are not mutually exclusive: both Skills and the MCP bridge mount into DSH as plugins (Cordis).

Detailed comparison

Dimension	Cordis	MCP	Skills
Nature	Composition model + runtime	Wire protocol specification	Instruction/capability pack
Granularity	Plugins, services, events	Servers, tools, resources	One skill (SKILL.md + assets)
Implemented by	Vendored inside DSH	Various vendors' servers/clients	Community and official
Language	TypeScript ecosystem	Language-agnostic (JSON-RPC)	Tied to the agent runtime
Role in DSH	The base that carries every capability	External tools bridged in via a plugin	Built-in registry + on-demand loading

DSH support matrix

Cordis: native

DSH vendors Cordis; the model adapter, tool registry, session log, and agent loop are all plugins. See the Cordis primer.

MCP: supported (client bridge)

DSH connects to external MCP servers through the @deepseek-ai/dsh-mcp-client bridge plugin: it connects to a server and registers its tools on ctx.tools, where the model calls them as mcp__<serverName>__<rawName> — the same server-qualified naming Claude Code and Codex use.

Supported scope

Transports: stdio (local subprocess) and streamable-http (remote URL);
One plugin instance per MCP server, configured in cordis.yml;
HMR hot-swap and automatic reconnection with exponential backoff;
The documented bridge plays the MCP client role (pulling external server tools in); exposing DSH itself as an MCP server does not appear in the upstream docs.

Configuration example:

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-github']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

Skills: native

DSH ships a skill registry and loader; the agent loads specialized skills on demand (e.g. code-review, astro), each organized as SKILL.md plus an asset directory. See Skills & Goals.

Plugins: native

Third-party plugins install into a profile via dsh plugin; see plugin ecosystem;
Runtime dynamic plugins mount new capabilities without source edits or restarts; see dynamic plugins.

How the three relate

How to choose

To extend the agent's abilities: prefer Skills (packaged practices) or plugins (packaged capabilities);
To reuse the existing MCP ecosystem: bridge with dsh-mcp-client instead of rewriting;
To understand or modify DSH itself: start from the Cordis composition model.

Cordis primer · Dynamic plugins · Registering tools
Skills & Goals · Plugin ecosystem

Cordis, MCP and Skills

On this page