Skip to main content
Glama
deenjakoruzh
sakurameishi

Codex DSH MCP

by sakurameishi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Codex DSH MCP

A cost-aware MCP bridge that lets Codex delegate routine, context-heavy work to DeepSeek Harness—while Codex keeps architecture, review, and final verification under control.

Codex DSH MCP runs each DeepSeek worker in an isolated Git worktree created from committed HEAD. It never applies changes to the main workspace automatically: Codex and the human reviewer receive a compact result, a Markdown report, and a patch to inspect first.

Why use it?

  • Offload repository exploration, routine implementation, refactors, tests, and ordinary fixes to DeepSeek.

  • Keep high-risk architecture, security, final review, and acceptance with Codex.

  • Retry an eligible non-timeout failure at most once; timeouts consume the total budget and escalate immediately.

  • Track calls, duration, success rate, and clearly labeled estimated/reported token usage per project.

  • Keep the main checkout protected: workers operate only in isolated worktrees.

Related MCP server: Hydra

Quick start

  1. Clone this repository and open its folder in Windows Explorer.

  2. Double-click install-windows.bat (or run install-windows.ps1 in PowerShell).

  3. Merge config.toml.example into %USERPROFILE%\.codex\config.toml and update the bridge path.

  4. Merge AGENTS.md into your global or project-level Codex instructions.

  5. Restart Codex and confirm the deepseek MCP server exposes five tools.

What it exposes

  • deepseek_explore — read-only repository exploration/search.

  • deepseek_task — normal implementation/refactor/test work in an isolated worktree.

  • deepseek_fix — bug/failing-test diagnose-edit-test loop in an isolated worktree.

  • deepseek_review — read-only focused review.

  • deepseek_stats — read-only bridge statistics (totals, tool counts, success rate, average duration, last 10 task metadata).

How routing works

AGENTS.md tells Codex to choose DIRECT_CODEX for small, critical, architectural, security-sensitive, destructive, or already-escalated work. It chooses DELEGATE_DEEPSEEK for broad exploration and routine work—especially when more than about three files must be read, more than about two files changed, or an edit/test/fix loop is likely. Codex does not scan the repository first just to make this choice.

User
 ↓
Codex Router
 ├── Small / Critical ──→ Codex
 │
 └── Delegatable
       ↓
    DeepSeek
       ↓
 ┌─────┴─────┐
Success     Failure
 ↓             ↓
Review      Retry once
               ↓
          Failure again
               ↓
             Codex

The retry is a focused bug-fix attempt using the same task ID. It is available only for eligible non-timeout failures and only while total time remains. A timeout or second failure returns ESCALATED_TO_CODEX; Codex takes over.

Long-running delegations

Codex estimates a duration range before launching DSH work:

  • Up to 10 minutes: use the synchronous MCP tools and keep the task in the current turn.

  • More than 10 minutes, or an estimate that crosses 10 minutes: start the isolated DSH batch in detached mode, record its run directory and expected completion window, then check status near the estimated time instead of continuously waiting.

Long runs are status-first: unchanged state does not trigger repeated log reads or chat updates. Reports, patches, and detailed logs are reviewed only at completion, failure, staleness, or a meaningful checkpoint. This preserves Codex context while retaining the same isolation, one-retry, and human-review guarantees.

The bundled controller enforces the deadline itself, emits 15-second heartbeats, terminates timed-out worker process trees, and finalizes status.json plus Markdown reports before returning. status also reconciles legacy running records when their heartbeat and processes are stale. Headless launches sharing one DSH_HOME are serialized across runs to avoid profile-startup races; Windows batches are additionally clamped to one active worker.

Requirements

  • Windows 10/11 (the bridge also has a POSIX path).

  • Node.js 20+.

  • Codex with MCP support.

  • DeepSeek Harness available as dsh and already configured/authenticated for the DeepSeek model/service you intend to use.

Install on Windows

Open PowerShell in this folder:

Set-ExecutionPolicy -Scope Process Bypass
.\install-windows.ps1

