Blog · Guide
DeepSeek Harness MCP: connecting external servers to a plugin-native agent
August 14, 2026 · dshbase
Model Context Protocol (MCP) is the de facto standard for giving agents tools that live outside their process — and it's the wrong mental model for DeepSeek Harness, at least as a default. dsh isn't MCP-native the way Claude Code is; it's plugin-native, built on the Cordis kernel where a plugin is the unit of extensibility. But that doesn't mean MCP is irrelevant. The community has built clean bridges, and in some cases dsh plugins expose MCP servers of their own. Here's how MCP actually works in dsh 0.1.0-rc.6.
How MCP actually reaches the model
Mechanically, an MCP server in dsh works the same way it does anywhere: the server exposes a set of tools over a stdio or HTTP transport, and the harness surfaces those tools to the model as callable functions. What's different is the registration path. Rather than a global config, the workspace-scoped approach in dsh-workspace-mcp ties servers to a directory, so the model only sees the tools relevant to the project it's currently in. That has a real cost benefit too: every tool you expose adds tokens to the prompt and to the schema, and a project-scoped server list keeps the tool surface lean. This is the same minimal-toolset discipline that makes dsh's caching cheap, applied to external integrations.
Plugins first, MCP as an adapter
The key distinction: in dsh you normally install a plugin (dsh plugin add …) rather than registering an MCP server. A plugin runs inside the harness and can do things an external server can't — read the session log, inject context, hook the UI. MCP, by contrast, is for tools that already live in a separate process (a database, a browser, a search API). So the right question isn't "how do I turn on MCP in dsh?" but "which of my external tools should I bridge in, and which should I just install as a plugin?" The plugin directory is the fast way to check whether someone already built the plugin version of the tool you were about to MCP in.
dsh-workspace-mcp: per-project MCP servers
The most direct MCP integration in the directory is dsh-workspace-mcp. It reads <session-cwd>/.dsh/mcp.servers.yml and loads those servers for the agent, scoped to the current workspace and auto-loaded / unloaded per project. That's the ergonomic detail that matters: you declare your MCP servers in a YAML file that lives inside the project, so each repo brings its own tools with it — no global config, no servers bleeding across unrelated sessions. It's currently listed as not-on-npm in the directory (you install from source), so treat it as early but directionally correct.
Plugins that ship their own MCP server
MCP runs both directions. dsh-cowork is a doc-tools plugin — doc_read / doc_write for xlsx, pdf, docx, pptx, and ipynb — and it ships "plus an MCP server and CLI." In other words, you can use it inside dsh as a normal plugin, or point another MCP-capable client at it as a server. That dual nature is the cleanest illustration of how dsh sits relative to the MCP ecosystem: a single tool can be both a Cordis plugin and an MCP server depending on which side you call it from.
The "zero external MCP" counter-pattern
Some builders deliberately go the other way. dsh-vision-primitives is a visual-reasoning plugin that advertises "zero external MCP" — a Set-of-Mark numbered grid overlay for precise visual grounding done natively inside the plugin, with no out-of-process server to babysit. It's worth naming because it captures a real philosophy split in the community: MCP adds a second process, a second failure domain, and a second thing to keep running, so for self-contained capabilities, a native plugin is often the better engineering choice. The MCP bridge is for the tools that can't be a plugin — the ones already running elsewhere.
When to reach for MCP vs. a plugin
- Reach for a plugin when the capability is dsh-specific (memory, UI, session hooks) or self-contained (a tool that just runs code in-process).
- Reach for MCP when the tool already lives in another process you don't want to reimplement — a database, a browser automation daemon, a company-internal API — and you want it scoped per project via
.dsh/mcp.servers.yml. - Expose MCP (the
dsh-coworkpattern) when you've built something in dsh that a non-dsh client should also be able to use.
Current state
MCP support in dsh is real but still maturing. The dedicated bridge (dsh-workspace-mcp) is early and not yet on npm; the most polished MCP-adjacent plugins (dsh-cowork) use MCP as an export rather than an import. If you're coming from Claude Code and expecting a mature .mcp.json-style experience, the honest answer is: dsh's equivalent is the plugin system itself, with MCP as a targeted adapter for external processes. For the current, test-verified lineup of MCP-related and tool plugins — with exact install commands — start at the plugin directory.