The DeepSeek MCP Patch Worker server provides AI-powered code patching, review, autonomous agent management, and a DeepSeek–Codex bridge, with both synchronous and asynchronous workflows.
Code Patching:
generate_patch – Generate a validated candidate unified diff for a task and file context, with optional model selection (deepseek-v4-pro or deepseek-v4-flash), constraints, and test failure context.
review_patch – Review an untrusted candidate patch and return a corrected diff (or empty if no correction needed).
Background Patch Jobs:
submit_patch_job – Start a long-running streamed patch generation job, returning a job ID.
get_patch_job – Poll status and aggregate stream progress of a background job.
get_patch_result – Retrieve the final validated result or current non-terminal status.
cancel_patch_job – Request cooperative cancellation of a running background job.
Autonomous Agent Management:
Submit single or batch tasks for DeepSeek agents to modify code in isolated Git worktrees.
Monitor progress with long-polling, budget tracking, and a compact status panel.
Fetch complete or partial patches from agent tasks.
Send follow-up instructions to resume incomplete tasks using the same session and worktree.
Record review outcomes after validation, release worktrees, and apply reviewed results to the main repository.
Optionally use structured edits for deterministic modifications.
DeepSeek Responses Bridge:
Convert Codex Responses API requests to DeepSeek Chat Completions, supporting text streaming and serial tool calls.
Provide health checks and query bridge capabilities (bridge_health, get_bridge_capabilities).
Securely handle reasoning content with authenticated encryption.
Local Capabilities:
get_capabilities – Query worker capabilities without external API calls.
Security & Validation:
Strictly limit patch modifications to specified allowed_paths, reject binary patches, out-of-scope paths, and oversized responses.
Perform deterministic security checks: symlink escape detection, git diff --check, limits on changed files and diff lines.
Persist only task summaries, hashes, progress, and validated results (no full prompts or inference content).
Generates and reviews Git unified diffs for code changes, with path validation to ensure patches only modify allowed directories.
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 Patch Worker generate a patch to fix the null pointer in user.py"
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-mcp：保留原有候选补丁工具，并提供由 Sol 调度的并发 DeepSeek 自主代理池。自主代理只在隔离 Git worktree 中修改和测试，不自动合并到主工作区。
deepseek-bridge：把 Codex Responses API 转换为 DeepSeek Chat Completions，使 DeepSeek 可以作为原生 Codex custom agent 的模型 provider。
非 DeepSeek 官方项目。调用 DeepSeek API 会发送数据并产生费用，请先阅读 SECURITY.md。
同步生成或审查候选补丁：generate_patch、review_patch
后台长任务：submit_patch_job、get_patch_job、get_patch_result、cancel_patch_job
本地能力查询：get_capabilities（不调用 API）
Bridge 查询：bridge_health、get_bridge_capabilities
自主代理：单任务/批量提交、状态面板、长轮询、结果获取、follow-up、取消和释放
严格限制补丁只能修改 allowed_paths 中的路径
拒绝二进制补丁、越权路径和超限响应
只持久化任务摘要、哈希、聚合进度和已校验结果，不持久化完整提示词、文件上下文或推理内容
Responses Bridge 支持文本流、串行函数/custom 工具调用、稳定工具别名和 token usage
Bridge 明确拒绝非流式请求、超过 128 个工具以及 web/image/file-search/computer hosted 工具
每个自主写任务使用独立 detached Git worktree，最终补丁再次接受写入范围和完整性校验
Related MCP server: CodePeel MCP Server
自主代理使用以下调用链：
GPT-5.6 Sol → deepseek-mcp → codex exec → DeepSeek Bridge → DeepSeek
↓
Shell/apply_patch/tests主仓库必须是干净的 Git 工作区，并位于 DEEPSEEK_AGENT_ROOTS 下。MCP 为每个任务从
当前 HEAD 创建独立 worktree；DeepSeek 可以在其中检查代码、修改文件和运行测试，MCP
不会把结果自动合并到主工作区。
Sol 应先调用 submit_agent_batch，一次提交最多八个任务。批次通过 task_size 明确指定
small（小任务）或 large（大任务）。每个任务提供 task、
write_scope，以及可选的 task_name、constraints 和 model。write_scope 支持仓库
相对文件和 src/** 形式的 glob。提交立即返回 batch_id 和 task_id。
随后调用：
wait_agent_events(batch_id, after_event_id)任务结束时调用立即返回；否则会聚合期间的进度事件，小任务每 60 秒轮询一次、最多 10 次，
大任务每 180 秒轮询一次、最多 15 次。把返回的 next_event_id 传入下一次调用，直到
all_terminal=true；响应中的 polling 会按任务给出当前次数、剩余次数和是否耗尽。预算由
服务端 scheduler 在任务真正开始执行后逐项计数；排队时间和所有状态查询都不消耗预算，也不会
仅因查询而创建 revision。语义检查点和 scheduler tick 会保存可查询的阶段结果。预算耗尽时，
MCP 会停止尚未完成的执行回合，并
使用同一 session 启动只读总结回合；总结时间为普通轮询间隔的 3 倍，即小任务最多 180 秒、
大任务最多 540 秒。总结完成后返回 partial_completed 和经过校验的部分补丁。返回值包含结构化事件、完成结果和
get_agent_dashboard 使用的紧凑状态面板。普通 MCP notification 不负责唤醒模型；长轮询
工具返回本身就是结果进入 Sol 上下文的交接点。
完成后由 Sol 调用 get_agent_result 审查完整或部分补丁、处理多个任务间的冲突、应用补丁并在
主工作区重新测试。不完整的任务可通过 send_agent_followup 恢复同一 Codex session 和
worktree。list_agent_result_revisions 和 get_agent_stage_result 可读取历史阶段；Sol 应在
写入主工作区并验证后调用 record_agent_review，以 revision 和 patch_sha256 记录审核结果。
验收完成后调用 release_agent_task 清理隔离 worktree。
MCP 服务重启后，启动对账会把未完成的任务转成带可审核局部补丁的 partial_completed
revision（stop_reason=server_restarted），并保留可恢复的 Codex session 与 worktree；
服务不会在启动时自动续跑或应用任何补丁。Sol 审核后如需继续，调用
resume_agent_task(task_id, prompt) 显式恢复：它只允许恢复 interrupted 或
partial_completed 任务，要求 worktree、base commit、session 与 rollout 文件均存在，复用
原 session、worktree 和模型，并且只重置该任务自身的预算，不影响同批其他任务。多个
MCP 实例共享同一状态目录时，批次的 scheduler lease 保证同一 tick 只被一个实例推进；
实例退出后，另一个实例在 lease 过期后接管并把孤儿任务转为可审核的 partial checkpoint。
小任务默认使用确定性结构化编辑（roadmap 6.1）：submit_agent_task /
submit_agent_batch 接受 prefer_structured_edits（auto 启发式、on 强制、
off 禁用）。启发式规则：small 任务 + 不超过 3 个 write_scope 模式 + 任务描述
不含重构/跨文件信号时，agent 只读分析 worktree 并在最终消息中输出结构化
edits JSON（path / expected_file_sha256 / operation="replace" /
expected_text / replacement / occurrence）；Worker 校验 SHA-256、精确文本
匹配与 occurrence 后确定性应用，再走与直接编辑相同的 git diff 收集与安全校验管线。
校验失败（VALIDATION_FAILED）返回同 session 修复一次；安全拒绝（scope 越界、
symlink、敏感路径等，PATCH_INVALID）不重试。结果 revision 附带 edits_applied
审计字段。能力响应中 structured_edits_supported=true、
structured_edits_routing="auto"。
确定性安全验证（roadmap 6.3）在收集与写回双路径执行：write_scope、symlink 逃逸、
git diff --check、补丁大小、二进制、敏感路径（.env/密钥/凭据文件名与私钥块
内容）、变更文件数（≤50）与 diff 行数（≤20,000）上限；apply_reviewed_result
写回前还会解析补丁目标路径复检 symlink 逃逸。所有校验失败统一为
PATCH_INVALID 错误码。
需要 Python 3.10 或更高版本。
git clone https://github.com/prelearn-code/deepseek-mcp.git
cd deepseek-mcp
python -m venv .venvLinux/macOS：
.venv/bin/python -m pip install -U pip
.venv/bin/python -m pip install -e .
export DEEPSEEK_API_KEY="your-key"Windows PowerShell：
.venv\Scripts\python.exe -m pip install -U pip
.venv\Scripts\python.exe -m pip install -e .
$env:DEEPSEEK_API_KEY = "your-key"不要把真实密钥写进 Git、TOML 示例或命令历史。除环境变量外，Bridge 和 MCP worker
会自动读取 Codex 用户配置目录下的 mcp-secrets.env。Linux/WSL 默认路径是
~/.config/codex/mcp-secrets.env，文件权限必须为 0600：
install -d -m 700 ~/.config/codex
printf 'export DEEPSEEK_API_KEY=%s\n' 'your-key' > ~/.config/codex/mcp-secrets.env
chmod 600 ~/.config/codex/mcp-secrets.env环境变量优先于文件内容；可通过 DEEPSEEK_SECRETS_FILE 指定其他文件。加载器不会执行
文件中的 Shell，只解析允许的 DeepSeek 配置项，因此同一文件中的其他 MCP key 会被忽略。
Bridge 默认只监听本机 127.0.0.1:8787：
.venv/bin/deepseek-bridge若 key 已写入上述持久化文件，无需先运行 source。
健康检查无需认证：
curl http://127.0.0.1:8787/healthz本机默认配置只需要 DEEPSEEK_API_KEY。Bridge 仅监听 127.0.0.1，因此 Codex provider 不需要额外认证。若确实需要监听非回环地址，必须另外设置 DEEPSEEK_BRIDGE_TOKEN，Codex 也需用该 token 发送 Bearer 认证；Bridge 会拒绝在无 token 时绑定非回环地址。可通过 --host、--port 或对应的环境变量调整监听地址。
将 config.example.toml 中的 provider 和 MCP 表复制到用户级 ~/.codex/config.toml，并替换 Python 的绝对路径。Codex 会忽略项目级 .codex/config.toml 中的 model provider，因此 provider 必须配置在用户级文件。
将 deepseek_worker.agent.toml.example 复制为：
~/.codex/agents/deepseek_worker.toml把模板中的 model_catalog_json 替换为仓库内 deepseek-model-catalog.json 的绝对路径。该目录为 Codex 提供 DeepSeek 的上下文窗口、串行工具和 apply_patch 能力；没有它时未知模型会使用降级元数据，核心编码工具可能不完整。
重启 Codex 后，要求父代理使用 agent_type="deepseek_worker" 创建子代理。使用 fork_turns="none" 或有限的最近轮次，不要复制完整长对话。子代理会出现在 /agent 中，其工具仍由 Codex 执行，Bridge 只负责模型协议转换。模板关闭 hosted web search；如果继承的 MCP、插件或 connector 展开后超过 DeepSeek 的 128 工具限制，需要在该 agent 配置中禁用无关工具。
Codex 0.146 的 Multi-Agent V2 会把子任务正文放入 OpenAI 专用的
encrypted_content，第三方 provider 无法解密。使用 DeepSeek custom agent 时，当前需要由
Multi-Agent V1 父线程调度。例如：
codex -m gpt-5.4 -c 'features.multi_agent_v2=false'然后要求父线程创建 deepseek_worker。已验证同一 DeepSeek 子线程可以完成代码修改、运行
测试并接受 follow-up。GPT-5.6 父线程当前会强制选择 V2，不适合作为 DeepSeek custom agent
的调度父线程；DeepSeek 作为直接根 provider 不受该限制。
本项目新增的 MCP 自主代理池不使用 Codex Multi-Agent handoff，因此 GPT-5.6 Sol 可以直接
调用 submit_agent_task 或 submit_agent_batch 调度 DeepSeek；这些任务显示在
get_agent_dashboard 中，而不是 CLI 的 /agent 原生线程列表中。
Windows 的 MCP command 应改为类似：
command = "C:/absolute/path/deepseek-mcp/.venv/Scripts/python.exe"重启 Codex 后运行 codex mcp list，或在 Codex 中输入 /mcp。示例使用 env_vars 转发已存在的环境变量，并将工具审批设为 prompt，因为每次模型调用都可能发送代码并产生费用。
其他支持 STDIO 的 MCP 客户端可用相同入口启动：
/absolute/path/.venv/bin/python -m deepseek_worker.server环境变量 | 用途 | 默认值 |
| 必需的 API 密钥 | 无 |
| 可选的持久化配置文件路径 | Codex 用户配置目录下的 |
| OpenAI-compatible API 地址 |
|
| MCP 工具未显式传入 |
|
| 可选；非回环监听时必需的本地 Bearer token | 无 |
| Bridge 监听地址 |
|
| Bridge 监听端口 |
|
| 上游请求及流读取超时（秒） |
|
| MCP |
|
| 可选的 32 字节 URL-safe Base64 reasoning 加密密钥 | 自动创建持久化密钥文件 |
| reasoning 加密密钥文件 | Agent state 目录下的 |
| Bridge 请求生命周期与 token 用量账本 | reasoning 密钥同目录下的 |
| Flash 单次 completion budget |
|
| Pro 单次 completion budget |
|
| 后台任务数据库目录 | 操作系统的用户 state 目录 |
| 后台并发数 |
|
| 自主任务数据库、Bridge日志和worktree目录 | 用户state目录 |
| 允许代理访问的仓库根目录，多个路径用系统路径分隔符分隔 | MCP启动目录 |
| 并发自主代理数 |
|
| 单批最大任务数 |
|
| 单个执行回合硬上限（秒）；包含最后轮询调度余量 |
|
| 单次长轮询最大等待时间（秒） |
|
| 内部 | 从 |
| 可选的内部 Codex DeepSeek 模型目录覆盖 | 包内目录文件 |
默认模型为 deepseek-v4-flash，也支持 deepseek-v4-pro。官方 API 当前使用 POST /chat/completions、JSON Output 和流式响应。
Bridge v2 默认启用 DeepSeek thinking，并要求串行工具调用。工具轮次的
reasoning_content 会经过带认证加密，以 Responses reasoning item 的不透明内容交给 Codex
保存并在下一轮回传；Bridge 重启后使用持久化密钥恢复。Bridge 不把原始 reasoning 写入普通
日志或任务结果；请求账本只保存状态、终止原因、用量和字符/工具计数。当前仍不支持并行 tool calls、hosted 工具或 Codex Multi-Agent V2 的 OpenAI
专用加密 handoff。Codex 继续负责 thread、上下文压缩、工作区权限和工具执行。
自主代理并发发生在 MCP 任务池层，而不是单个 DeepSeek response 内。内部 Codex worker
关闭 MCP、apps 和继续创建子代理的能力，避免递归调用。MCP重启时仍处于活动状态的任务会
标记为 interrupted；其 worktree 会保留供检查和显式释放，第一版不会自动恢复进程。
finish_reason=length 会映射为 response.incomplete，Agent Job 会从已有 Codex session 和
worktree 做一次同模型恢复；再次耗尽时使用同一已选模型生成只读阶段总结并返回
partial_completed，不会自动把 Flash 升级到 Pro。只有调用方明确指定时才使用 Pro。旧的一次性
Patch Job 仍是兼容接口，长审阅和跨文件修改应使用 Agent Job。
任务执行预算由服务端 scheduler 按墙钟时间推进：小任务保持 60 秒/10 ticks，大任务保持
180 秒/15 ticks。wait_agent_events、dashboard 和结果查询不增加 tick，多客户端查询不会提前
耗尽预算。session、工具/命令完成、文件变化、测试和 agent message 会保存语义 checkpoint；
传输和 reasoning 活动只更新时间。MCP 重启后会从残留隔离 worktree 保存可审核的 partial
revision。
测试结果使用 passed、failed、inconclusive 和 not_run。当测试命令的退出码缺失，或
未启用 pipefail 的输出管道可能掩盖真实失败时，结果为 inconclusive，不能作为通过依据。
Sol 使用 record_agent_review 接受精确的 task_id + revision + patch_sha256 后，可显式调用
apply_reviewed_agent_result 写回。写回要求主仓库 HEAD 未变化、工作区干净、scope/hash 匹配
且 git apply --check 通过；同一 revision 不能重复应用。
测试不会调用真实 API：
.venv/bin/python -m pip install -e ".[dev]"
.venv/bin/python -m pytest -q
.venv/bin/python -m build
.venv/bin/deepseek-bridge --help
.venv/bin/python tests/codex_bridge_smoke.py真实 DeepSeek 自主代理验收是显式 smoke，不进入默认测试：
.venv/bin/python tests/agent_pool_live_smoke.py
.venv/bin/python tests/agent_pool_live_smoke.py --model deepseek-v4-pro实网 smoke 会为当前源码启动独立随机端口 Bridge，避免误用机器上仍在运行的旧协议进程。
GitHub Actions 会在 Linux、Windows 和 macOS 的 Python 3.10/3.13 上运行相同验证。
返回的补丁和原生子代理生成的修改始终是不可信候选内容。父 Codex 仍需审查完整 diff 并重新运行测试。allowed_paths 只能约束补丁 worker 的输出路径，不能约束原生子代理，也不能识别输入中是否包含敏感数据。
Request cooperative cancellation of a background streamed job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The term 'cooperative cancellation' hints at non-forceful termination but lacks details on side effects, idempotency, or what happens if already completed.
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?
Extremely concise (one phrase) but at the cost of completeness; boundary of appropriate conciseness.
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, one param, and related siblings, the description is insufficient. Lacks mention of expected behavior (e.g., job may not stop immediately), potential failures, or post-cancellation status checks.
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 has one parameter 'job_id' with no description; description coverage is 0%. The description does not explain how to obtain job_id or its 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 states the verb 'cancel' and the resource 'background streamed job', which is clear and specific. However, it doesn't differentiate from sibling tools like 'get_patch_job' or 'submit_patch_job'.
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 on when to use this tool versus alternatives; missing context like 'use this to stop a running job when it is no longer needed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a validated candidate unified diff; this tool never edits the repository.
Use deepseek-v4-pro for complex work and deepseek-v4-flash for routine changes. file_context should label each supplied file with its repository-relative path. allowed_paths is the exact list of files the returned patch may add, edit, or delete. On a repair round, send current file contents plus exact test/build failures.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| model | No | deepseek-v4-pro | |
| constraints | No | ||
| file_context | Yes | ||
| allowed_paths | Yes | ||
| test_failures | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states the tool never edits the repository, which is the key behavioral trait. Additional clarity about validation or side effects would improve this, but the main constraint is clearly 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 5 sentences long, front-loading the core purpose and then adding usage guidelines. It is mostly concise, though some repetition could be trimmed. The structure is logical.
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 has 6 parameters and no output schema or annotations, the description provides a good overview but lacks detail on task and constraints parameters, output format, or error behavior. It is adequate but not exhaustive.
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 0%, so the description must add meaning. It explains file_context should include repository-relative paths, allowed_paths defines which files the patch can modify, and provides context for test_failures. However, task and constraints parameters are not described, leaving gaps.
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 validated candidate unified diff and explicitly notes it never edits the repository. This specific verb-resource combination distinguishes it from siblings like submit_patch_job and review_patch.
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 advises using deepseek-v4-pro for complex work and deepseek-v4-flash for routine changes, and specifies that on a repair round the agent should include current file contents and test/build failures. While it provides context for when to use different models, it does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return local worker capabilities without calling DeepSeek.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that no DeepSeek call is made, but says nothing about potential side effects, cost, or what 'capabilities' entails. The behavioral disclosure is minimal.
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?
A single sentence of 7 words is highly concise and front-loaded. No wasted text; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters or output schema, the description lacks context about what 'capabilities' are and how this tool fits into the patch workflow suggested by siblings. It is incomplete for an agent to decide when to invoke 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?
There are no parameters, so the schema is trivially covered. The description adds context beyond the schema by specifying the resource and the fact that no external call is made, justifying a baseline of 4.
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 returns 'local worker capabilities' and distinguishes it by noting it does so without calling DeepSeek. This is a clear verb-resource pair that implies a read operation, though sibling differentiation is implicit.
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 explicit guidance on when to use this tool versus alternatives. The description implies it is for getting capabilities locally, but does not mention when to prefer it or mention any alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return persisted status and aggregate stream progress for a background job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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 only mentions 'persisted status and aggregate stream progress' without detailing side effects, permissions, or rate limits.
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?
Single sentence with no fluff, but would benefit from additional context. Efficient but not maximally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists and the description omits details about return format, status values, or progress interpretation. Inadequate for practical 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 coverage is 0% and the description does not explain the job_id parameter beyond its existence. No format, source, or constraints are provided.
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 clearly states the verb 'return' and resources 'persisted status and aggregate stream progress for a background job'. It distinguishes from sibling tools like cancel_patch_job or get_patch_result.
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 checking job status, but provides no explicit guidance on when to use this versus alternatives like get_patch_result or submit_patch_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a persisted validated result, or the current non-terminal status.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. Mentions that it returns either a persisted result or non-terminal status, but doesn't elaborate on what triggers each, side effects, or idempotency. Insufficient for a mutation-adjacent 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?
Single sentence, no fluff. Front-loaded with action. However, it could add useful detail without becoming lengthy.
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, description should cover return value details (e.g., format of status, possible values). It mentions 'non-terminal status' but doesn't define it. Lacks completeness for a tool with simple interface.
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?
Single parameter job_id with 0% schema description coverage. Description does not explain what job_id is or its format. Agent must infer from name alone.
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 clearly states it returns a 'persisted validated result' or 'current non-terminal status', which distinguishes it from siblings like get_patch_job (which may return the job itself) and submit_patch_job. The verb 'return' is specific.
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 explicit guidance on when to use this versus alternatives like get_patch_job. Context suggests it's for checking result/status after submission, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Review an untrusted candidate patch and return a corrected replacement diff, or an empty patch when no correction is justified.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| model | No | deepseek-v4-pro | |
| constraints | No | ||
| file_context | Yes | ||
| test_results | No | ||
| allowed_paths | Yes | ||
| candidate_patch | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the tool returns a corrected diff or empty patch, but lacks details on side effects, rejection handling, or system state changes. The term 'untrusted' hints at security but is insufficient.
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 wasted words. It could benefit from structuring, but remains concise and clear.
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 7 parameters (4 required), no output schema, and no annotations, the description fails to provide essential context. Key terms like task, file_context, and allowed_paths are left undefined, and output format is vague.
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 0%, and the description adds no parameter-level information. It only mentions 'candidate patch' implicitly, but none of the other 6 parameters (e.g., task, file_context, allowed_paths) are explained.
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 verb 'review' and the resource 'untrusted candidate patch', with specific outcomes of returning a corrected replacement diff or an empty patch. This distinguishes it from siblings like generate_patch (create) and submit_patch_job (submit).
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 explicit when-to-use or when-not-to-use guidance is provided. The description implies use for security review of patches, but does not mention alternatives like generate_patch or submit_patch_job for different stages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a long-running streamed patch job and return a local job ID immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| model | No | deepseek-v4-pro | |
| task_name | No | ||
| constraints | No | ||
| file_context | Yes | ||
| allowed_paths | Yes | ||
| test_failures | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden. It mentions the job is 'long-running' and 'streamed' and returns an ID immediately, but does not disclose potential side effects, required permissions, rate limits, or what happens on failure. Critical behavioral traits are missing.
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 of 18 words that efficiently conveys the core purpose and key characteristics. Every word adds value, and there is no 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?
Despite a complex 7-parameter schema and no output schema, the description only covers high-level functionality. It omits explanations of parameter roles, return structure beyond a job ID, and any behavioral caveats. The agent lacks sufficient context to use the tool effectively.
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 0% description coverage for its 7 parameters, and the tool description provides no explanation of what parameters like 'task', 'file_context', or 'allowed_paths' mean. The agent cannot determine parameter semantics from the description alone, severely hindering correct invocation.
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 clearly specifies the action ('submit') and resource ('patch job'), adds behavioral details ('long-running', 'streamed', 'returns local job ID immediately'), and is easily distinguishable from sibling tools like get_patch_job or cancel_patch_job.
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?
Description gives no explicit guidance on when to use this tool versus alternatives. Sibling tools are listed but no comparisons or exclusion criteria are provided. The agent is left to infer usage context from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: generating, reviewing, submitting, canceling, and querying patches. The get_patch_job and get_patch_result are clearly differentiated by status vs. result.
All tools follow a consistent verb_noun pattern in snake_case (e.g., cancel_patch_job, get_patch_result). No mixed conventions or vague verbs.
7 tools is well-scoped for a patch generation and management server. Each tool serves a clear purpose without redundancy or excessive granularity.
The set covers the full lifecycle of patch jobs (generate, review, submit, cancel, monitor, retrieve). Minor gaps exist, such as a tool to list all jobs or delete old results, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prelearn-code/deepseek-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server