Or double-click install-windows.bat; it is a thin Windows wrapper around the same installer. The installer also updates the bundled dsh-batch-subagents skill under %USERPROFILE%\.codex\skills.

Then verify DeepSeek Harness independently before involving Codex:

dsh --profile headless "Reply with exactly READY"

If that does not work, fix dsh first. The MCP bridge intentionally does not manage DeepSeek credentials itself.

Configure Codex

Merge config.toml.example into %USERPROFILE%\.codex\config.toml, and replace the example path:

[mcp_servers.deepseek]
command = "node"
args = ["C:/tools/codex-deepseek-bridge/src/index.mjs"]
startup_timeout_sec = 20
tool_timeout_sec = 7200

[mcp_servers.deepseek.env]
DSH_BATCH_CONTROLLER = "C:/Users/Administrator/.codex/skills/dsh-batch-subagents/scripts/dsh-batch-agents.mjs"
DSH_COMMAND = "dsh"
DSH_TIMEOUT_MS = "1800000"
DSH_MAX_OUTPUT_CHARS = "6000"
DSH_AUTO_RETRY = "true"
DSH_MAX_RETRIES = "1"
DSH_STATS_ENABLED = "true"
DSH_TOKEN_STATS = "true"
DEEPSEEK_ALLOWED_ROOT = "D:/Projects"

Restart Codex. In Codex TUI, /mcp should show the deepseek MCP server and five tools.

Install the delegation prompt

For one repository, put AGENTS.md at the repository root (or merge the DeepSeek delegation section into an existing AGENTS.md).

For a global personal policy, merge the contents into %USERPROFILE%\.codex\AGENTS.md. Project-specific instructions can still override it.

Suggested first test

In a disposable Git repository, ask Codex:

Find where the CLI arguments are parsed. Use DeepSeek for repository exploration and report the relevant files. Do not modify anything.

Then try a harmless write task:

Add a small unit test for an existing pure helper. Delegate the implementation to DeepSeek, then inspect the diff and run the focused test yourself before reporting success.

Then verify stats:

Run deepseek_stats to check bridge usage and token savings.

Environment variables

Core

Variable

Description

Default

DSH_BATCH_CONTROLLER

Absolute path to the isolated-worktree controller

(required)

DSH_COMMAND

dsh, or an absolute DSH JavaScript launcher module passed safely to the controller

dsh

DSH_TIMEOUT_MS

Total wall-clock budget for one delegation, including any retry; clamped 10 s – 2 h

1800000 (30 min)

DSH_MAX_OUTPUT_CHARS

Max chars returned to Codex context

6000

DEEPSEEK_ALLOWED_ROOT

Optional root; restricts which directories DeepSeek can access

(none)

Auto-retry

Variable

Description

Default

DSH_AUTO_RETRY

Whether to auto-retry eligible non-timeout failures while budget remains

true

DSH_MAX_RETRIES

Max focused retries; a timeout is never retried automatically

1

Statistics

Variable

Description

Default

DSH_STATS_ENABLED

Enable stats persistence

true

DSH_STATS_FILE

Path to stats file; absolute or relative to workspace

.codex-deepseek/stats.json

DSH_TOKEN_STATS

Enable token usage tracking

true

Result format

Every delegation tool returns a compact structured JSON object with:

Field

Description

status

success, failed, or escalated_to_codex

tool

The tool name (e.g. deepseek_task)

task_id

Unique ID: ds_YYYYMMDD_shortid

attempt

Current attempt number

attempts

Actual number of attempts completed

max_attempts

Configured maximum (initial + retries)

duration_ms

Wall-clock duration of this attempt

exit_code

Exit code from the batch controller

changed_files

Array of file paths that were changed

tests

{ ran, passed, summary }

usage

Token usage with source (reported/estimated) and estimated boolean

summary

Short description of what was done

artifact_paths

{ run_dir, report, patch }

failure_type

timeout, controller_error, malformed_output, unable_to_complete, test_failure, no_changes, or null

retry_recommended

