deepseek-as-subagent
This server lets you delegate batch and mechanical tasks to DeepSeek as a sub-agent running its own multi-turn agent loop inside your workspace, saving tokens by keeping heavy lifting out of Claude's main context.
ping— Health check; confirms the server is alive and returns version, mode, and config status.delegate_to_deepseek(task, context)— Hands off a focused task to DeepSeek, which runs autonomously with access to 7 sandboxed tools: Read, Write, Edit, Bash, Glob, Grep, and NotebookEdit. Returns a summary of files affected, turns used, tokens consumed, and any issues.✅ Best for: batch refactors, i18n extraction, log scanning, ETL scripts, bulk translation, tasks spanning 10–50 files with a clear mechanical pattern
❌ Avoid for: architectural design, cross-file judgment, or tasks requiring project-specific idioms
Safety sandbox — Operations are path-restricted to your workspace with a command blacklist, preventing destructive or escape actions.
Token efficiency — Claude only receives a summary, avoiding costly full-context reads.
Client-agnostic — Works with Claude Code, Codex CLI, Cursor, Cline, and any MCP-compatible client.
Configurable — Via
~/.deepseek-mcp/config.json(API key, model, max turns, allowed tools) with environment variable overrides.
deepseek-as-subagent
English · 简体中文
Run DeepSeek as a real sub-agent inside Claude Code / Codex CLI — not just an LLM endpoint. The host agent keeps the main conversation, planning, judgment, and verification. DeepSeek gets its own agent loop for execution-heavy work. Coding APIs use workspace-scoped writes and bounded trusted-host Bash; separate read-only APIs provide pure file analysis without command execution.
Full coding delegation
Claude / Codex (main agent)
├─ ordinary coding → delegate_to_deepseek
└─ coding task whose direction may change
→ start_deepseek → job_id
├─ send_deepseek_message(job_id, ...)
├─ get_deepseek_status(job_id)
├─ cancel_deepseek(job_id)
└─ get_deepseek_result(job_id)
▼
DeepSeek coding sub-agent
│ Read / Write / Edit / Bash / Glob / Grep / NotebookEdit
│ autonomously reads, modifies, runs, and tests in the workspace
▼
Result returns to the host
Host verifies representative changes / testsCoding Bash runs on the trusted host with cwd=workspace; it is bounded and
credential-isolated, but it is not an OS sandbox.
Read-only analysis delegation
Claude / Codex (main agent)
├─ ordinary read-only analysis → delegate_to_deepseek_readonly
└─ read-only analysis whose direction may change
→ start_deepseek_readonly → job_id
├─ send_deepseek_message(job_id, ...)
├─ get_deepseek_status(job_id)
├─ cancel_deepseek(job_id)
└─ get_deepseek_result(job_id)
▼
DeepSeek read-only sub-agent
│ Read / Glob / Grep
│ autonomously reads, searches, reviews, and performs static analysis
▼
Analysis returns to the host
Host verifies the conclusionQuick start
git clone https://github.com/PsChina/deepseek-as-subagent.git
cd deepseek-as-subagent
# Inspect install.sh and requirements.lock, then:
./install.shPython 3.10–3.12 must already be installed. The installer never pipes a remote
bootstrap script into a shell. It installs the exact, hash-verified dependency
set in requirements.lock, registers the MCP server with Claude Code, deploys
protected generation copies of the skill + /ds slash command. It does not
modify shell startup files. Helper deployment is best-effort after the core MCP
registration commits; a foreign destination is preserved and reported.
After install, edit ~/.deepseek-mcp/config.json to paste your DeepSeek API
key on POSIX, or set DEEPSEEK_API_KEY on Windows (get one at
platform.deepseek.com). Then
run claude and try /ds inspect this workspace and summarize its structure.
To upgrade, fetch and inspect an explicit tag or commit, then re-run the local
installer. Coding always uses trusted_host; read-only APIs need neither Bash
nor Docker/Podman. For
Codex or other MCP clients, see Install below.
Related MCP server: claude-code-codex-agents
How is this different from existing DeepSeek MCP servers?
Most deepseek-mcp-server projects expose DeepSeek as a single LLM call (create_chat_completion, create_anthropic_message). The host has to read every file itself and feed content into the prompt — DeepSeek only saves the "thinking" cost, not the "reading/writing" cost.
This project gives DeepSeek its own agent loop: tool dispatch, file I/O, optional command execution for coding, and multi-turn reasoning against the configured workspace. The host hands off a complete logical unit and gets a result back. Token savings are end-to-end.
What's in the box
MCP server (Python, stdio transport)
Coding and read-only delegation:
delegate_to_deepseek/delegate_to_deepseek_readonlySteerable background jobs:
start_deepseek/start_deepseek_readonlyplus shared controlsFlash / Pro model routing: host chooses a stable profile; users control the actual provider model IDs in config
Local DeepSeek agent loop (
agent_loop.py) with OpenAI-compatible function callingFixed capability APIs: coding gets Read / Write / Edit / Bash / Glob / Grep / NotebookEdit; read-only gets Read / Glob / Grep
Bash execution: bounded credential-isolated trusted-host commands through the tool-child boundary
Workspace path boundary for file tools, with outbound symlinks rejected
Cross-process execution lease so two MCP servers cannot run DeepSeek concurrently against the same workspace
Crash-safe mutation journal for Write / Edit / NotebookEdit with recovery query, file verification, and exact acknowledgement before another delegation; trusted-host Bash changes are not journaled
Explicit network retry policy with OpenAI SDK internal retries disabled to avoid nested retry amplification in proxy/TLS-timeout environments
Claude Code skill +
/dscommand for delegation policy and forced delegation
Compatibility
The four delegation entry points accept one additive optional argument,
model="flash" | "pro". Existing calls that omit it remain valid and now default
to the Flash profile. Background-job and recovery tools remain additive.
Mutation-capable legacy hosts must adopt the recovery query/verify/ack handshake
before starting another delegation; read-only use needs no change.
Clients should not parse health/error text byte-for-byte because diagnostics are now more specific. Provider calls still
use DeepSeek's OpenAI-compatible Chat Completions API.
Local Python module signatures are implementation details rather than a stable
public API.
Install
Claude Code (default)
git clone https://github.com/PsChina/deepseek-as-subagent
cd deepseek-as-subagent
./install.shThen edit ~/.deepseek-mcp/config.json on POSIX, or set
DEEPSEEK_API_KEY on Windows.
Codex CLI
git clone https://github.com/PsChina/deepseek-as-subagent
cd deepseek-as-subagent
bash adapters/codex/install.shSee adapters/codex/README.md for the Codex-specific install, delegation policy, and background-job workflow.
The Claude and Codex installers build a fresh isolated runtime, validate its configuration and MCP protocol, and only then switch the host registration. They keep the active generation plus one previous generation for recovery. Any manual runtime must stay outside a delegated workspace when file-mutation tools are enabled; unsafe layouts are rejected at startup. Both installers serialize install/uninstall transactions. A hard-killed installer intentionally leaves an empty fail-closed lock that must be removed only after confirming no installer is running.
Cursor / Cline / Claude Desktop / other MCP clients
The MCP server itself is client-agnostic. Install requirements.lock with
pip --require-hashes, install this project with dependency resolution disabled,
then point your client's MCP config at the generated deepseek-mcp entrypoint.
Usage
Choose capability for the task's entire expected lifecycle first. Use read-only only when every expected step is static file analysis with Read, Glob, and Grep—no command execution. If any step might need Bash, tests, builds, lint, Git, program execution, dependency work, workspace mutation, or is not clearly read-only, choose coding.
Simple delegation
Use a synchronous API when the task can run to completion without mid-flight intervention. The MCP request remains open until DeepSeek finishes:
delegate_to_deepseek(task, context, model="flash")for coding, Bash, tests, or any task that might write the workspace.delegate_to_deepseek_readonly(task, context, model="flash")for static file analysis only.
model is optional and accepts only flash or pro. Omit it for normal work;
select pro explicitly for difficult debugging, architecture-level reasoning,
or when Flash has already proved insufficient. The host never passes a provider
model ID directly.
Steerable background delegation
For longer tasks that may need new instructions or cancellation, choose the matching background API, then use the same controls for either job type:
start_deepseek(task, context, model="flash") / start_deepseek_readonly(task, context, model="flash") -> job_id
send_deepseek_message(job_id, message)
get_deepseek_status(job_id)
cancel_deepseek(job_id)
get_deepseek_result(job_id)Either start_* API returns quickly while the DeepSeek agent continues in a
background worker. Steering changes only the task instruction: it cannot change
the job's fixed tools, Bash availability, or selected model profile. Cancellation
wakes retry backoff and promptly terminates an in-flight provider or local-tool
subprocess.
If a readonly job later needs a command or workspace mutation, cancel or finish
it, then create a new coding job with start_deepseek; steering cannot upgrade
the existing readonly job.
If a steering message arrives after DeepSeek has planned tool calls but before a not-yet-executed tool runs, the stale tool call is skipped and DeepSeek re-plans from the new parent instruction.
Only one DeepSeek execution per canonical workspace may run at a time, including executions started by separate MCP server processes. This lease coordinates DeepSeek MCP executions only; it cannot prevent the host agent, IDE, user, or another local process from changing the workspace. While a coding background job is running, the host should steer, query, or cancel that job rather than independently mutate the same workspace, then resume host-side edits after the job reaches a terminal state. Background job IDs and results are session-scoped; collect the result before closing the host session.
Mutation recovery
Mutations committed through Write, Edit, and NotebookEdit are journaled
before commit. Trusted-host Bash runs outside this transaction journal and may
modify workspace files directly; those changes are not represented by
get_deepseek_recovery. After an interrupted coding run in which Bash may have
executed, inspect the workspace independently before continuing or retrying work.
After a result reports journaled mutations—or after cancellation, disconnection,
or MCP restart—run:
get_deepseek_recovery()
# verify every reported file
acknowledge_deepseek_mutations(transaction_ids)New delegation fails closed until the exact reviewed IDs are acknowledged. Recovery works without a valid DeepSeek API credential and never deletes or rolls back workspace files.
Claude Code helpers
delegate_to_deepseek/delegate_to_deepseek_readonly— Claude selects the matching fixed capability and Flash/Pro profile/ds <task>— force synchronous coding delegationDEEPSEEK_MODE=off claude— start one session with DeepSeek disabled
When delegation actually saves money
The delegation decision should happen before the host reads large amounts of source. If the host reads first and then delegates, both agents pay the repository-reading cost.
Sweet spot:
✅ Multi-file implementation / mechanical refactors / test generation
✅ Large data + simple processing (log scan, file conversion, ETL)
✅ Tasks that may benefit from a cheap independent execution loop
❌ Tiny edits where orchestration overhead dominates
❌ Cross-domain architecture / ambiguous root-cause analysis / security-sensitive judgment
Architecture
┌─────────────────────────────────────────────────────────────────┐
│ Claude Code / Codex CLI (main agent) │
│ ↓ stdio (MCP protocol, local) │
│ deepseek-as-subagent (Python MCP process) │
│ ├─ synchronous delegate │
│ └─ steerable background job manager │
│ ↓ │
│ DeepSeek agent loop + selected fixed-capability tools │
│ ↓ HTTPS │
│ api.deepseek.com │
└─────────────────────────────────────────────────────────────────┘No third-party proxy or cloud relay is introduced by this project. Delegated prompts and tool/file outputs selected by the agent are sent to the configured DeepSeek-compatible API, so only delegate data that endpoint is permitted to receive.
Configuration
~/.deepseek-mcp/config.json:
{
"api_key": "sk-...",
"flash": "deepseek-v4-flash",
"flash_reasoning_effort": "high",
"pro": "deepseek-v4-pro",
"pro_reasoning_effort": "high",
"_reasoning_effort_options": ["none", "low", "high", "max"],
"max_turns": 50,
"max_run_seconds": 18000,
"allowed_tools": ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "NotebookEdit"]
}flash and pro are the provider model IDs behind the two stable MCP routing
profiles. You can change these strings when DeepSeek publishes a new model
revision, or when a compatible endpoint uses different model names, without
changing how Claude/Codex calls the MCP tools. The public tool argument remains
only model="flash" or model="pro".
flash_reasoning_effort and pro_reasoning_effort accept none, low, high,
or max. none disables thinking; the other values explicitly enable thinking
at that effort. _reasoning_effort_options is only an in-file hint and is ignored
at runtime. If an effort field is absent, deepseek-mcp leaves thinking controls
unspecified for that slot so the provider's existing default applies; this keeps
older configs and OpenAI-compatible gateways compatible. New installer-generated
configs explicitly set both slots to high.
For upgrade compatibility, a legacy single model field is still accepted when
flash and pro are absent; its value is used for both slots. Do not combine
legacy model with the new flash / pro fields.
allowed_tools is retained for configuration compatibility and validation. It
does not select capabilities for a delegation: each MCP API applies its own
fixed profile after configuration is loaded.
max_run_seconds is the wall-clock limit for one delegated run. Its default is
18,000 seconds (5 hours), it may be increased explicitly, and its absolute
accepted maximum is 172,800 seconds (48 hours). Individual provider requests
remain bounded to 180 seconds within that run budget.
For synchronous delegation, the MCP client's tool timeout must be at least the
configured run limit plus cleanup grace; Codex installs with an 18,060-second
default (five hours plus 60 seconds).
Workspace root auto-follows the directory where you launch the host client.
To lock it to a fixed path regardless of cwd, add "workspace": "/abs/path"
to the config. It is the file-tool path boundary and the working directory for
coding Bash; it is not an OS sandbox for trusted-host Bash.
delegate_to_deepseek and start_deepseek always use full coding tools and
bounded trusted_host Bash. delegate_to_deepseek_readonly and
start_deepseek_readonly always use only Read/Glob/Grep and never expose Bash.
The selected API—not a task argument or model request—freezes that capability
for the job lifetime.
See SECURITY.md for boundaries and platform limitations.
Override at runtime with env vars: DEEPSEEK_API_KEY, DEEPSEEK_WORKSPACE, DEEPSEEK_MODE=off.
Uninstall
Claude Code: ./uninstall.sh. Codex: bash adapters/codex/uninstall.sh.
Each uninstaller removes only its owned host registration. Neither deletes your projects, DeepSeek config/API key, logs, or account.
License
MIT
Available Tools
2 toolsdelegate_to_deepseekA
Delegate a focused task to DeepSeek as a real sub-agent.
DeepSeek runs its own agent loop with Read/Write/Edit/Bash/Glob/Grep/NotebookEdit tools inside the configured workspace. Use this for batch / repetitive / mechanical tasks where you want to save main-conversation tokens and let DeepSeek do the heavy lifting end-to-end.
Good fits:
Extract i18n keys from N files into JSON
Translate large chunks of text
Scan logs for patterns
Bulk refactors with a clear pattern
One-off ETL scripts
Bad fits (do it yourself instead):
Architectural design / cross-file judgment
Bug root-cause analysis
Tasks requiring project-specific idioms from CLAUDE.md or other repo conventions
Args: task: Clear description of what DeepSeek should accomplish, including success criteria and file paths involved. context: Optional additional context — project conventions, related files DeepSeek should consider, output format requirements. Include this when project-specific knowledge matters.
Returns: A summary of what DeepSeek did, including files affected, turns used, tokens consumed, and any issues. Always verify the result by reading a sample of the affected files before declaring success to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| context | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes that DeepSeek runs its own agent loop with specific tools, saves main-conversation tokens, and returns a summary including files, turns, tokens, and issues. It also advises verifying results. Could mention potential failures or permissions but overall transparent.
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?
Well-structured with clear sections and bullet points for good/bad fits, front-loading the main purpose. Every sentence adds value, though the list of tools (Read/Write/Edit/Bash/etc.) could be slightly trimmed but is still informative.
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?
Given the complexity of the tool and that an output schema exists (though not shown), the description covers parameters, use cases, and return value. Sibling is only 'ping', so no confusion. Could mention edge cases or error handling, but adequate.
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?
Despite 0% schema coverage, the description provides detailed semantics for both parameters: 'task' is a clear description with success criteria and file paths; 'context' is optional additional context for project-specific knowledge. This significantly adds value beyond the schema property names.
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 clearly states that the tool delegates a task to DeepSeek as a sub-agent, listing its capabilities (Read/Write/Edit/Bash/etc.) and specifying the scope of tasks (batch/repetitive/mechanical). It distinguishes itself from the only sibling tool 'ping' which is a simple health check.
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?
Excellent usage guidelines: explicitly lists 'Good fits' (e.g., extract i18n keys, translate, scan logs, bulk refactors) and 'Bad fits' (architectural design, bug analysis, tasks needing project-specific idioms), advising the agent to 'do it yourself instead' for bad fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingA
Health check. Confirms the deepseek-mcp server is alive.
Use this before delegate_to_deepseek if you're not sure whether DeepSeek is configured. Returns version, mode (auto/off), and whether config is loadable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears the burden. It states the return values (version, mode, config loadable) and implies a safe read operation. However, it does not explicitly state that the tool is non-destructive or requires no permissions, but for a health check, this is acceptable.
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 sentences long, front-loaded with 'Health check.', and contains no unnecessary words. Every sentence adds value.
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?
Given no parameters and the presence of an output schema (which likely details return structure), the description still lists what the tool returns and provides usage context relative to the sibling tool. It is fully adequate for an agent to understand and invoke this tool 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?
There are no parameters, so baseline 4 applies. The description does not need to add parameter information.
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 clearly states the tool is a health check that confirms server aliveness, and distinguishes it from the sibling tool 'delegate_to_deepseek' by explicitly mentioning its use before that tool.
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 provides explicit guidance: 'Use this before delegate_to_deepseek if you're not sure whether DeepSeek is configured.' This tells the agent exactly when to use this tool and even mentions an alternative.
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.
2 tool updates
v0.0.1- First observed
delegate_to_deepseek - First observed
ping
TDQS
Scored across 2 tools
The two tools serve completely distinct purposes: one for delegating tasks to DeepSeek and one for health checking. There is no ambiguity or overlap.
Both tools use snake_case, but 'delegate_to_deepseek' is descriptive while 'ping' is a single-word convention. The pattern is mostly consistent, with a minor deviation.
With only 2 tools, the server is minimal but appropriate for its focused role as a sub-agent delegator. The health check is essential, but more tools (e.g., cancellation) could be added.
The server covers its core purpose: delegating tasks and verifying availability. No obvious missing operations for its narrow scope, though a status polling tool could be useful.
Maintenance
Related MCP Connectors
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
- mcp-serverOAuthai.cdbx
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
Related MCP Servers
- AlicenseCqualityFmaintenanceConnects AI assistants like Claude to the Codex CLI for code analysis, editing, and execution. Supports file references with @ syntax, sandboxed code execution with approval workflows, and structured code changes for automated refactoring and documentation.8116 npm179MIT
- AlicenseAqualityDmaintenanceEnables Claude Code to delegate tasks to OpenAI's Codex CLI (GPT-5.4) with structured execution traces, parallel execution, session persistence, and adversarial code review.15MIT
- AlicenseAqualityAmaintenanceEnables Claude Code to use GLM (Zhipu) as a cheap, full-capability subagent for file editing, code generation, and bash commands, with automatic routing between Opus and GLM based on task complexity.42MIT
- AlicenseNot gradedqualityAmaintenanceEnables dispatching work to DeepSeek Harness agents from Claude Code/Codex, with native progress UI, tier policy, and vision/image generation through MCP tools.128 npm142MIT