Turning DSH plugins into MCP tools for any agent

[bobleer]

Turning DSH plugins into MCP tools for any agent

DeepSeek Harness makes the internals of an agent replaceable through plugins. That raises a second question: should those plugins only be usable from a DSH process, or can an existing MCP-capable agent discover and use them without adopting DSH as its whole runtime?

We built deepseek-harness-plugin-mcp to test the latter design.

Disclosure: I contribute to BitFun and this bridge is an early BitFun-side experiment. It is not an official DeepSeek component. The source and CI are public, but the npm package is not published yet; treat it as source preview rather than a one-command install.

The bridge is three different control planes

“Expose plugins through MCP” sounds like one adapter. In practice it has three responsibilities with different risk levels.

1. Catalog: discover without executing

The default plane reads repositories carrying the dsh-plugin GitHub topic, caches a small catalog, and exposes MCP tools/resources for search and inspection.

An MCP agent can ask:

• Which DSH plugins appear relevant to a task?
• Is this repository an installable Cordis bundle, an MCP server, a UI extension, or only a directory?
• What install spec would DSH accept?
• What does the repository declare before anything touches a local profile?

This plane is intentionally useful on its own. Discovery should not imply installation, and a repository description is not proof of runtime compatibility.

Source trail:

• src/github/catalog.ts
• src/plugin/inspect.ts
• src/plugin/classify.ts
• src/mcp/resources.ts

2. Profile: mutate only after an explicit opt-in

Installation and removal are disabled by default. dsh_plugin_install and dsh_plugin_uninstall only become active when the operator passes --allow-install or the matching environment flag.

The bridge delegates mutation to the official dsh plugin --profile ... command instead of editing profile files by hand. It then reads the installed profile back and returns the observed bundle/dependency state.

That does not make installation “safe by definition.” It makes the mutation boundary visible and gives the caller a place to attach policy. A proper next step is an auditable install receipt: resolved source commit, profile diff, installed/skipped tools, requested capabilities, first health check, and an exact rollback action. We opened that work publicly in issue #1.

Source trail:

• src/config.ts — allowInstall: false by default
• src/profile/dsh-cli.ts
• src/mcp/control-tools.ts

3. Runtime: mirror a live DSH tool registry into MCP

Runtime bridging is a separate opt-in (--allow-runtime). The host creates a dedicated DSH profile, starts a DSH process, asks the live runtime for its tool schemas, and mirrors compatible tools under deterministic dsh__* MCP names.

The important direction is not “translate JSON Schema once.” The live DSH registry remains the execution owner:

MCP agent
  → dsh__tool_name
  → bridge lookup + argument forwarding
  → live DSH ctx.tools.execute(...)
  → DSH policy / execution / result pipeline
  → MCP result

Calls therefore stay inside the DSH tool runtime rather than importing arbitrary plugin executors into the MCP server process.

Not every plugin becomes a tool. UI, TUI, theme, or configuration-only plugins may be catalogued and installed, but they have no model-callable runtime surface to mirror. The server says this explicitly instead of pretending that “plugin” and “tool” are synonyms.

Source trail:

• src/runtime/host.ts
• src/runtime/bridge.ts
• src/mcp/server.ts
• src/dsh-plugin.ts

Why this matters for BitFun

BitFun already supports MCP as one of its extension layers. DSH explores a deeper, highly composable plugin graph. An MCP bridge lets us test a useful middle path:

• BitFun can keep its desktop, remote-control, permission, session, and workspace product boundaries;
• DSH can remain the owner of a plugin composition and its runtime tools;
• MCP becomes the interoperability boundary instead of forcing either runtime to be rewritten inside the other.

The same boundary is available to other MCP-capable agents. The experiment is deliberately not BitFun-exclusive.

This is also why we should not market it as “BitFun now supports every DSH plugin.” The accurate claim today is narrower: the source implements catalog, profile, and opt-in runtime planes; compatible live DSH tools can be mirrored as MCP tools; packaging, install receipts, compatibility evidence, and broader testing still need work.

What we need to prove before calling it production-ready

1. Immutable provenance — resolve a repository or package spec to the exact source revision used.
2. Capability evidence — show what a plugin mounts, which tools appear, and which surfaces cannot be bridged.
3. Mutation receipts — record profile changes and a tested rollback path.
4. Permission preservation — demonstrate that bridged calls cannot bypass DSH or host policy.
5. Cancellation semantics — define how MCP cancellation reaches DSH and the underlying tool.
6. Name stability — keep dsh__* projections deterministic across reloads and collisions.
7. Compatibility snapshots — test against a named DSH revision, because DSH is currently a developer preview.

Until those are covered, this is an architecture experiment with real code—not a mature package.

Repository: https://github.com/bobleer/deepseek-harness-plugin-mcp

BitFun: https://github.com/GCWing/BitFun

If this interoperability direction is useful, star the repository you want us to harden and leave a concrete plugin/agent combination to test. Specific compatibility reports are more valuable than generic feature requests.