
Letter2025/dsh-tool-search
30Last commit Aug 14, 2026
dsh-tool-search DSH plugin
When your tool catalog grows large, every tool's JSON schema is injected into the context on every turn, wasting tokens. This plugin collapses the long tail behind three bridge tools and lets the model discover and load them on demand via a configured rerank model. It supports tiered disclosure, conversational setup, and user or project-level configuration.
How to install the dsh-tool-search DSH plugin
dsh plugin --profile web add dsh-tool-searchCopying does not run this command. Review the repository and version before installing the dsh-tool-search DSH plugin.
dsh-tool-search DSH plugin data source
dsh-tool-search DSH plugin snapshot date: Aug 16, 2026
discovered
What the dsh-tool-search DSH plugin can do
- Keeps core tools (file/shell/essential) always directly visible in the context.
- Provides three bridge tools: tool_search, tool_describe, tool_call to defer and load long-tail tools on demand.
- Automatically adjusts visible tool listing based on token budget (thresholdPct of context window, capped by listingMaxTokens).
- Supports hot-reload of runtime configuration file (~/.dsh/dsh-tool-search.json) for groups, matcher, and preload.
- Includes a built-in skill (tool-slimmer-setup) for conversational grouping and rerank configuration.
Where the dsh-tool-search DSH plugin fits
- Reduce token consumption when using many MCP servers or plugin tools in DSH.
- Organize large tool catalogs into groups for easier management and discovery.
- Enable the model to dynamically search and load tools only when needed, preserving context budget.
- Configure tool visibility per-project vs. globally with a simple JSON file.
- Preload semantically relevant tools on the first turn using a rerank model.
Who the dsh-tool-search DSH plugin is for
- DSH users who manage a large number of tools (e.g., from MCP servers or plugins).
- Developers wanting to optimize token usage and model-context footprint in agentic workflows.
dsh-tool-search DSH plugin limitations
- Requires a configured rerank model (OpenAI-compatible /v1/rerank endpoint) for optimal ranking; keyword fallback is less accurate.
- Only supports OpenAI-compatible rerank endpoints; no other matcher types are available.
- The plugin is in early stage; see DESIGN.md for architecture details and potential pitfalls.
- Configuration changes require a restart or next turn (hot-reload supported for runtime file).
dsh-tool-search DSH plugin: from the repository README
Quoted from the Letter2025/dsh-tool-search README, the upstream source of the dsh-tool-search DSH plugin. Copyright remains with the original authors.
Tool search & slimming for [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) (DSH): Hermes-style progressive disclosure. When your tool catalog gets large (many MCP servers or plugin tools), every tool's JSON schema is injected into the model context on every turn — wasting tokens on tools the task never uses. This plugin collapses the long tail behind three bridge tools and lets the model discover and load them on demand through a configured **rerank model**. - **Core tools stay eager** — file/shell/essential tools are always directly visible. - **Bridge tools** — `tool_search`, `tool_describe`, `tool_call` replace the deferred schemas. - **Tiered disclosure** — the visible listing shrinks automatically as the catalog grows. - **Conversational setup** — the bundled `tool-slimmer-setup` skill groups your tools by talking to you, and guides configuring the rerank model. - **User or project config** — groups/matcher live in `~/.dsh/dsh-tool-search.json` (global) or `<workspace>/.dsh/dsh-tool-search.json` (per project), your choice. ## Install ```sh dsh plugin --profile web add dsh-tool-search ``` ## How it works Inspired by [Hermes Agent's Tool Search](https://
Read the full READMEThe repository declares no license. Check with the authors before using it.
dsh-tool-search DSH plugin questions
How do I configure the rerank model for dsh-tool-search?
You need to add a `matcher` section in the runtime configuration file (`~/.dsh/dsh-tool-search.json` for global, or `<workspace>/.dsh/dsh-tool-search.json` for per-project). The matcher requires an OpenAI-compatible `/v1/rerank` endpoint, including `endpoint`, `apiKey`, `model`, and `topN`. For example: `{"endpoint": "https://dashscope.aliyuncs.com/compatible-mode/v1/rerank", "apiKey": "sk-...", "model": "qwen3-reranker", "topN": 20}`. Without a configured matcher, `tool_search` will fall back to keyword matching and prompt you to set it up.
How do I group my tools using the conversational setup?
Ask your agent: '帮我配置 dsh-tool-search 的工具分组' (or in English, you can use the built-in skill). The `tool-slimmer-setup` skill will read your tool catalog, propose groups, confirm with you, and ask whether the config should be global or per-project. It will also guide you through configuring the rerank matcher. After the conversation, the groups are saved to the runtime configuration file and take effect on the next turn.
Can I use dsh-tool-search without a rerank model?
Yes, but with limited functionality. Without a configured rerank matcher, `tool_search` degrades to keyword matching (exact name match > name token match > description token match). This fallback is less accurate and may not return relevant results. The plugin will show setup guidance until a matcher is configured. It's recommended to set up a rerank endpoint for best results.
How do I enable or disable the plugin temporarily?
You can set the `enabled` config option in your profile `cordis.patch.yml` to `auto`, `on`, or `off`. The default is `auto`, which means the plugin will be active when a tool catalog is large enough. Setting it to `on` forces it on, and `off` disables it completely. You need to restart DSH for changes to take effect.
What is the difference between user-scope and project-scope config?
User-scope config is stored in `~/.dsh/dsh-tool-search.json` and applies to all projects. Project-scope config is stored in `<workspace>/.dsh/dsh-tool-search.json` and only applies to that specific project. By default, the plugin checks for a project file first; if it exists, project scope wins. You can also set `configScope` in `cordis.patch.yml` to `user` or `project` to force a specific scope.