Introduction

DeepSeek Harness (DSH) extends its capabilities through a plugin mechanism. In particular, dsh-mcp-client globally registers the tools installed from MCP servers at the deployment scope. When numerous MCP servers are installed, every request must process the schema definitions for all tools. This creates fixed overhead and produces a large tool list, making it difficult for the model to choose the correct tool among many options.

dsh-mcp-loader is designed to address this issue. It introduces a loader tool for each multi-tool MCP server, and the real tools enter the model context only when the loader is invoked. This removes the fixed cost of tool schemas in every request and keeps the visible tool list concise.

Plugin Overview

  • Name: mikotomywife/dsh-mcp-loader
  • Maintainer: MikotoMyWife
  • Positioning: A lazy-loading plugin for DSH MCP tools, supporting per-session masking and description engineering.
  • License: MIT
  • Core Value: Reduce token consumption, optimize the tool list, and improve the model’s selection efficiency in multi-MCP-server scenarios.

Core Features

The plugin provides the following capabilities:

  1. Per-server loader toggle
    Each multi-tool server is represented by a single loader tool (named mcp_<server> by default). Invoking the loader can load, hide, or reload the real tools. The loading state is isolated per session: loading in one session is not visible to other sessions.

  2. Operating modes

    • auto: At startup, it checks the number of server tools once; servers with fewer tools than the threshold (singleToolThreshold) are kept resident, while others are registered behind a loader.
    • lazy: Servers are always hidden behind a loader and loaded only when invoked; no probing is performed at startup.
    • eager: Servers are kept resident and the loader is not used.

  3. Per-agent tool masking (hiddenTools)
    After a server is loaded, specific tools can be masked. Masking is implemented using restrict({ deny }) and supports exact names, public names (such as mcp__notes__*), and wildcards (such as e*, ?). Masking only affects visibility; tools remain globally registered.

  4. Globally disabled tools (disabledTools)
    Matching tools are discarded directly at the registration layer, making them invisible to any agent. Wildcard rules are also supported.

  5. Description engineering
    It supports description overrides per server or per tool, as well as truncation of parameter descriptions (maxParameterDescriptionChars). The instructions sent by a server are presented as attribution text in the loading result, instead of permanently occupying tokens in the loader description.

  6. Environment cleanup and resource bridging

    • The child-process environment removes credential-like keys (such as /KEY|PASSWORD|SECRET|TOKEN) and DSH_* facts, while preserving environment variables such as PATH and NPM_CONFIG_*.
    • An optional Resource Bridge is supported, exposing resources from loaded servers to the Harness resource service.

  7. Fault tolerance and boundaries

    • Atomic registration: on failure, roll back to zero tools.
    • Hard limits: maxToolListPages, maxToolsPerServer, and discoveryTimeoutMs are enforced; loading that times out or exceeds the limits fails, while the loader remains available.
    • Ordered resynchronization: prevents concurrent loading from causing stale data to overwrite newer data.

Installation and Build

The plugin depends on a Node.js environment and @modelcontextprotocol/client 2.0.0.

  1. Clone the repository and install dependencies:
npm install
  1. Compile the code:
npm run build
  1. Configure the plugin:
    Based on the configuration in package.json, the plugin is mounted via cordis.patch.yml.

Typical Usage

The workflow is as follows:

  1. Initial state: The tool list shows only loader tools (for example, mcp_notes, mcp_browser).
  2. First invocation: The model calls mcp_notes({}). The system returns ok and exposes the real tools in the current session and its sub-agents (for example, mcp__notes__search).
  3. Second invocation: The model calls mcp_notes({}) again. The system returns ok (N tool(s) hidden), hiding the real tools.
  4. Third invocation: The model calls mcp_notes({}). The system reloads and exposes the real tools.

For single-tool servers (those with a tool count below the threshold), the server is kept resident at startup and does not go through the loader workflow above.

Notes

  • Node version: The plugin requires Node.js >=20.
  • Registration scope: Tool registration is at the deployment scope (global), consistent with the official dsh-mcp-client. hiddenTools filters visibility per session on top of the global registration.
  • Session isolation: Visibility is per session. The loading state in one session does not affect other sessions.
  • Single-tool threshold: Setting singleToolThreshold: 0 forces all servers to use the per-session loader mode.
  • Permission security: The plugin runs with the permissions of the current DSH process. Review the source code and license before installing.

Conclusion

dsh-mcp-loader addresses context bloat in DSH when integrating many MCP tools through lazy loading and per-session masking. It preserves global tool registration while optimizing the model’s usage experience through fine-grained visibility control.