Skip to main content
Glama

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 sha256 checksum. 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

  1. 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: true

Absolute paths matter: a desktop app launched from the Finder inherits a minimal PATH, so a bare node or a relative path will not resolve.

  1. 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

prompt

yes

The whole job, written out. Claude cannot see our conversation, so say which files to read and which file to write.

model

no

Which Claude model or alias to use, for example sonnet. Leave it out to use your own Claude Code settings.

files

no

Report only these files. Leave it out to report everything the run produced.

readDirs

no

Extra directories Claude may read. Defaults to the configured workspace.

timeoutMs

no

How long this run may take, in milliseconds. Default: 15 minutes.

maxBudgetUsd

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.md

artifact 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 launched

Configuration (optional)

Environment variable

Effect

CLAUDE_MCP_ENTRY

Full path to the claude program, when it cannot be found automatically.

CLAUDE_MCP_TIMEOUT_MS

Default per-run time limit.

CLAUDE_MCP_STAGING_DIR

Where run directories live. Default: <your workspace>/.claude-staging.

CLAUDE_MCP_READ_DIRS

Extra readable directories, separated by your platform's path separator.

CLAUDE_MCP_ENV_PASSTHROUGH

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 prune is the only thing that deletes run directories.

Development

node --test tests/*.test.mjs

The 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 tool
runA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
filesNoOptional explicit list of artifact paths (relative to the artifact root) to report. Omit to report every file the run created.
modelNoOptional 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.
promptYesThe 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).
readDirsNoOptional extra directories Claude may READ (absolute paths). It still cannot write there. Omit to use the server working directory.
timeoutMsNoDeadline in milliseconds for the whole run. Defaults to the deployment value (CLAUDE_MCP_TIMEOUT_MS, else 900000).
maxBudgetUsdNoOptional 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

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedrun

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers