Introduction

Connecting to an MCP server for DeepSeek Harness (hereinafter dsh) has two main paths: the official @deepseek-ai/dsh-mcp-client and the community implementation dsh-mcp-adapter. The most direct path is the official @deepseek-ai/dsh-mcp-client: it connects to the server at startup and registers each declared tool as a native mcp__<server>__<tool> function. The cost is schema overhead—when there are many servers, hundreds of tool definitions enter the context with every request, regardless of whether they are used in that round.

dsh-mcp-adapter is an alternative approach for this problem: it only registers a single mcp proxy tool. The server starts lazily, and the model searches/describes/calls on demand. DSH’s philosophy is “everything is a plugin,” and this plugin is a community implementation under this philosophy. Below is an introduction to its positioning, core features, configuration methods, and notes.

What is it

dsh-mcp-adapter is a dsh plugin developed by NexusAgentX. Current version 0.6.3, MIT license, requires Node >= 20. It inherits the contract of pi-mcp-adapter (MIT) in its design, and the repository includes a NOTICE file.

It is an independent plugin and has no affiliation with DeepSeek AI. One-sentence positioning: it replaces full MCP schema registration with a proxy tool, trading context overhead for on-demand search, describe, and call.

Core Design

Single Proxy Tool

The plugin only registers a single mcp tool with the model. Actions are distinguished by parameters: search finds tools, describe views a tool’s schema, and tool plus args performs the actual call. There is always only one tool definition in the context; the schema cost changes from “request × all tools” to “fetch only when called.”

Lazy Startup and Metadata Caching

Servers are not all connected at startup. The lifecycle supports lazy (default) / eager / keep-alive / lazy-keep-alive; idleTimeout controls how long an idle server stays open, in minutes (default 10). Setting it to 0 disables it.

Paired with lazy startup is metadata caching: before a live connection is established, search can be used. The model can find the tool name first, then decide whether to connect.

Two-Faced Plugin

This is a two-faced plugin: the Host side registers tools and commands, while the Web client provides the /mcp modal and MCP tool cards. The cards use the same DisclosureRow / StateDot / SearchBlock components as the official Skill / Tool rows, ensuring visual consistency.

Installation and Activation

  1. Execute the official installation command:
dsh plugin --profile web add dsh-mcp-adapter
  1. Restart dsh web and perform a hard refresh in your browser. At this point, the Host-side tools and commands, and the Web-side /mcp modal are in place.

  2. Type /mcp in the Chat input box to enter the configuration menu.

A common pitfall to note in advance: under Settings → Plugins, there is no MCP form. Official plugin settings are an allowlist, and external plugins cannot register cards there. The only configuration entry points are the Web’s /mcp menu or directly editing a JSON file.

Configuration Methods

Web /mcp Menu

In the menu, you can view Status / Sources / Prompts; perform connect, OAuth authorization, disable, or remove on existing servers; and five built-in presets are written to the project .mcp.json with one click: DeepWiki, Context7, Notion, GitHub, Chrome DevTools.

Adding a custom server also happens here; write to the project .mcp.json and reload within the process:

/mcp add docs url=https://mcp.example.com/mcp
/mcp add fs command=npx args=-y,@modelcontextprotocol/server-filesystem,/tmp

Or use presets directly:

/mcp add-preset <deepwiki|context7|notion|github|chrome-devtools>

File Configuration

To share the same batch of servers with other MCP hosts (such as Cursor), directly write the standard .mcp.json:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@1.6.0"]
    }
  }
}

The plugin supports multi-level file discovery, with later-read files taking priority:

File Purpose
~/.config/mcp/mcp.json User global shared configuration
~/.agents/mcp.json / ~/.agents/mcp/mcp.json User global tool-agnostic configuration
.mcp.json Project-level shared configuration (Web add/remove writes here)
$DSH_HOME/mcp.json dsh global override (default ~/.dsh/mcp.json)
.dsh/mcp.json dsh project override

/mcp disable and /mcp enable only write the disabled field to .dsh/mcp.json and do not copy credentials.

Host Config Discovery

The plugin can detect configurations for hosts like Cursor / Claude Code / Codex / OpenCode / Windsurf / VS Code (detected by dsh-mcp-adapter init and /mcp list), but they are not loaded by default. To enable them, set settings.hostConfigDiscovery to "on", or list them in imports:

