Introduction¶

When using DeepSeek Harness (DSH), connecting multiple MCP (Model Context Protocol) servers causes the tool list to bloat. Injecting all of these tools consumes a large number of tokens, and repeated updates to the tool list break the cache. dsh-mcp is a client plugin designed to address these issues: it provides a visual management interface, supports on-demand tool search and hot injection of tools, and keeps the tool list stable to maximize cache hit rates.

Core Features¶

The plugin includes the following core capabilities:

1. Visual management: Manage the server list in Settings → MCP, with support for creating, editing, deleting, testing connections, starting/stopping, and refreshing.
2. Tool-level fine-grained control: Expand each server to view its tool list. All tools are selected by default; you can uncheck tools to load only the ones you need.
3. Process-level environment variables: Supports global key-value configuration. For streamable-http servers, you can use the ${变量名} syntax in request headers; the configured value is substituted automatically on connection (for example: Authorization: Bearer ${TOKEN}).
4. Dual injection modes: Provides search (on-demand tool search, saving tokens) and full (inject all tools) modes.
5. Transparent pass-through of image results: Images returned by MCP tools are projected into the model context as references via the attachment service, with preflight checks and fallback text.
6. Zero npm dependencies: Directly integrates DSH internal capabilities.
7. OAuth authentication support: Supports the authorization code + PKCE flow, with automatic token refresh (automatically renewed if active within 24 hours).
8. System certificate validation: HTTPS connections are validated against system certificates by default; no extra configuration is required.

Installation and Enablement¶

The installation command is as follows:

dsh plugin --profile web add github:ArvinQi/dsh-mcp

Supported version: dsh 0.2.0-rc.2.

After installation, the plugin automatically registers as the bundle layer of the profile. Restart dsh web, then go to Settings → MCP to open the visual management page.

Configuration and Usage¶

On the Settings → MCP page, you can perform the following operations:

1. Declarative server takeover:
   DSH natively supports declaring MCP servers in cordis.patch.yml. The plugin reads these declarations.

   • Declaration priority: If a server with the same name is already declared in cordis.patch.yml (and not disabled), the plugin will not mount a same-name row, to avoid tool registry conflicts.
   • Takeover/release: After clicking “Take Over”, the plugin writes disabled: true within the managed block, releases the serverName, and then the plugin row takes over mounting, enabling features such as OAuth and credential management. Clicking “Release” hands control back.

2. OAuth authentication:
   OAuth is an explicit toggle. The OAuth provider will only be mounted when “Use OAuth authorization” is checked on the settings page.

   • It will not be mounted automatically if unchecked.
   • Before authorization, only “Authorizing” is displayed; if authorization fails, the reason will be shown.
   • Authorization is initiated by a button on the settings page; the host opens the system browser to complete it, and this page polls the status every 5 seconds.

3. Tool Search mode:
   In search mode, the model hot-injects required tools through mcp_tool_search, substantially saving tokens. The tool list stabilization mechanism ensures unchanged tools retain their original registration, maximizing cache hits.

Applicable Scenarios and Notes¶

• Applicable scenarios: Scenarios requiring fine-grained control of multiple MCP servers, saving token consumption, or handling complex authentication (OAuth) or intranet HTTPS certificate validation.
• Notes:
  • The plugin runs with the permissions of the current dsh process. Please review the source code and license (MIT) before installation.
  • On upgrade, the plugin automatically migrates existing OAuth credentials.
  • For servers using static tokens, do not check the OAuth option; otherwise, they may be mistakenly identified as OAuth challenges.