DSH adopts a plugin-based architecture, aiming to enhance Agent operational capabilities through extensions. dsh-stool-plugin is a plugin that registers all capabilities of the stool operations CLI as DSH tools. It enables the Agent to directly invoke server management, log querying, database operations, and other capabilities, allowing operational tasks to be executed without human intervention.

The plugin is maintained by fufengyuan, categorized as workflow tools, and follows the MIT License.

Core Features

The plugin maps the stool v7.x command surface to 12 DSH tools, covering the following scenarios:

  • Server management: supports listing, testing, batch execution, health checks, diagnostics, file transfer (upload/download), directory operations, and Java process management.
  • Database and Redis: supports database listing, querying, schema viewing, data operations, and Redis command execution.
  • Log querying: supports log listing, search, real-time viewing, context reading, and history paging.
  • CI/CD: supports deployment, status viewing, rollback, history records, build logs, and tool detection.
  • Other capabilities: includes two-factor authentication code management, Git repository operations, todo and note management, project management, Nginx configuration presets and deployment, accounting statistics, weekly report generation, and operation audit.

Installation and Enablement

Installing the stool CLI on the host machine is a prerequisite for using this plugin. The installation command is:

dsh plugin --profile web add github:fufengyuan/dsh-stool-plugin

After installation, restart the DSH Web service to load the plugin:

launchctl kickstart -k gui/501/com.duormi.dsh-web

Tool Parameters and Usage Notes

The tool layer performs parameter normalization, but when invoking the underlying stool CLI, be aware of specific parameter names and limitations:

stool_todo

  • add: the due date uses -d/--due, and tags use -g/--tag.
  • edit: text modification uses -t/--text, and tags must use -g/--tag (note the difference from add).

stool_log

  • Paginating history: you must specify either the date or days parameter; the two are mutually exclusive.
  • search/tail: line-count control uses the -l parameter. For context viewing, use the context action with a line number.

stool_db redis

  • The --json parameter is not accepted.
  • Subcommands must be whitelisted; in early versions, directly splitting the command may cause errors.

stool_server upload

  • Three positional parameters are required: <ID> (server ID), <LOCAL> (local path), and <REMOTE> (remote target path).

java-restart

  • Only performs the stop operation and does not automatically restart the process.

Settings Page Detection Mechanism

On the DSH settings page, the Stool operations toolbox card automatically detects the local stool installation status:
* Detection method: the Host side retrieves the result via the GET /stool/status endpoint, which only responds to same-origin loopback requests.
* Result cache: detection results are cached for 30 seconds; forced re-detection can be triggered with ?refresh=1.
* Status feedback: if installed, the path and version number are displayed; if not installed, a download guide is displayed; if the endpoint is unavailable, it is marked as “Status Unknown”.

Dependencies and Build

The plugin depends on the following Peer Dependencies:

  • @deepseek-ai/cordis (^4.0.1)
  • @deepseek-ai/dsh-tools (^0.1.0-rc.6)
  • stool CLI (must be installed on the host machine; the plugin scans PATH and common directories such as /usr/local/bin)

When building from source, ensure that @deepseek-ai/dsh-tools exists:

cd ~/.dsh/plugin-src/dsh-stool-plugin
npm install
# 或手动建立符号链接
ln -sf /path/to/dsh-tools node_modules/@deepseek-ai/dsh-tools

Summary

dsh-stool-plugin introduces the mature stool CLI capabilities into the DSH ecosystem through an adapter pattern, greatly expanding the Agent’s automation capabilities in server operations, database operations, and workflow management. When using it, be mindful of the special parameter requirements and whitelist limitations of each subcommand.