Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dsh-cli-mcp refactor the auth module in /home/user/myapp to use async/await"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that delegates coding tasks to your locally installed
DeepSeek Harness CLI (dsh,
npm package @deepseek-ai/dsh).
It wraps the real dsh binary instead of bundling its own copy of the agent,
so every call inherits your DeepSeek login, models and config.
This is a minimal first scaffold. The wrapped CLI is invoked one-shot via
dsh --print "<prompt>". Sessions, ACP transport, mid-run control, and the
dsh web UI integration are out of scope for v0.1.0 and will land in later
releases.
Sibling of mcode-mcp, qwen-cli-mcp, kimi-cli-mcp, pi-cli-mcp and grok-code-mcp — same architecture, same principles, DeepSeek Harness behind the wheel.
npx -y dsh-cli-mcp # no install
npm install -g dsh-cli-mcp # or globalRequires Node >= 22 and a working dsh on PATH
(npm i -g @deepseek-ai/dsh or pnpm add -g @deepseek-ai/dsh).
To point the adapter at a non-PATH binary without changing global PATH:
export DSH_MCP_BIN=/path/to/dshRelated MCP server: dsh-orchestrator
claude mcp add-json dsh -s user '{
"type": "stdio",
"command": "npx",
"args": ["-y", "dsh-cli-mcp"],
"timeout": 3600000
}'Any other MCP client:
{
"mcpServers": {
"dsh": { "command": "npx", "args": ["-y", "dsh-cli-mcp"] }
}
}Keep the server name short (dsh): it becomes part of the tool names your
model sees.
Tool | Purpose |
| Run a prompt through DeepSeek Harness. Returns the final answer plus the exit code, wall time, and the last 4 KB of stderr. |
dshArgument | Notes |
| Required. The task for the DeepSeek Harness agent. Self-contained — |
| Optional absolute path. Defaults to the server's cwd. |
| Optional integer, default 300 000 (5 min), max 1 800 000 (30 min). Wall-clock cap on the run. |
dsh({
prompt: "Reply with exactly: hello from dsh",
cwd: "/abs/path/to/repo",
timeout_ms: 120000,
})The server spawns dsh --print "<prompt>" as a child process, waits for it
to finish, and returns one text block containing the prompt echo, the trimmed
stdout, the tail of stderr, the exit code, and the elapsed wall-clock time.
A non-zero exit code is reported as a tool error (isError: true) — the
adapter does not invent success where dsh itself returned failure.
git clone https://github.com/minmax/dsh-cli-mcp.git
cd dsh-cli-mcp
pnpm install
pnpm run build
pnpm run lint
pnpm testpnpm run test:live exercises the real dsh binary end-to-end
(DSH_CLI_MCP_LIVE=1 opt-in). The default unit suite runs without dsh and
exercises the adapter's stdio JSON-RPC loop directly.
MIT. See LICENSE.
Run a prompt through your locally installed DeepSeek Harness CLI (dsh --print). Blocks until dsh settles, then returns the captured stdout, the last 4 KB of stderr, the exit code, and the wall-clock time. dsh cannot see this conversation, so the prompt must be self-contained: file paths, goal, constraints, expected output format.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Absolute path where dsh will run. Defaults to the server's cwd. Relative paths are rejected. | |
| prompt | Yes | The complete task for the DeepSeek Harness agent. Must be self-contained — dsh cannot see your conversation, so include everything it needs (file paths, goal, constraints, expected output format). | |
| timeout_ms | No | Wall-clock timeout in milliseconds. Defaults to 300000 (5 min). Hard ceiling is 1800000 (30 min). On timeout, dsh is sent SIGTERM (then SIGKILL after 5 s) and the tool result is reported as a `DshTimeout` error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey that this is not read-only, is not idempotent, is open-world, and may be destructive. Beyond that, the description adds useful behavioral details: it blocks until dsh settles, returns captured stdout, the last 4 KB of stderr, the exit code, and wall-clock time, and it cannot access the conversation context. These are meaningful additions that help an agent anticipate the tool's runtime behavior and output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences, front-loaded with the tool's primary action and command, followed by behavioral details and the key prompt constraint. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does well by specifying exactly what is returned: stdout, last 4 KB of stderr, exit code, and wall-clock time. It also covers blocking behavior and the important limitation that dsh cannot see the conversation. A small gap is that it does not explicitly mention the timeout escalation behavior in the main description, though that is covered in the timeout parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description reinforces the prompt self-containment requirement but does not materially extend it beyond what the prompt parameter schema already states. This matches the baseline 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run a prompt through your locally installed DeepSeek Harness CLI (`dsh --print`)'. It clearly identifies what the tool does and even names the underlying command. With no sibling tools to distinguish from, this is unambiguous and fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are no sibling tools, so no alternative comparison is needed, but the description gives clear operational context: the tool runs a self-contained prompt through a local CLI and blocks until completion. It also provides a crucial usage constraint: dsh cannot see the conversation, so the prompt must be fully self-contained. It stops short of explicit when-to-use or when-not-to-use guidance, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dshScored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap. The tool's purpose is clear and distinct by definition.
With a single tool named 'dsh', the name is concise and directly tied to the underlying CLI. While there is no pattern to evaluate, the naming is consistent with the server's purpose and poses no ambiguity.
A single tool is thin for most MCP servers, but here it serves a narrow, specific purpose (running a single CLI command). It feels borderline—appropriate for a minimal wrapper but could benefit from additional tools for managing or inspecting dsh state.
For its stated purpose of executing a prompt through dsh, the tool covers the essential functionality. Minor gaps exist, such as lacking support for listing available prompts or managing dsh configuration, but agents can work around these by crafting self-contained prompts.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
A paid remote MCP for OpenAI Codex harness MCP, built to return verdicts, receipts, usage logs, and
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Paid remote MCP for LLM security scans, jailbreak checks, analytics, checkout, and readiness.