Whether this failure type qualifies for retry

will_retry

Whether another attempt will actually run under the configured limit

escalated

Boolean; true when all attempts exhausted

escalation_marker

"ESCALATED_TO_CODEX" when exhausted

Escalation flow

Tool call → attempt 1 (eligible non-timeout failure) → one retry within the original budget → failure → escalated_to_codex

Tool call → timeout → controller finalizes artifacts → escalated_to_codex (no retry)

When a delegation returns status: "escalated_to_codex", Codex should investigate the root cause and decide on next steps. The bridge never calls the Codex API.

Token Statistics

Token usage is parsed from DeepSeek/Harness output when a usage JSON block is available (source: "reported", estimated: false). Otherwise, it is approximated from prompt/result character counts at about one token per four characters (source: "estimated", estimated: true). Reported usage is provider data; estimated usage is only a fallback approximation.

The project-level .codex-deepseek/stats.json records bounded metadata for at most 100 attempts and is written through a temporary file followed by rename. It never stores the complete task Prompt, result summary, diff, changed-file paths, or artifact paths. deepseek_stats returns totals, success rate, average duration, per-tool counts, and the most recent 10 metadata entries.

estimated_codex_tokens_avoided uses the amount of context handled by DeepSeek as a rough proxy for context Codex did not have to process. It is always marked estimate_only: true. It is not an OpenAI or Codex quota measurement and should be used only to judge whether delegation is directionally worthwhile.

Security model

deepseek_task and deepseek_fix allow DeepSeek Harness to edit only an isolated Git worktree. Reports and patches are kept outside the repository for Codex and human review. Nothing is merged or applied automatically.

deepseek_explore and deepseek_review also run in isolated worktrees. Their read-only behavior remains a prompt-level policy, but accidental writes cannot touch the main workspace.

deepseek_stats is read-only and accesses only the stats file.

Why this saves Codex usage

The expensive loop is usually repository search → many file reads → implementation → tests → failure analysis → retry. The bridge moves that loop into a separate DeepSeek Harness session. Only DeepSeek's compact structured result returns to Codex; Codex can then inspect the resulting diff and perform targeted verification.

Author

Created and maintained by @sakurameishi.

License

MIT © 2026 sakurameishi.

Available Tools

5 tools
deepseek_exploreA
Read-onlyIdempotent

Delegate repository exploration, code search, dependency tracing, or implementation-location discovery to DeepSeek Harness. Read-only: DeepSeek is instructed not to modify files. Returns compact structured JSON.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory. Defaults to the MCP server process working directory.
taskYesThe concrete coding task to delegate to DeepSeek Harness.
timeout_minutesNoOptional timeout override in minutes.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that DeepSeek is 'instructed not to modify files' and returns 'compact structured JSON,' which reinforces the read-only nature and provides output format context. This adds value beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and includes a read-only note and output format. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (delegation to an external harness), the description covers the purpose, read-only behavior, and output format. It lacks details on how the task is executed or what 'compact structured JSON' contains, but with no output schema and good annotations, the description is reasonably complete for an agent to decide and invoke.

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 the schema already documents all three parameters (cwd, task, timeout_minutes). The description does not add additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.

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?

The description clearly states the tool's purpose: 'Delegate repository exploration, code search, dependency tracing, or implementation-location discovery to DeepSeek Harness.' It uses specific verbs (explore, search, trace, discover) and a clear resource (repository). It distinguishes from siblings by focusing on exploration/discovery rather than task execution, fixing, reviewing, or stats.

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 implies when to use this tool: for exploration, code search, dependency tracing, and implementation-location discovery. It does not explicitly state when not to use it or name alternatives, but the sibling tools (deepseek_task, deepseek_fix, deepseek_review, deepseek_stats) provide context. The description could be more explicit about exclusions, but the purpose is clear enough for an agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deepseek_fixA

