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 "Install 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.
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.
Seven tools instead of thirty-four. agent, orchestrate, agent_control,
memory, review, generate, analyze — each with a role/kind/action
discriminator. 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
/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).
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"
}
}
}
}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.
Put your key in your shell profile — never in a repo:
export DEEPSEEK_API_KEY=your_actual_keynpm 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"]
}
}
}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_root argument on an individual tool call
PROJECT_ROOT environment variable
the 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" }.
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.
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: "..." }. Pass session to 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.
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.tsAnything 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.
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.
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.
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.
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).
Analyze repository directory structure, key dependencies, and high-level architectural design
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider | |
| repository_tree | Yes | Directory layout tree or package manifest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The word 'Analyze' implies a read-only operation, but it does not explicitly state whether it modifies anything, what permissions are needed, or what the output format is. This is a significant gap for a tool with no annotation safety hints.
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 a single, front-loaded sentence that directly conveys the tool's purpose without redundancies or fluff. Every word contributes, making it highly concise and well-structured.
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?
The description is minimal, lacking any information about return values, limitations, or when to choose this tool over the many sibling analysis/review tools. Without an output schema, it would be beneficial to mention what the analysis produces, but this is absent. The tool is not fully described in context.
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%, with all three parameters documented in the input schema. However, the tool description itself adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.
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 states a specific action ('Analyze') and a resource ('repository'), and lists concrete aspects (directory structure, key dependencies, high-level architectural design). This clearly separates it from generic 'analyze' tools, though it does not explicitly differentiate from closely related siblings like 'review_architecture'.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The description only states what the tool does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate clean technical Markdown documentation for APIs, classes, or modules
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to document | |
| model | No | Model to use (default: deepseek-chat) | |
| doc_type | No | Type of documentation (e.g. API Docs, README, JSDoc/Docstring) | |
| provider | No | AI Provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It only states that it generates Markdown documentation, leaving unspecified whether it writes to files, returns a string, requires network access, or modifies code. This is a significant gap without annotations to fall back on.
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 a single, concise sentence that immediately conveys the core function. There is no fluff, and it is front-loaded with the verb and resource. It is appropriately sized for the amount of information it provides.
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?
With no output schema and no annotations, the description must explain return values and behavioral context, but it does not. It fails to mention what the tool actually returns (e.g., Markdown string, file path), how doc_type changes output, or any limitations. Given the presence of sibling tools, the description is incomplete for safe and effective use.
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 the schema already documents all four parameters. The description does not add any extra meaning beyond that, such as how 'doc_type' influences the output or how 'model' and 'provider' are used. Baseline of 3 is appropriate when schema covers everything.
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's purpose: generating clean technical Markdown documentation for APIs, classes, or modules. However, it does not distinguish itself from the sibling tool 'generate_documentation', which likely serves a nearly identical purpose.
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 no guidance on when to use this tool versus alternatives like 'generate_documentation' or other generate_* tools. It only implies use for documentation generation but does not specify contexts, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain step-by-step how a specific complex piece of code works
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code snippet to explain | |
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool explains code step-by-step, but omits details about potential side effects, required permissions, or the nature of the response (e.g., format, length). This is minimal transparency beyond the basic action.
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 a single sentence with no wasted words. It clearly communicates the core function and is appropriately front-loaded. Every word contributes to understanding the tool's purpose.
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?
The tool has no output schema and no annotations, so the description needs to be self-sufficient. It lacks information about return values, limitations, usage context, or when to prefer this tool over siblings. For a 3-parameter tool, this is a notable gap.
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 the baseline is 3. The description adds no extra meaning beyond the schema; the phrase 'specific complex piece of code' loosely aligns with the 'code' parameter but does not provide additional detail about the parameter values or their usage.
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 uses a specific verb "explain" and a specific resource "a specific complex piece of code", further clarifying the behavior with "step-by-step". It clearly distinguishes from sibling tools like review_code or refactor_code, which focus on different actions.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or suggestions for other tools. The description only states what the tool does, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Full specification of what to generate: purpose, inputs/outputs, behavior, dependencies | |
| model | No | Model to use | |
| language | No | Target programming language (e.g. typescript, csharp, python) | |
| provider | No | AI Provider | |
| file_name | No | Desired file name | |
| file_type | No | Kind of file (e.g. Repository, Service, Controller, DTO, Entity, Validator, Middleware, Background Job, Migration, Stored Procedure, View, Interface, Extension, Configuration) | |
| framework | No | Framework in use (e.g. ASP.NET Core, NestJS, Express, Spring Boot) | |
| architecture | No | Architecture to follow (e.g. Clean Architecture, Onion, Vertical Slice, Modular Monolith, Microservices, CQRS, Repository+UoW) | |
| coding_style | No | Coding style/formatting conventions to follow | |
| project_rules | No | Project-specific rules or constraints the generated code must respect | |
| target_folder | No | Target folder/namespace the generated file(s) belong to | |
| design_pattern | No | Specific design pattern(s) to apply | |
| project_context | No | Existing project tree, dependencies, namespaces, or conventions the output must match | |
| naming_convention | No | Naming convention to follow (e.g. PascalCase classes, camelCase methods) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the key behaviors: returns content, never writes to disk, and uses DeepSeek. This is useful for an agent to know there are no filesystem side effects. However, it does not mention potential length limits, model cost, or exact response schema.
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 a single, well-structured sentence that front-loads the core action ('Generate a brand-new single file') and packs in a comprehensive list of file types plus a critical behavioral caveat. It avoids redundant boilerplate and earns each word.
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 14 parameters and no output schema, the description provides a concise but adequate overview: generation source (specification), model (DeepSeek), and return format (structured, saveable content). It does not detail parameter relationships or the exact JSON return envelope, but the schema fills parameter gaps and the key output behavior is clear.
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?
The input schema already has 100% description coverage for all 14 parameters, including detailed definitions for spec, file_type, and other fields. The description adds no parameter-specific semantics beyond what the schema provides, only referencing 'specification' and file type examples already in the schema.
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?
Description states the tool generates a brand-new single file from a specification, enumerating supported file types (Repository, Service, Controller, etc.). It distinguishes itself by returning saveable content and explicitly not writing to disk, a unique trait among sibling generation tools.
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 implies appropriate usage: use when you need a single generated file's content for review/saving rather than direct disk writes. It contrasts with tools like generate_files by emphasizing 'single file' and 'never writes to disk itself', but does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Code/project to document or description of what should be documented | |
| model | No | Model to use (default: deepseek-chat) | |
| doc_set | No | Which docs to produce (e.g. "README, API Docs, Architecture Docs, Sequence Diagram") | |
| provider | No | AI Provider | |
| target_folder | No | Target folder for the generated doc file(s) | |
| project_context | No | Existing project structure/conventions the docs must reflect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses an important behavioral trait: 'never writes to disk itself'. It also clarifies the return type ('structured, saveable file content'), which is a non-obvious detail. This goes beyond what the schema alone conveys and helps the agent understand side-effect-free behavior.
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 two sentences long and front-loaded with the core purpose. The second sentence adds a comparative distinction and a critical behavioral detail. Every clause earns its place; no redundancy or fluff.
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 there is no output schema, the description compensates by explaining what the tool returns ('structured, saveable file content') and what the generated set includes. It omits some optional details like file naming or how the model parameter is used, but the essential contextual information is present for a tool with this level of complexity.
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 the baseline is 3. The description adds minimal extra meaning for parameters, though it indirectly clarifies 'target_folder' by stating the tool never writes to disk itself, implying the folder is a suggested path rather than an immediate write location. No deeper parameter-level enrichment.
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 uses a specific verb ('Generate') with a precise resource ('a full, saveable documentation set') and enumerates content types (README, API docs, architecture docs, Mermaid sequence diagrams). It explicitly distinguishes itself from the sibling tool 'documentation' by contrasting scope and output format.
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 a clear when-to-use signal by comparing with the sibling 'documentation' ('distinct from documentation, which returns inline Markdown for a single piece of content'). It does not explicitly list other alternative tools, but the key competing option is covered sufficiently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Full specification of the module/feature to generate | |
| model | No | Model to use | |
| language | No | Target programming language (e.g. typescript, csharp, python) | |
| provider | No | AI Provider | |
| framework | No | Framework in use (e.g. ASP.NET Core, NestJS, Express, Spring Boot) | |
| components | No | List/description of the components expected (e.g. "IUserRepository, UserRepository, IUserService, UserService, DTOs, Validators, Mapper, Controller, Unit Tests") | |
| module_name | No | Name of the module/feature (e.g. User, Order, Authentication) | |
| architecture | No | Architecture to follow (e.g. Clean Architecture, Onion, Vertical Slice, Modular Monolith, Microservices, CQRS, Repository+UoW) | |
| coding_style | No | Coding style/formatting conventions to follow | |
| project_rules | No | Project-specific rules or constraints the generated code must respect | |
| target_folder | No | Target folder/namespace the generated file(s) belong to | |
| design_pattern | No | Specific design pattern(s) to apply | |
| project_context | No | Existing project tree, dependencies, namespaces, or conventions the output must match | |
| naming_convention | No | Naming convention to follow (e.g. PascalCase classes, camelCase methods) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait: returns structured, saveable file content and never writes to disk itself. This is critical and well-stated, though it doesn't detail the output structure or other potential side effects.
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?
Two sentences, front-loaded with the purpose statement, followed by a concise behavioral note. No redundancy or unrelated details.
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?
For a tool with 14 parameters and no output schema, the description is minimal but covers the core purpose and non-write behavior. However, it doesn't clarify how parameters relate, what the structured output looks like, or whether the optional parameters override or supplement the required 'spec'.
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 descriptions cover all 14 parameters (100%), so the description adds little beyond the schema. The example listing component types is illustrative but not a semantic addition to parameter ownership or format.
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?
Clearly states the action (generate), the resource (several related files), and provides a concrete example (interface + implementation + DTOs + validators + mapper + controller). This distinguishes it from single-file generation tools in the sibling list, though it doesn't name them explicitly.
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 example implies use when a full module or multiple related files are needed, but there is no explicit comparison to sibling tools like generate_code or generate_project, nor any statement of when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Description of the project/system to scaffold | |
| model | No | Model to use (default: deepseek-reasoner) | |
| database | No | Database technology (e.g. PostgreSQL, SQL Server) | |
| language | No | Target programming language | |
| provider | No | AI Provider | |
| framework | No | Framework in use (e.g. ASP.NET Core, NestJS) | |
| architecture | No | Architecture/template to use (e.g. Clean Architecture, Onion, Vertical Slice, Modular Monolith, Microservices, CQRS, Repository+UoW) | |
| target_folder | No | Root folder for the scaffolded project | |
| project_context | No | Existing project structure/conventions the scaffold must fit into, if any | |
| naming_convention | No | Naming convention to follow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: 'Returns structured, saveable file content — never writes to disk itself,' which tells the agent that the tool is non-destructive and requires the caller to persist results. It does not detail edge cases like existing projects or error responses, but the main behavioral contract is clear.
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?
Three sentences, each earning its place: first states purpose and scope, second gives usage vs. alternative guidance, third explains return behavior and side-effect. Information is front-loaded and free of filler.
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?
Despite having 10 parameters, no output schema, and no annotations, the description covers the essential context: what the tool produces (full scaffold), when to use a different tool (large projects), the output format (structured, saveable file content), and its non-destructive nature. This is sufficient for an agent to select and invoke the 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?
Schema coverage is 100%, so the baseline is 3 and the description does not need to explain each parameter. The description adds little beyond repeating architecture examples already present in the schema's architecture field. It does not enrich semantics for spec, model, database, or other parameters.
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 uses a specific verb and resource: 'Generate a full project scaffold under a named architecture' and lists concrete architecture options. This clearly distinguishes it from sibling tools like generate_files or generate_code, which focus on individual files or code snippets.
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?
It explicitly states when to use this tool ('Recommended for small-to-medium scaffolds in one call') and when not to ('for large projects call generate_files repeatedly per module instead of expecting one call to build an entire system'). It also clarifies the output behavior ('never writes to disk itself'), giving strong decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate realistic mock data / seed fixtures for database tables or API payloads
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-chat) | |
| format | No | Desired output format (e.g. SQL INSERT, JSON, CSV) | |
| schema | Yes | Schema structure or entity description | |
| provider | No | AI Provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'generate' without disclosing whether the tool writes to files, returns data, or requires any permissions. No side effects, rate limits, or other behavioral traits are mentioned.
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 a single sentence, fourteen words, and front-loads the core action. Every word is necessary and there is no fluff or repetition.
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 that there is no output schema and no annotations, the description is somewhat sparse. It states the purpose and the schema covers parameters, but it does not explain what the tool returns or any behavioral caveats. For a simple generation tool, this is acceptable but not fully complete.
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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal extra meaning by mentioning 'database tables or API payloads', which provides context for the schema parameter, but it does not enrich parameter semantics beyond that.
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 generates realistic mock data or seed fixtures for database tables or API payloads. It uses a specific verb ('generate') and resource ('mock data / seed fixtures'), and distinguishes itself from sibling tools like generate_sql or generate_code.
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 implies usage for creating seed data, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools suggest there are other generation tools, but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate SQL objects — stored procedures, views, functions, triggers, migrations, indexes — from a specification. Returns structured, saveable file content — never writes to disk itself.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Specification of the SQL object(s) to generate: purpose, tables involved, parameters, expected behavior | |
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider | |
| database_type | No | DB Engine (e.g. PostgreSQL, SQL Server, MySQL, SQLite) | |
| target_folder | No | Target folder for the generated SQL file(s) | |
| project_context | No | Existing schema/tables/conventions the output must match | |
| sql_object_type | No | Kind of SQL object (e.g. Stored Procedure, View, Function, Trigger, Migration, Index) | |
| naming_convention | No | Naming convention for SQL objects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explicitly states that the tool returns structured, saveable file content and never writes to disk itself, which is a critical safety and usage trait. It does not cover other behaviors like error handling or rate limits, but for a generation tool this is a strong disclosure of side effects.
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?
Two sentences that immediately state the action, enumerate the object types, and disclose the key non-persistence behavior. Every word adds value, with no fluff or repeated schema information.
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 tool's moderate complexity (8 parameters, 1 required) and no output schema, the description provides adequate context: it decribes the output as structured, saveable file content and clarifies the no-disk-write behavior. The schema covers all parameters, so the description is complete enough, though more detail on the exact return structure (e.g., file paths or content layout) would improve it.
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?
The input schema has 100% coverage with descriptive parameter comments, so the description does not need to add parameter details. The description provides examples of object types and the fact that output is file content, but it does not elaborate on parameter relationships or add meaning beyond the schema, so the baseline of 3 is appropriate.
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?
Clearly states it generates SQL objects from a specification, enumerating object types (stored procedures, views, etc.). This distinguishes it from sibling tools like generate_code or generate_files by focusing specifically on SQL objects and explicitly framing its output as file content, not a mutation or analysis operation.
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 clearly implies when to use this tool: when you need to generate SQL objects from a specification. It does not explicitly name alternatives or state when-not-to-use, but the scope is unambiguous enough that an agent can infer the appropriate context, distinguishing it from more general code generation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | Code to test or specification of behavior to cover | |
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider | |
| framework | No | Test framework (e.g. Jest, Vitest, JUnit, xUnit, PyTest) | |
| test_scope | No | Scope of tests (e.g. Unit, Integration, Performance, or combination) | |
| target_folder | No | Target folder for the generated test file(s) | |
| project_context | No | Existing project conventions the tests must match | |
| naming_convention | No | Test file/naming convention |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals a key trait: 'never writes to disk itself' and indicates output is 'structured, saveable file content.' It does not mention error handling, permissions, or other side effects, but the core safety behavior is transparently disclosed.
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 two sentences, compact, and front-loaded with the main purpose before the distinction. Every phrase adds value, especially the explicit contrast with write_tests and the safety clarification about not writing to disk.
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 8 parameters, no annotations, and no output schema, the description covers the essential context: what it does, the key alternative, and the return behavior. It is slightly light on details like how target_folder is used or what 'full' means, but the schema covers parameter details and the description provides enough behavioral context.
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?
All 8 parameters are documented with descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds a little context by mentioning 'specification or existing code' and 'unit/integration/performance,' but it does not provide additional syntax or format details beyond the schema.
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 generates a 'full, saveable test-suite (unit/integration/performance) as file(s)' from a specification or existing code, naming the resource (test suite) and the action (generate). It explicitly differentiates itself from sibling write_tests, which returns inline review-style code, making the purpose unmistakable.
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 distinguishes generate_tests from write_tests by explaining that write_tests 'returns inline review-style test code,' implying generate_tests is for saveable file content. This provides clear when-to-use guidance and an explicit alternative, satisfying the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide refactored version of code adhering to Clean Code, SOLID principles, and optimal patterns
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to refactor | |
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider | |
| refactor_goal | No | Specific refactoring goal (e.g. extract functions, convert to async, apply pattern) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not specify whether the tool returns refactored code as a string, modifies files in place, preserves original behavior, or has any side effects. This is a significant gap for a transformation tool.
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 a single, front-loaded sentence with no redundant words. It efficiently captures the core purpose and quality targets, making it easy to parse and act upon.
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 output schema, no annotations, and four parameters, the description is notably incomplete. It omits return value expectations, usage context, and behavioral constraints, leaving an agent without sufficient guidance for proper invocation and result handling.
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 the baseline is 3. The description mentions 'Clean Code, SOLID principles, and optimal patterns', which adds context to the refactor_goal parameter but does not detail parameter formats or relationships beyond what the schema already provides.
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 action ('Provide refactored version of code') and the resource ('code'), with explicit quality criteria (Clean Code, SOLID, optimal patterns). This distinguishes it from sibling tools like review_code (analysis only) and generate_code (creation from scratch).
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 implies usage for improving existing code but does not explicitly state when to use it versus alternatives like generate_code or review_code. There are no exclusions or alternative recommendations, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze system architecture, design patterns, scalability, and coupling bottlenecks using Reasoner LLM
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider | |
| architecture_description | Yes | Architecture specification or component layout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'using Reasoner LLM' which indicates the model, but does not explicitly state that the operation is read-only or describe the output format. The 'analyze' verb suggests non-destructive analysis, but this is not explicit.
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 a single concise sentence, front-loading the purpose and scope without extraneous information.
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?
The tool has no output schema and no annotations. The description covers the input scope and model, but does not indicate what the analysis output looks like or any limitations. Given the moderate complexity, this is a minor gap.
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 covers all three parameters with descriptions, so baseline is 3. The description mentions 'Reasoner LLM' which aligns with the model parameter, but adds no additional parameter semantics beyond the schema.
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 verb 'Analyze' plus specific resource 'system architecture, design patterns, scalability, and coupling bottlenecks' clearly states the tool's function. This distinct focus differentiates it from siblings like review_security or review_performance.
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 implies usage for architecture-level analysis but does not explicitly state when to use this vs alternatives. It provides clear context ('Analyze system architecture...') but no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review a single file or code snippet for bugs, quality, and best practices using DeepSeek
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code content to review | |
| focus | No | Specific focus area (e.g. error handling, performance) | |
| model | No | Model to use (default: deepseek-chat) | |
| language | No | Programming language (e.g. typescript, python, csharp) | |
| provider | No | AI Provider (default: deepseek) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It mentions 'using DeepSeek', which implies an external AI service, but does not disclose that code is sent to a third party, potential privacy/data-sensitivity implications, or operational details like rate limits, latency, or failure modes. For a tool that exfiltrates code to an external model, this is a significant transparency gap.
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 a single sentence, front-loaded with the action ('Review a single file or code snippet') and ends with the model ('using DeepSeek'). Every word carries meaning; there is no filler or repetition.
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?
There is no output schema and no annotations, so the description must cover return values, side effects, and prerequisites. It fails to explain that code is sent to an external AI service, what the output format looks like, or any limitations (e.g., file size, model required). This is incomplete for a tool that makes an external API call, especially given the presence of sibling review tools that could be confused with it.
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?
The input schema already provides descriptions for all 5 parameters, achieving 100% schema coverage. The tool description adds no additional parameter-level semantics beyond the schema, so the baseline score of 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?
The description uses the clear verb 'review' with a specific resource ('single file or code snippet') and scope (bugs, quality, best practices). It distinguishes itself from sibling tools like review_folder, review_project, review_security, and review_performance by focusing on a single file or snippet and a general review scope.
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 clearly states the tool is for a single file or code snippet, providing context on when to use it. However, it does not explicitly mention alternatives like 'review_folder' or 'review_project' for larger scopes, nor does it state when not to use it. The single-file scope is a clear contextual cue, but the absence of exclusions or alternative references keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review multiple files within a folder to analyze relationships and module code quality
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider (default: deepseek) | |
| folder_name | No | Name of the folder being reviewed | |
| folder_content | Yes | Aggregated content of files in the folder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the review purpose. It does not mention whether files are modified, how content is aggregated, or any prerequisites or side effects, leaving the agent to guess at the tool's behavior.
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 a single, front-loaded sentence with no filler or redundant content, making it efficiently worded.
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?
The tool has no output schema and no annotations, so the description must explain return values and behavior, but it only provides a high-level purpose. It also fails to mention how the folder content should be passed or what the analysis result looks like, leaving significant gaps for a tool with 4 parameters.
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?
All four parameters have schema descriptions covering 100% of the parameters, so the schema carries the burden. The description mentions 'multiple files' and 'folder' which roughly aligns with folder_name and folder_content, but adds no additional semantics about model/provider or expected input format.
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 reviews multiple files in a folder to analyze relationships and module code quality, using a specific verb and resource. It distinguishes from siblings like review_code (likely single-file) and review_project (broader scope) by focusing on folder-level analysis.
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 implies usage for folder-level code review but provides no explicit guidance on when to use this versus sibling tools. No alternatives or exclusions are mentioned, so the agent must infer context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify performance bottlenecks, memory leaks, algorithmic complexity (Big O), and async I/O overhead
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Code to optimize for performance | |
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does disclose that the tool performs analysis ('identify') and specifies the categories of issues it detects, which is useful. However, it does not mention whether the tool is read-only, what the output format is, or any side effects, leaving some behavioral ambiguity.
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 a single, well-structured sentence with no unnecessary words. It front-loads the verb and lists all key performance concerns efficiently, making it immediately scannable.
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 tool's simplicity (one required parameter, no output schema), the description provides enough context to understand its purpose and scope. It could be improved by mentioning what kind of output the user can expect, but the description is largely complete for a straightforward analysis tool.
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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter context, but it also doesn't need to since the schema already explains each parameter adequately.
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 uses the specific verb 'Identify' and clearly specifies the resource: performance bottlenecks, memory leaks, algorithmic complexity (Big O), and async I/O overhead. This distinguishes it from sibling tools like review_code, review_security, and review_architecture by focusing on performance-specific concerns.
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 clear context by stating it identifies performance-related issues, making it obvious when to use this tool (e.g., when code performance needs analysis). It does not explicitly mention when not to use it or name alternatives, but the context is clear enough to guide basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a comprehensive high-level project review utilizing DeepSeek Reasoner model
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider (default: deepseek) | |
| project_summary | Yes | Overview and code structure of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only notes that the DeepSeek Reasoner model is used, which hints at a backend dependency, but gives no details on input expectations (that it needs a project_summary rather than repository access), output format, or potential side effects. This is insufficient for a tool with zero annotation support.
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 a single sentence, making it concise and front-loaded with the main purpose. The phrase 'utilizing DeepSeek Reasoner model' is slightly awkward and arguably redundant given the 'model' parameter's default, but it does not waste many words. It is appropriately short for a simple purpose.
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 lack of an output schema and annotations, the description is too minimal. It does not explain what the tool returns (e.g., a textual review report), how it consumes the project_summary, or how it differs from similar comprehensive tools like 'summarize'. The one-liner leaves significant gaps in the agent's understanding, making selection and invocation riskier.
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?
The input schema already provides full descriptions for all three parameters: model, provider, and project_summary. The description adds no extra meaning beyond what the schema already documents, and does not clarify how the parameters interrelate or influence the review output. With 100% schema coverage, a baseline of 3 is appropriate.
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 performs a 'comprehensive high-level project review', providing a specific verb and resource. It also mentions using the DeepSeek Reasoner model, which adds specificity. However, it does not explicitly distinguish itself from sibling tools like review_architecture or review_code, so it misses the full sibling differentiation needed for a 5.
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 offers no explicit guidance on when to use this tool versus its many siblings. It doesn't mention suitable use cases, exclusions, or alternatives. The phrase 'high-level' implies it's for broad overviews, but this is not clearly stated as a directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a deep cybersecurity audit focusing on OWASP vulnerabilities, secret leaks, and access control
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-reasoner) | |
| provider | No | AI Provider | |
| code_or_config | Yes | Code or configuration to audit for security flaws |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to disclose behavioral traits. The description lacks details on whether the operation is read-only, what data might be sent to an external AI provider, or the format of the returned output. The phrasing 'deep cybersecurity audit' adds little beyond the purpose.
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 a single sentence that is front-loaded with the core action and includes specific focus areas. Every word contributes to the meaning, and there is no redundant or filler content.
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?
The description adequately states the tool's purpose and focus, and the schema covers parameters. However, there is no output schema, so the description should mention the expected return value (e.g., a security report), which it does not. The lack of behavioral and usage details makes it a minimally viable description.
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%, with each parameter (model, provider, code_or_config) already described. The tool description adds no additional parameter semantics, reducing its value beyond the schema to baseline.
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 performs a deep cybersecurity audit with specific focus areas (OWASP, secret leaks, access control), using a specific verb and resource. It effectively distinguishes itself from sibling review tools like review_code and review_performance.
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 clearly defines the context for use ('deep cybersecurity audit') and the specific security concerns, which helps an agent decide when to select it. However, it does not explicitly mention alternative tools or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review SQL queries, table schemas, database migrations, and index performance
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider | |
| sql_content | Yes | SQL queries or DDL schema definition | |
| database_type | No | DB Engine (e.g. PostgreSQL, SQL Server, MySQL, SQLite) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not reveal any behavioral traits beyond the act of reviewing, such as whether it sends data to an external AI model, returns a detailed report, or has any side effects. This lack of transparency leaves significant uncertainty for the agent.
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 a single, concise sentence that front-loads the verb and resource list. It avoids filler and uses every word meaningfully, making it easy to scan.
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?
The description lists what it reviews but omits expected output, return format, or any behavioral context. There is no output schema, and the description does not explain what the agent should expect after invocation, making it incomplete for a review tool that presumably returns analysis or suggestions.
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%, and each parameter has a clear description (e.g., sql_content, database_type). The tool description itself adds no extra parameter context, but since the schema already provides full semantics, the baseline score of 3 is appropriate.
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's purpose with a specific verb 'Review' and lists concrete resources: SQL queries, table schemas, database migrations, and index performance. This distinguishes it from sibling tools like generate_sql or review_code by focusing on SQL-specific review tasks.
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?
No guidance is provided on when to use this tool versus alternatives such as generate_sql or review_performance. There is no mention of prerequisites, explicit use cases, or exclusions, leaving the agent to infer applicability without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize complex codebases, documentations, or technical specifications
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Content to summarize | |
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the high-level action without revealing key traits such as whether the operation is read-only, what output format to expect, or any dependencies like API keys. The mention of 'model' and 'provider' parameters hints at configurability but does not clarify side effects or requirements.
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 a single, front-loaded sentence that states the core purpose without unnecessary words. It earns its place and is easy to parse quickly.
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 tool's moderate complexity (3 parameters, no output schema), the description is functional but not fully complete. It lacks information about return values or usage scenarios, though the schema fills in parameter details. The description could benefit from a brief note on expected output or positioning against sibling tools.
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?
The schema already provides 100% coverage with clear descriptions for all three parameters (text, model, provider). The description adds no additional parameter semantics, so the baseline score of 3 is appropriate given the schema's completeness.
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 identifies the tool's action ('Summarize') and the resource types ('complex codebases, documentations, or technical specifications'). This verb+resource structure effectively distinguishes it from sibling tools like 'explain_code' or 'review_code', which imply different purposes.
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 implies when to use the tool (for summarizing complex technical material) but provides no explicit guidance on alternatives or exclusions. It does not mention scenarios where a different tool would be more appropriate, leaving usage context somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate high-coverage unit or integration tests for the provided code
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Target code for test generation | |
| model | No | Model to use (default: deepseek-chat) | |
| provider | No | AI Provider | |
| framework | No | Test framework (e.g. Jest, Vitest, JUnit, xUnit, PyTest) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the intended outcome ('generate tests') without mentioning side effects, output format, file writes, or required permissions.
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 a single, front-loaded sentence with no redundant words. It states the core purpose immediately.
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?
The description is too sparse for a tool with no output schema and no annotations. It fails to specify whether tests are returned as text, written to files, or what the output format is, making it incomplete for confident use.
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 the baseline is a 3. The description adds minimal extra meaning (e.g., 'high-coverage', 'unit or integration') but does not elaborate on parameter usage beyond the schema.
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 generates tests for provided code, with a specific verb and resource. However, it does not differentiate from the sibling tool 'generate_tests', which appears to serve a similar purpose.
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 implies usage: given code, generate tests. It lacks explicit guidance on when to use this over alternatives like 'generate_tests', and provides no exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_repositorydocumentationexplain_codegenerate_codegenerate_documentationgenerate_filesgenerate_projectgenerate_seedgenerate_sqlgenerate_testsrefactor_codereview_architecturereview_codereview_folderreview_performancereview_projectreview_securityreview_sqlsummarizewrite_testsSeveral 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Abbas-F-R/DeepSeek-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
