DeepSeek-MCP
This server provides AI-powered tools for reviewing, generating, analyzing, and refactoring code.
Review & Analysis: Review individual files, folders, entire projects, SQL, architecture, security (OWASP, secrets, access control), and performance (bottlenecks, Big O, async I/O). Summarize codebases, docs, or specifications. Explain complex code step-by-step.
Generation: Generate single or multiple related code files, SQL objects (procedures, views, migrations), test suites (unit/integration), seed/mock data, documentation (READMEs, API docs, Mermaid diagrams), and full project scaffolds (Clean Architecture, Onion, Microservices).
Improvement: Refactor code following Clean Code and SOLID principles.
Server Features: Manages project memory (facts, rules, history) with staleness checks. Enforces per-project isolation, preventing file access outside the designated root. Optimizes AI token usage via context budgeting and pruning. All output is structured and saveable; the server never writes to disk directly.
Provides integration with OpenAI's language models as a provider for delegating AI tasks such as code review, generation, and analysis through the AI Orchestrator's unified provider interface.
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., "@DeepSeek-MCP Review my authentication code for security vulnerabilities"
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.
DeepSeek Subagents
A Claude Code plugin. Delegate bounded coding sub-tasks — generate a file, write a test suite, audit a folder, find where something lives — to DeepSeek subagents that read and write the project directly. Their file reads, searches and tool loops happen out of process, so only the final answer reaches your context.
What it does
Seven tools instead of thirty-four.
agent,orchestrate,agent_control,memory,review,generate,analyze— each with arole/kind/actiondiscriminator. Tool schemas are resent on every request, so a small surface is a permanent token saving. Old tool names (subagent_coder,review_code, …) still work as hidden aliases.Plans run as a graph. Write a dependency graph of subagents and hand it over: independent steps run in parallel, dependent ones inherit their predecessors' answers, and the run survives the tool call that started it.
Per-project isolation. Every call is bound to one project root. File tools refuse any path that escapes it, so working in one repo can never touch another.
Memory that fills itself. Facts about the codebase, the rules it holds you to, and what each thread decided live as plain markdown in
<project>/.agent/memory/. Facts are captured after every run and re-checked against the working tree before they are served.A context pipeline per subagent. Oversized tool results are capped, old ones pruned, and only then is a summary paid for.
Context injected for you. Project facts and the thread brief are added to each subagent's system prompt automatically — the caller never resends them.
Related MCP server: mcp-agent-review
Install
As a Claude Code Plugin
/plugin marketplace add Abbas-F-R/DeepSeek-MCP
/plugin install deepseek-subagents@deepseek-subagentsOne install, every project. Ships the tool backend, the skill, and seven commands
(/deepseek-subagents:brief, delegate, orchestrate, generate, review, explore,
save).
As an MCP Server (Cursor, Claude Desktop, Windsurf, VS Code, etc.)
Add to your MCP configuration (.mcp.json or mcp.json or host MCP settings):
{
"mcpServers": {
"deepseek-subagents": {
"command": "npx",
"args": ["-y", "deepseek-subagents"],
"env": {
"DEEPSEEK_API_KEY": "your_api_key_here"
}
}
}
}Or for local repository usage:
{
"mcpServers": {
"deepseek-subagents": {
"command": "node",
"args": ["/path/to/DeepSeek-MCP/dist/index.js"],
"env": {
"DEEPSEEK_API_KEY": "your_api_key_here"
}
}
}
}Global Skill Discovery
A top-level SKILL.md file is provided at the repository root. Any AI agent or assistant supporting SKILL.md standards can load the contract and capabilities directly.
Environment Variable
Put your key in your shell profile — never in a repo:
export DEEPSEEK_API_KEY=your_actual_keyDeveloping on this plugin
npm install
npm run build
npm testTo try a local checkout before publishing, point a .mcp.json at your build. It is
gitignored, because it names paths that only exist on your machine:
{
"mcpServers": {
"deepseek-subagents": {
"command": "node",
"args": ["/abs/path/to/DeepseekMCP/dist/index.js"]
}
}
}How the project root is decided
The root is never written into config. The host launches the backend with the project
directory as its working directory, and the root is resolved from there, walking up to the
nearest .git, package.json, go.mod, pyproject.toml, Cargo.toml or .sln. A
moved, renamed or cloned project keeps working with no config change.
Precedence, if you ever need to override it:
project_rootargument on an individual tool callPROJECT_ROOTenvironment variablethe working directory (the normal path)
One process per project, over stdio. There is no network transport and no shared instance — a project's files, memory and sessions are reachable only from the process bound to that project's root.
The resolved root is logged at startup and shown by memory { action: "brief" }.
What to commit
Commit .claude/skills/ if you vendor the skill into a repo. Commit .agent/memory/ too
if you want the project's remembered facts, rules and thread history to travel with it;
the shipped .gitignore treats it as local state. .env always stays out of git.
Working agreement
memory { action: "brief", query: "what you are about to do" }— stack, rules, the facts that rank for that query, and where the last thread stopped.memory { action: "chat_start", title, goal }— get a chat id, pass it on later calls.Delegate:
agent { role: "coder", task: "..." }. Passsessionto continue a thread. Facts are captured from the answer automatically.memory { action: "chat_save", summary, next_steps, decisions }before finishing.
Mid-task, memory { action: "recall", query: "..." } answers from what is already known
instead of re-reading the codebase. memory { action: "projects" } lists every project
on this machine with its active chat.
See the skill contract for the full tool reference.
Tests
npm test # unit + integration, no API calls (~15s)
npm run test:live # real DeepSeek subagents in a temp sandbox project (~6 min)Live tests skip themselves when no API key is configured. They run every agent
against a throwaway fixture project in $TMPDIR, never a real repo. To run one:
node --import tsx --test --test-name-pattern="@coder writes" tests/live/agents.test.tsWhat subagents cannot see
Anything a subagent reads is sent verbatim to a model provider, so the boundary is enforced in the tools rather than left to the prompt.
Credential files are refused by every tool, reads and writes alike — .env*,
*.pem, *.key, id_rsa, .npmrc, .netrc, cloud credentials, secrets.*,
terraform.tfstate. This is not configurable. list_directory will not even name them.
Templates like .env.example and *.pub stay readable.
Ignored paths are skipped when walking the tree: build output, dependencies and
caches by default, plus everything in .gitignore and .agentignore. Both use
gitignore syntax, including **, character classes and ! negation:
# .agentignore — keep the agent out of things that are big or irrelevant
fixtures/**
*.generated.ts
!src/keep.generated.tsDot-directories such as .github and .claude are searchable — only the ignore
rules decide. Reads over 2 MB are refused with a pointer to search_files, and files
over 1 MB are skipped while searching.
Reading narrowly
read_file takes offset and limit, and returns line-numbered output:
[src/big.ts lines 100-104 of 401]
100| export const value99 = 99;
101| export const value100 = 100;Measured on a 400-line file: reading the whole thing is ~7,145 tokens, the five lines
that mattered are ~99. The numbers are also why file:line anchors in memory are
trustworthy — a subagent citing line 97 is reading "97" rather than counting.
search_files takes a real glob, so a search can be scoped before it runs rather than
filtered after: *.ts, **/*.test.ts, src/**, or a bare .md.
Orchestrated runs
agent runs one task. orchestrate runs a plan of them — a dependency graph, written
by the coordinating agent and executed verbatim:
orchestrate { action: "start", plan: {
goal: "Add refresh-token rotation",
tasks: [
{ id: "scan", role: "explore", task: "Map src/auth." },
{ id: "impl", role: "coder", task: "Add rotation.", needs: ["scan"] },
{ id: "tests", role: "coder", task: "Cover the new path.", needs: ["impl"] },
{ id: "audit", role: "security", task: "Audit it.", needs: ["impl"] },
{ id: "check", kind: "checkpoint", task: "Run npm test and report.", needs: ["tests", "audit"] },
{ id: "fix", role: "coder", task: "Fix what it reported.", needs: ["check"] }
]
}}tests and audit run at the same time; each dependent starts with its predecessors'
answers already in its context, capped at 6k chars each and 20k in total.
The scheduler makes no model calls. It resolves dependencies, holds a concurrency ceiling, and records state — arithmetic on a graph, so it is testable and cannot drift. Judgement about what to run stays with the agent that wrote the plan.
Checkpoints are where tests get run. Subagents cannot execute anything, so a
checkpoint task runs nothing: the graph stops, you run the suite, and the note you
approve with becomes the result its dependents read.
orchestrate { action: "approve", task: "check",
note: "2 failing: auth.test.ts:41 expects 401, got 500" }The run outlives the call. start returns the board immediately; wait parks until
a gate opens or the run ends, up to 4 minutes per call. Polling a twenty-minute run costs
more in tool calls than the run costs in tokens.
run-2026-08-06-77k2 [waiting] · Add a slugify helper alongside the existing string utilities
4/5 done · 20.7k tok · 1m12s
done scan explore 2.4k tok 14s
done impl coder 5.4k tok 17s src/slug.ts
done tests coder 9.4k tok 41s src/slug.test.ts
done audit security 3.5k tok 12s
awaiting verify checkpoint ← Run the test suite and report the output.Nothing is lost when the chat closes. Every state change is written to
.agent/runs/<id>.md through a temp file and a rename. On shutdown, in-flight model
calls are aborted and unfinished tasks are recorded as interrupted;
action: "resume" re-queues exactly those. A run left running by a process that no
longer exists is reported as interrupted rather than as working.
Failure policy | Effect on the graph |
| dependents are blocked, unrelated branches still finish |
| dependents run anyway and are told what failed |
| the whole run is cancelled |
Delegation. A task with allowSpawn gets a spawn_agent tool: it hands one piece
of its work to another subagent and only that subagent's final answer comes back, up to
two levels deep. The child appears as its own row in the run rather than as invisible
work. Note that a delegate may hold a role its parent does not — a read-only task with
allowSpawn can get files written — so set allowedTools to cap its delegates.
Parallel writes are refused, not merged. Two tasks writing the same file is the one way this plugin could silently destroy work: the loser's edit vanishes with no error anywhere. A task claims a file on first write and the other is refused by name. All writes go through a temp file and a rename, so no reader ever sees a half-written file.
Context pipeline
A subagent's own history is shaped before every model call, cheapest layer first — the ordering matters more than any single layer, because it means you never pay a model to do what arithmetic can:
Layer | Does | Fires when |
Budget | caps a single tool result, keeping head and tail | that result exceeds 6k tokens |
Prune | replaces old tool results with a reference to what they returned | tool output over 40k tokens and at least 20k is reclaimable |
Fold | writes a structured handoff note over the older turns | still over 85% of the usable window |
The last two turns are never touched, and compaction happens at 85% rather than at the cliff, so it never lands mid-task. Measured on a run reading five large files: 37,007 → 15,007 tokens, same answer.
Set DEEPSEEK_CONTEXT_WINDOW if your model's window is not 128k.
Memory
Plain markdown, no JSON — the agent reads this back on every run, and markdown costs a fraction of the tokens for the same content.
<project>/.agent/memory/PROJECT.md stack and modules, one line per package
<project>/.agent/memory/FACTS.md what is true about the code, with file:line anchors
<project>/.agent/memory/RULES.md conventions, always injected
<project>/.agent/memory/ARCHIVE.md retired facts, kept recoverable
<project>/.agent/memory/chats/<id>.md goal, state, decisions, next steps, files
<project>/.agent/memory/sessions/<id>.txt transcripts, pruned after 14 days
~/.deepseek-mcp/PROJECTS.md machine-wide project indexThree layers, each retrieved differently: facts by relevance to the task, rules always,
threads by recency. FACTS.md entries look like
- [a3f] Kestrel binds 0.0.0.0:6777 @server/src/Program.cs:30 #config x4 c0.90 2026-08-05Capture is automatic. After each subagent run a cheap DeepSeek pass proposes facts;
deterministic code merges them. A repeat claim reinforces the existing entry, a changed
value supersedes it and the old one moves to the archive. The model proposes, it never
rewrites the store — letting a model rewrite its own accumulated context is what makes
these systems collapse. Set MEMORY_AUTOCAPTURE=0 to disable.
Edits by hand are noticed. Each fact stores a hash of the lines its anchors point at. Anchors alone only prove a file still exists — the hash proves the code behind the claim is the code it was made about. Change a port by hand and the next prompt says:
- Kestrel binds IPAddress.Any on port 6777 [server/src/Program.cs:30]
— STALE: this code changed since, re-read before relying on itThe check runs automatically on the facts about to be injected, so a stale claim can never reach a prompt unlabelled. Only the anchored lines are hashed, so editing elsewhere in the same file leaves unrelated facts alone, and re-observing a claim clears the flag.
Forgetting is deliberate. memory { action: "verify" } re-checks every anchor
against the working tree; entries that no longer resolve lose confidence and retire.
memory { action: "compact" } also compresses overgrown threads and prunes transcripts.
memory { action: "stats" } reports what is held and what it costs on disk.
Sandbox escape is refused by default; set ALLOW_OUTSIDE_WORKSPACE=1 to disable that
check (not recommended).
Available Tools
20 toolsanalyze_repositoryC
Analyze repository directory structure, key dependencies, and high-level architectural design
Inputs: repository_tree (required), model, provider.
documentationC
Generate clean technical Markdown documentation for APIs, classes, or modules
Inputs: code (required), model, doc_type, provider.
explain_codeB
Explain step-by-step how a specific complex piece of code works
Inputs: code (required), model, provider.
generate_codeA
Generate a brand-new single file (Repository, Service, Controller, DTO, Entity, Validator, Middleware, Background Job, Migration, Stored Procedure, View, Interface, Extension, Configuration, etc.) from a specification using DeepSeek. Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, language, provider, +10 more.
generate_documentationA
Generate a full, saveable documentation set (README, API docs, architecture docs, Mermaid sequence diagrams) as file(s) — distinct from documentation, which returns inline Markdown for a single piece of content. Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, doc_set, provider, +2 more.
generate_filesA
Generate several related files in one call (e.g. a full module: interface + implementation + DTOs + validators + mapper + controller). Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, language, provider, +10 more.
generate_projectA
Generate a full project scaffold under a named architecture (Clean Architecture, Onion, Vertical Slice, Modular Monolith, Microservices, CQRS, Repository+UoW). Recommended for small-to-medium scaffolds in one call; for large projects call generate_files repeatedly per module instead of expecting one call to build an entire system. Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, database, language, +6 more.
generate_seedA
Generate realistic mock data / seed fixtures for database tables or API payloads
Inputs: schema (required), model, format, provider.
generate_sqlA
Generate SQL objects — stored procedures, views, functions, triggers, migrations, indexes — from a specification. Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, provider, database_type, +4 more.
generate_testsA
Generate a full, saveable test-suite (unit/integration/performance) as file(s) from a specification or existing code — distinct from write_tests, which returns inline review-style test code. Returns structured, saveable file content — never writes to disk itself.
Inputs: spec (required), model, provider, framework, +4 more.
refactor_codeB
Provide refactored version of code adhering to Clean Code, SOLID principles, and optimal patterns
Inputs: code (required), model, provider, refactor_goal.
review_architectureA
Analyze system architecture, design patterns, scalability, and coupling bottlenecks using Reasoner LLM
Inputs: architecture_description (required), model, provider.
review_codeA
Review a single file or code snippet for bugs, quality, and best practices using DeepSeek
Inputs: code (required), focus, model, language, +1 more.
review_folderB
Review multiple files within a folder to analyze relationships and module code quality
Inputs: folder_content (required), model, provider, folder_name.
review_performanceA
Identify performance bottlenecks, memory leaks, algorithmic complexity (Big O), and async I/O overhead
Inputs: code (required), model, provider.
review_projectC
Perform a comprehensive high-level project review utilizing DeepSeek Reasoner model
Inputs: project_summary (required), model, provider.
review_securityA
Perform a deep cybersecurity audit focusing on OWASP vulnerabilities, secret leaks, and access control
Inputs: code_or_config (required), model, provider.
review_sqlB
Review SQL queries, table schemas, database migrations, and index performance
Inputs: sql_content (required), model, provider, database_type.
summarizeA
Summarize complex codebases, documentations, or technical specifications
Inputs: text (required), model, provider.
write_testsB
Generate high-coverage unit or integration tests for the provided code
Inputs: code (required), model, provider, framework.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 20 tools
Several tools occupy adjacent territory (analyze_repository vs review_architecture vs review_project), and the write_tests/generate_tests distinction is subtle. Descriptions help but an agent may still hesitate between similar-sounding options.
Most tools follow a consistent verb_noun pattern (e.g., review_security, generate_code), but 'summarize' and 'documentation' break the pattern, and the two test-generation tools use different verbs for similar purposes.
20 tools is appropriate for a code assistance server, though it slightly exceeds the typical 3-15 range and pushes toward the heavier side.
The surface covers analysis, review (code, folder, project, architecture, security, performance, SQL), generation (code, files, SQL, tests, docs, project), documentation, summarization, explanation, refactoring, and seeding. No obvious gaps for its stated purpose.
Maintenance
Related MCP Connectors
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Related MCP Servers
- AlicenseAqualityCmaintenanceA multi-model AI orchestration MCP server for automated code review and LLM-powered analysis, integrating with Claude Code and OpenCode to orchestrate multiple AI models for code quality checks, security analysis, and multi-agent consensus.637MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides agentic code review powered by OpenAI-compatible models, designed for use with Claude Code.1MIT
- AlicenseCqualityDmaintenanceSingle MCP server providing over 500 developer tools for Claude Code, covering security, testing, documentation, and more.50098 npm3MIT
- AlicenseAqualityDmaintenanceMCP server that lets any agent or MCP host delegate tasks to Claude Code running headless, with tools for review, validation, analysis, and autonomous work.4353 npm2MIT