Delegate a bug-fix or failing-test loop to DeepSeek Harness in an isolated Git worktree. The main workspace is never modified automatically. Returns compact structured JSON.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory. Defaults to the MCP server process working directory.
taskYesThe concrete coding task to delegate to DeepSeek Harness.
evidenceNoOptional error message, failing test output, stack trace, or symptoms already observed by Codex.
timeout_minutesNoOptional timeout override in minutes.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false, but the description adds important context: the tool operates in an isolated Git worktree and never modifies the main workspace automatically. This goes beyond the annotations and clarifies the safety profile. It also mentions the return format (compact structured JSON), which is useful. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and includes a key safety guarantee and return format. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (4 params, no output schema, no nested objects), the description is fairly complete. It explains the isolation mechanism, the safety guarantee, and the return format. It could mention what happens on failure or how the worktree is cleaned up, but the annotations and schema cover the basics. A 4 is appropriate.

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 the schema already documents all four parameters. The description adds minimal extra meaning beyond what the schema provides, but it does mention the 'evidence' parameter implicitly by saying 'failing-test loop' and 'symptoms already observed'. Since the schema covers everything, a baseline of 3 is appropriate.

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?

The description clearly states the tool's purpose: delegating a bug-fix or failing-test loop to DeepSeek Harness in an isolated Git worktree. It specifies the action (delegate), the resource (bug-fix/failing-test loop), and the isolation mechanism (worktree), which distinguishes it from siblings like deepseek_task or deepseek_explore.

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 implies when to use this tool: when there is a bug-fix or failing-test loop to delegate. It also notes that the main workspace is never modified automatically, which is a key usage consideration. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deepseek_reviewA
Read-onlyIdempotent

Delegate a focused code review to DeepSeek Harness. Read-only: DeepSeek is instructed not to modify files. Returns only material findings. Returns compact structured JSON.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory. Defaults to the MCP server process working directory.
taskYesThe concrete coding task to delegate to DeepSeek Harness.
focusNoOptional review focus such as correctness, concurrency, security, performance, or API compatibility.
timeout_minutesNoOptional timeout override in minutes.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only: DeepSeek is instructed not to modify files.' It adds value by explaining the agent will not make changes and by stating the output behavior: 'Returns only material findings. Returns compact structured JSON.' Though it doesn't mention advanced details like auth or rate limits, it enriches beyond the annotations with output expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceedingly concise—two sentences—yet packs in all key information: action, read-only guarantee, output filtering, and output format. It front-loads the primary purpose and delivers maximum information density without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delegation tool with 4 parameters (1 required) and no output schema, the description adequately contextualizes the tool's role and output expectations. It covers the core aspects: what it does, its safety profile, and partial output details. While it could elaborate on 'material findings' or the exact JSON structure, the description is sufficient for an agent to use the tool effectively without confusion.

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?

The input schema has 100% description coverage, with parameters like task and focus clearly documented. However, the description adds no additional semantic meaning beyond what's in the schema. It simply outlines the tool's high-level behavior without elaborating on parameter usage or providing examples. Thus, it meets the baseline but doesn't exceed it.

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?

The description clearly states the tool's function with a specific verb and resource: 'Delegate a focused code review to DeepSeek Harness.' It distinctly identifies the operation (delegating a code review) and differentiates it from sibling tools like deepseek_task or deepseek_fix, which likely handle task execution or bug fixes. The 'focused' modifier adds precision, and the description leaves no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage ('Delegate a focused code review') but does not explicitly state when to prefer this tool over siblings or provide exclusions. There's no mention of alternatives or when not to use it. A 3 reflects that the usage context is implied but not explicitly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deepseek_statsA
Read-onlyIdempotent

Read-only bridge statistics. Returns concise totals, tool counts, success rate, average duration, and last 10 task metadata. Results are drawn from the project-level stats file (.codex-deepseek/stats.json).

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory used to locate the stats file. Defaults to the MCP server process working directory.

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, idempotentHint), the description adds that results are drawn from a project-level stats file (.codex-deepseek/stats.json), providing extra context about data provenance. 'Read-only' aligns with annotations, and no contradictions exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: two sentences, front-loaded with purpose ('Read-only bridge statistics'), and each clause provides useful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (1 optional param, no output schema), the description explains the return categories (totals, counts, success rate, duration, last 10 task metadata) sufficiently. It might be slightly more complete with mention of failure modes (e.g., missing stats file), but that is not essential for this tool.

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?