{
  "imports": ["cursor"],
  "settings": {
    "hostConfigDiscovery": "off",
    "toolPrefix": "server",
    "idleTimeout": 10
  },
  "mcpServers": {}
}

Server-Level Options

Each server can be configured separately for lifecycle, filtering, and authentication:

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["-y", "some-mcp-server"],
      "lifecycle": "lazy",
      "idleTimeout": 10,
      "requestTimeoutMs": 30000,
      "directTools": ["search"],
      "includeTools": ["search", "get_*"],
      "excludeTools": ["admin_*"],
      "searchKeywords": {
        "search": ["find", "lookup"]
      }
    }
  }
}

A few fields worth mentioning separately:

  • directTools: true or a list of tool names; promotes hot-path tools to native dsh tools, allowing high-frequency tools to bypass the proxy hop;
  • includeTools / excludeTools / searchKeywords: Tool filtering, supports glob and search keywords;
  • approveTools: true or glob; tools that match require confirmation in the Chat Ask dialog before execution;
  • socket: rmcp-mux Unix domain socket, mutually exclusive with command / url.

Authentication and Transport

The transport layer uses Streamable HTTP, automatically falling back to SSE on 404 / 405. There are two authentication methods: tokens for OAuth are stored in the OS credential store; bearer tokens are configured via bearerToken / bearerTokenEnv.

The OAuth flow on the model side is driven by two actions:

mcp({ action: "auth-start", server: "notion" })
mcp({ action: "auth-complete", server: "notion", args: { redirectUrl: "..." } })

In the Web menu, you can also initiate Authorize directly for a single server.

Model-Side Usage

After installation, the model-side interface is concentrated in a single mcp tool. A typical sequence is to search, then describe, and finally call:

mcp({ search: "screenshot" })
mcp({ describe: "chrome-devtools_take_screenshot" })
mcp({ tool: "chrome-devtools_take_screenshot", args: { format: "png" } })

Use connect when a pre-connection is needed:

mcp({ connect: "chrome-devtools" })

args can be a JSON object or a JSON string.

Two advanced capabilities:

  • mcpScript: Loop, search, and call multiple MCP tools within a single JavaScript request, suitable for scenarios where multiple steps are chained in a single request;
  • MCP prompts: mcp({ prompt: "create_plan", server: "agent-board", args: "harden retry policy" }).

CLI and Human-Machine Commands

The standalone CLI provides two subcommands:

dsh-mcp-adapter init
dsh-mcp-adapter status

init detects each host’s configuration, and status views the plugin and server status.

The complete list of Chat-side /mcp command family: /mcp, /mcp status, /mcp list, /mcp json, /mcp setup, /mcp prompts, /mcp add-preset, /mcp add, /mcp connect, /mcp auth, /mcp enable, /mcp disable, /mcp remove.

Applicable Scenarios and Notes

Suitable scenarios:

  1. Connecting multiple MCP servers but not wanting all tool schemas to reside permanently in the context;
  2. Wanting to share the same .mcp.json with other hosts;
  3. Sensitive tools require manual confirmation before calling (approveTools);
  4. A few high-frequency tools that wish to use the native path (directTools).

Notes:

  1. Do not connect the same batch of servers as @deepseek-ai/dsh-mcp-client, as this will cause double connections and name conflicts;
  2. Host-specific configurations are not loaded by default; you need to explicitly enable hostConfigDiscovery or write to imports when needed;
  3. elicitation / sampling / MCP UI apps are not yet supported in the dsh host;
  4. The plugin runs with the permissions of the current dsh process; it is recommended to check the repository source code and license before installation—this project is MIT, code is hosted on GitHub.

Following the above steps, a dsh instance can connect to any number of MCP servers on demand, with only one mcp tool definition remaining in the context. This is the core value of this plugin.

Links

  • GitHub: https://github.com/NexusAgentX/dsh-mcp-adapter
  • Community Directory Page: https://www.skillhub.cn/plugins/NexusAgentX/dsh-mcp-adapter (The community directory is an independent site and has no official affiliation with DeepSeek / Hintai)