dsh-claude-mcp
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-claude-mcphave Claude review src/auth.js and write its findings to review.md"
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.
dsh-claude-mcp
Hand one task to the Claude Code CLI on this machine, and get the result back cleanly — while Claude cannot touch your project files. Good for reviewing a plan, a code change or a PR, or for getting a second opinion.
What it does
Runs one Claude Code task for you. Give it a complete, self-contained job ("review this plan", "review this change"), it runs
claude -p, and brings the answer back.Keeps Claude out of your files. Claude reads the directories you name, but the only place it can write is its own throwaway run directory.
Hands back a list, not a wall of text. You get Claude's final message plus a manifest of what it produced: name, size, and a
sha256checksum. Open what you need, decide for yourself, then copy the parts you approve into your project.One tool. Nothing else to learn and nothing else to configure.
Related MCP server: Claude Code Bridge
Requirements
Node.js 22.19 or newer, or 24 or newer, plus a working, already-signed-in claude command on the same machine.
Install
Append the block below to
~/.dsh/profiles/<your profile>/cordis.patch.yml, replacing every/absolute/path/...with a real absolute path:
- insert:
- id: mcp-claude
name: '@deepseek-ai/dsh-mcp-client'
config:
transport: stdio
serverName: claude
command: /absolute/path/to/node
args:
- /absolute/path/to/dsh-claude-mcp/src/server.mjs
cwd: /absolute/path/to/your/workspace
toolCallTimeoutMs: 900000
failOnStartupError: trueAbsolute paths matter: a desktop app launched from the Finder inherits a minimal PATH, so a bare
node or a relative path will not resolve.
If the tool does not appear, restart the app once. A profile that reloads its patches live picks the row up on its own; the desktop profile declares no live reload.
You then have one extra tool: mcp__claude__run.
Usage
Ask me for a review, or anything else you want a second opinion on, and I will call it. What you can specify:
Argument | Required | Meaning |
| yes | The whole job, written out. Claude cannot see our conversation, so say which files to read and which file to write. |
| no | Which Claude model or alias to use, for example |
| no | Report only these files. Leave it out to report everything the run produced. |
| no | Extra directories Claude may read. Defaults to the configured workspace. |
| no | How long this run may take, in milliseconds. Default: 15 minutes. |
| no | Optional spending ceiling for the run. |
A run looks like this:
ok exit=0 140.1s model=sonnet permission=dontAsk
artifact <workspace>/.claude-staging/run-20261001-191307-9c44/work
final message
-------------
review written to review.md
artifacts (1) — bodies are NOT included, read them yourself
-------------
2500 B sha256:6676042702213315 review.mdartifact is the directory Claude was allowed to write; the run directory also
holds a manifest.json recording the same facts. Open the files the list names,
read them, and copy the parts you approve into your project.
If the boundary blocked something Claude wanted to do, the run says so under
denied by the permission boundary; the answer may then be incomplete, so read that
list first. Keep answers short and structured — say how long they should be, because
very long replies get truncated.
Command line (optional)
claude-mcp run -p "Review plan/foo.md and write review.md" -m sonnet
claude-mcp runs # list past runs
claude-mcp prune --older-than-days 7 --keep 5 # clean up old run directories
claude-mcp env # show how Claude Code will be launchedConfiguration (optional)
Environment variable | Effect |
| Full path to the |
| Default per-run time limit. |
| Where run directories live. Default: |
| Extra readable directories, separated by your platform's path separator. |
| Comma-separated names to forward to Claude Code even though they look like credentials or steer model routing. |
Safety
Claude reads the directories you name and writes only in its own run directory. Both are enforced by Claude Code's permission rules, not by asking the model nicely; the session has no shell and no network tools at all, and your Claude Code login is used as-is. This tool never reads, stores, or forwards your credentials, and variables whose names look like credentials are not passed on.
Nothing Claude produces enters your project by itself — you decide what to copy.
Every run leaves a manifest, and
claude-mcp pruneis the only thing that deletes run directories.
Development
node --test tests/*.test.mjsThe tests are fully offline: they use a fake claude, call no model and cost
nothing. The real thing lives in scripts/live-review.mjs (that one costs money).
License
MIT.
Available Tools
1 toolrunA
Run one Claude Code task (claude -p) in an isolated scratch directory. Returns Claude's final message plus an artifact manifest (path, bytes, sha256 per file) — file bodies are NEVER included. Claude can read the directories you name but can only write inside its own scratch directory. Read the artifact paths yourself, review them, and only then copy what you approve into the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | Optional explicit list of artifact paths (relative to the artifact root) to report. Omit to report every file the run created. | |
| model | No | Optional Claude model id or alias for this call (for example "sonnet" or a full model name). Omit to use the deployment default from CLAUDE_MCP_MODEL, or Claude Code's own configuration. | |
| prompt | Yes | The complete, self-contained task for Claude. It does not share this conversation, so include everything it needs (paths it may read, the exact question, and the output file it should write). | |
| readDirs | No | Optional extra directories Claude may READ (absolute paths). It still cannot write there. Omit to use the server working directory. | |
| timeoutMs | No | Deadline in milliseconds for the whole run. Defaults to the deployment value (CLAUDE_MCP_TIMEOUT_MS, else 900000). | |
| maxBudgetUsd | No | Optional ceiling in US dollars for this run, passed to Claude Code as its budget guard (default: CLAUDE_MCP_MAX_BUDGET_USD, else no ceiling). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses write isolation (scratch-only writes), that artifact file bodies are NEVER returned, and the return payload shape (final message + manifest with path/bytes/sha256). It omits auth/permission requirements and any rate-limit or concurrency behavior, keeping it short of a 5.
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?
Front-loaded with the core action, then returns, then permissions, then review workflow — a logical order. Every clause earns its place, though the final imperative sentence lengthens it slightly.
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?
No output schema exists, so the description must explain returns, and it does precisely (final message plus manifest fields, bodies excluded). Combined with the write-isolation rules, an agent has everything needed to invoke and consume the result correctly.
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 every parameter (files, model, prompt, readDirs, timeoutMs, maxBudgetUsd) is already documented in the schema. The description reinforces the read/write boundary and the self-contained prompt requirement but adds no syntax or format detail beyond the schema. Baseline 3 applies.
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?
States a specific verb+resource ('Run one Claude Code task (`claude -p`)') plus the execution context ('in an isolated scratch directory'). There are no sibling tools to differentiate from, and an agent immediately knows what this tool produces.
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?
The description gives clear context for use: Claude can read named directories but writes only in scratch, and the caller should read/review artifacts before copying them into the workspace. It doesn't state explicit when-not conditions or alternatives, but none exist here, so the guidance is solid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
run
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another. Its purpose—running a Claude Code task in an isolated scratch directory—is clearly stated and unambiguous.
The single tool is named 'run', a simple verb that clearly reflects its action. No other tools exist to create inconsistency, so naming is perfectly predictable.
A single tool is on the thin side for an MCP server, even one with a narrow focus. While it may be sufficient for the core operation, the rubric considers 1-2 tools borderline.
The core workflow—run a task, return the final message and artifact manifest—is covered. However, there is no explicit lifecycle management (e.g., cancel, list runs) or in-server artifact retrieval, though the latter is intentionally omitted for security.
Maintenance
Related MCP Connectors
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Safe folder access for ChatGPT and Claude: read, write and search files, risky tools opt-in.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables ISLI agents and MCP clients to dispatch natural-language coding and terminal tasks to a locally-installed Claude Code CLI, supporting both one-shot execution and persistent sessions with workspace and security controls.-
- FlicenseNot gradedqualityBmaintenanceEnables Claude conversations to send tasks to a local Claude Code CLI instance and retrieve results, bridging chat to laptop-based builds via stdio or HTTPS/tunnel modes.4 npm-
- AlicenseAqualityBmaintenanceEnables Claude Code to hand off mechanical work — file edits, code lookups, and lint triage — to a local Ollama model that reads and edits files directly, so file contents never enter Claude's context. Returns only a compact receipt, and reports success only after the change passes a deterministic syntax/project gate, rolling back and escalating on failure.4MIT
- AlicenseBqualityBmaintenanceEnables delegating coding tasks to the local cursor-agent CLI synchronously, blocking until completion and returning a compact report with diff, status, and session ID.1310 npmMIT