The schema description coverage is 100% (the single 'cwd' parameter is fully described in the input schema). The tool description does not add any parameter details beyond the schema, so it meets the baseline but offers no extra semantic value.

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?

The description clearly states the tool's function: returns bridge statistics including totals, tool counts, success rate, average duration, and last 10 task metadata. It distinguishes from sibling tools (task/fix/explore/review) by being a stats aggregator, and the verb 'Returns' is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for obtaining overall statistics but does not explicitly say when to use it over alternatives or when not to use it. Context from sibling names helps, but there is no direct guidance on selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deepseek_taskA

Delegate a normal implementation/refactor/debug task to DeepSeek Harness in an isolated Git worktree. The main workspace is never modified automatically; Codex must review the report and patch before applying anything. Returns compact structured JSON with status, task_id, retry information, usage, and artifact paths.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorkspace directory. Defaults to the MCP server process working directory.
taskYesThe concrete coding task to delegate to DeepSeek Harness.
timeout_minutesNoOptional timeout override in minutes.

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the raw annotations (readOnly:false, destructive:false), the description adds valuable behavioral context: the isolation guarantee ('main workspace is never modified automatically') and the mandatory review gate ('Codex must review the report and patch before applying anything'). This paints a coherent safety model — the operation produces work but is gated — that the annotations alone don't fully convey. It stops short of addressing failure paths, but for this complexity level it's strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: (1) what and where, (2) safety/review gate, (3) return format. Front-loaded with the purpose statement, zero fluff, and optimally scannable for an agent parsing the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-param tool with no output schema, the description covers the key facets: delegation target, isolation model, safety gate, and return contract (status, task_id, retry info, usage, artifact paths). Remaining minor gaps: no guidance on error/failure behavior or how task_id might chain with sibling tools, but neither is critical given the explicit safety workflow.

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% — cwd, task, and timeout_minutes already have meaningful descriptions with defaults, constraints, and types. The description adds no additional parameter semantics on top of the schema, so the baseline of 3 is appropriate. The 'Returns compact structured JSON...' sentence describes the output, not the parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description pairs a specific verb ('Delegate') with a resource ('DeepSeek Harness in an isolated Git worktree') and a clear scope ('normal implementation/refactor/debug task'). The word 'normal' implicitly contrasts with the specialized sibling tools (fix/explore/review/stats), though it stops short of explicitly naming them as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: 'normal implementation/refactor/debug task' signals this is the general-purpose sibling, while deepseek_explore/review/fix/stats handle specialization. However, there are no explicit when-to-use, when-not-to-use, or named-alternative statements, and the safety workflow note ('Codex must review the report and patch before applying anything') is about execution behavior rather than selection criteria.

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. 5 tool updatesv0.2.0
    • First observeddeepseek_explore
    • First observeddeepseek_fix
    • First observeddeepseek_review
    • First observeddeepseek_stats
    • First observeddeepseek_task
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: task delegation, bug fixing, exploration, review, and statistics. The descriptions explicitly differentiate read-only operations and the action types, leaving no ambiguity.

Naming Consistency5/5

All tools follow the identical `deepseek_` prefix with a verb indicating the action (task, fix, explore, review, stats). This consistent pattern makes the API predictable and easy to navigate.

Tool Count5/5

With only 5 tools, the set is tightly scoped to the core operations of the DeepSeek Harness bridge. Each tool serves a distinct necessary function without redundancy or bloat.

Completeness4/5

The tools cover the primary workflows (delegation, fixing, exploration, review, and stats). A minor gap is the lack of explicit task status or cancellation tools, though the stats tool implicitly provides an overview. The surface is otherwise well-rounded.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers