Introduction

In the DeepSeek Harness (DSH) plugin ecosystem, when the tool catalog becomes large (for example, when integrating multiple MCP servers or many plugin tools), the JSON schema for each tool is injected into the model context in every conversation turn. This can cause a large amount of irrelevant token consumption and reduce inference efficiency. dsh-tool-search is designed to address this issue. It adopts the “progressive disclosure” design philosophy of Hermes Agent, folds long-tail tools in the background, and loads them on demand through only three bridge tools, thereby controlling the size of the model-visible catalog.

Installation

Installing this plugin requires the DSH command-line tool. Run the following command in the terminal:

dsh plugin --profile web add dsh-tool-search

Core Capabilities

The core functionality of this plugin revolves around “on-demand visibility” and “core retention”:

  1. Tiered disclosure: Dynamically adjusts the tool list visible to the model based on the current context window budget and the size of the tool catalog.
  2. Bridge tools: Provides three bridge interfaces, tool_search, tool_describe, and tool_call, to replace the original lengthy tool catalog.
  3. Eager loading: File operations, Shell execution, and core required tools are always visible directly and do not need to be folded.
  4. Dynamic injection: After a tool is searched or invoked, that tool is injected into the visible context (subject to an LRU limit) so it can be used directly in subsequent turns.

How It Works

The plugin listens for the system-prompt/assemble event to calculate the “tier” and replaces the visible tool list for the model.

Tier logic depends on the budget calculation, using the formula min(thresholdPct% × contextWindow, listingMaxTokens), and is recalculated in every conversation turn:

  • Tier 0: All tools are directly visible when the catalog is small or there are no foldable tools.
  • Tier 1: When the grouped catalog fits within the budget, the bridge tools and group titles and descriptions (## group) are displayed.
  • Tier 2: When only tool names fit within the budget, only the bridge tools and the list of names are displayed.
  • Tier 3: When the names also overflow, only the bridge tools are displayed, with one line per group (such as group_name: 5).

Dynamic execution: When tool_call is invoked, the plugin executes the real tool through ctx.tools.execute, not the bridge tool. This means approval mechanisms, guardrails, and session events still reference the original tools, not the bridge layer. Search uses the configured reranker by default; if it fails or is not configured, it falls back to keyword matching (exact name > name fragment > description fragment).

Conversational Setup

The plugin includes the built-in tool-slimmer-setup skill, which supports completing configuration through conversation. You can directly make the following request to the Agent to start the setup process:

Help me configure the tool groups for dsh-tool-search

This skill reads the catalog, proposes a grouping plan, guides you to choose global or project-level configuration after confirmation, and helps configure the reranker.

Configuration

Configuration is divided into static configuration (effective after restart) and runtime configuration (hot reload).

1. Static configuration
Static configuration is located in the profile’s cordis.patch.yml file:

- id: tool-search
  config:
    enabled: auto        # auto | on | off
    thresholdPct: 5      # 清单预算占上下文窗口的百分比
    listingMaxTokens: 4000
    configScope: auto    # user | project | auto (项目文件优先)
    core: [todo_write]   # 额外的始终急切工具
    maxWarmTools: 8      # 动态注入工具 LRU 上限

2. Runtime configuration
Tool groups, matchers, and preload settings are stored in the runtime file. The user-level path is ~/.dsh/dsh-tool-search.json:

{
  "version": 1,
  "scope": "user",
  "groups": [
    { "name": "git", "tools": ["git_status", "git_diff"] },
    { "name": "mcp-github", "prefixes": ["mcp_github_"] }
  ],
  "matcher": {
    "endpoint": "https://dashscope.aliyuncs.com/compatible-mode/v1/rerank",
    "apiKey": "sk-...",
    "model": "qwen3-reranker",
    "topN": 20
  },
  "preload": { "enabled": false, "topK": 5 },
  "core": ["read_file", "write_file"]
}
  • groups: Exact tool names or prefixes; matching priority depends on the definition order.
  • matcher: It must be an OpenAI-compatible /v1/rerank endpoint; otherwise, the search functionality is unavailable.
  • preload: Optional feature. When enabled, it preloads the K semantically most relevant tools in the first conversation turn.
  • The file supports mtime monitoring; changes take effect in the next conversation turn.

Bridge Tools

The plugin provides three main bridge tools for the model to call:

Tool Name Function
tool_search(query, limit?) Searches the deferred catalog (using reranking or keyword fallback), returns ranked results, and injects them into the visible context.
tool_describe(name) Loads the complete schema of a single deferred tool and injects it into the visible context.
tool_call(name, arguments) Executes the call using the real tool name and injects the tool into the visible context.

Applicable Scenarios and Notes

This plugin is suitable for DSH projects with a large number of third-party tools or MCP servers. Before using it, please confirm the following points:

  1. Permissions: The plugin runs with the permissions of the current DSH process. Check the source code and license before installation.
  2. Registry integrity: Slimming only rewrites the model-visible surface; the underlying registry remains complete, and deferred tools can still be executed normally.
  3. Reranking priority: Keyword matching is only a fallback; core search relies on the reranking model.
  4. Context dependence: The catalog is based on the runtime context and can adapt to the full prompt composition.

References