本项目封装了一个本地编码代理工作流：
一个 Qwen 编码模型在本地运行，并通过 OpenAI 兼容的 /v1/chat/completions API 对外提供服务。
一个 Python worker 通过 OpenAI SDK 与该本地 API 通信。
一个 local-coder MCP 服务器向 Codex 暴露 delegate_to_local_coder。
Codex 将实现任务转交给本地 worker，然后由它自行审查测试和 diff。
不包含模型权重。请通过 MODEL_DIR 使用你自己的本地模型目录。
Codex
-> MCP tool: delegate_to_local_coder(task, workspace, max_steps)
-> mcp_servers.local_coder.server
-> workers.coding.worker.CodingWorker
-> OpenAI-compatible local model server
-> restricted file/test/git tools inside the requested workspace该 worker 可以列出文件、读取文件、写入文件、对精确文本打补丁、运行 pytest、运行一个小型命令白名单、搜索文本、检查 git status 和检查 git diff。它会拒绝所选工作区之外的路径。
Related MCP server: Codex Workspace Bridge
git clone <your-repo-url>
cd local-coder-mcp-agent
python -m venv .venv
source .venv/bin/activate
python -m pip install -U pip
python -m pip install -e ".[dev,mlx]"
cp .env.example .env编辑 .env：
MODEL_DIR=${HOME}/models/Qwen3-Coder-30B-A3B-Instruct-4bit
ALLOWED_WORKSPACE_ROOT=${HOME}/AI/projects
LOCAL_CODER_BASE_URL=http://127.0.0.1:8080/v1
LOCAL_CODER_MODEL=default_model
LOCAL_CODER_API_KEY=localALLOWED_WORKSPACE_ROOT 是允许 worker 编辑的目录树。如果有多个根目录，请在 macOS/Linux 上使用以 : 分隔的 ALLOWED_WORKSPACE_ROOTS。
在 Apple Silicon 上使用 MLX 模型时：
source .venv/bin/activate
./scripts/start_qwen3_coder_server.sh脚本会启动：
python -m mlx_lm.server \
--model "${MODEL_DIR}" \
--host 127.0.0.1 \
--port 8080 \
--max-tokens 4096 \
--temp 0任何 OpenAI 兼容的服务器都可以工作，只要它暴露了 http://127.0.0.1:8080/v1/chat/completions，或者你更新 LOCAL_CODER_BASE_URL。
source .venv/bin/activate
./scripts/start_local_coder_mcp.sh通常情况下，Codex 会从 config.toml 中为你自动启动 MCP 服务器。
将 config.example.toml 中的 local-coder 块复制到你的 Codex config.toml 中，然后把占位符替换为本地值：
[mcp_servers.local-coder]
enabled = true
command = "${PROJECT_ROOT}/.venv/bin/python"
args = ["-m", "mcp_servers.local_coder.server"]
cwd = "${PROJECT_ROOT}"
[mcp_servers.local-coder.env]
LOCAL_CODER_BASE_URL = "http://127.0.0.1:8080/v1"
LOCAL_CODER_MODEL = "default_model"
LOCAL_CODER_API_KEY = "local"
ALLOWED_WORKSPACE_ROOT = "${ALLOWED_WORKSPACE_ROOT}"只能在你的私有 Codex 配置中使用真实本地路径，绝不要放入已提交批准的文件中。
给 Codex 的示例提示：
Use the local-coder MCP server and specifically call delegate_to_local_coder.
Workspace:
${ALLOWED_WORKSPACE_ROOT}/sandbox
Task:
Add multiply(a: int, b: int) -> int to calculator.py.
Requirements:
- Do not change add(), subtract(), or divide().
- Add pytest coverage for multiply().
- Run all tests.
- Inspect git diff before finishing.
After the local worker completes the task, review its changes yourself.
Do not implement the change yourself unless the local worker fails.随附的 examples/sandbox 文件夹是一个用于冒烟测试的小型 pytest 项目。
设置 ALLOWED_WORKSPACE_ROOT 或 ALLOWED_WORKSPACE_ROOTS，使请求的工作区位于允许目录内。这是有意为之：不应允许 worker 编辑任意本地文件。
对于更大的任务，请增加 max_steps，或将任务拆分为更小的步骤。好的本地 worker 任务应当具体且可验证。
本地模型服务器返回的响应中没有可用的 content、reasoning_content、reasoning 或 thinking。请尝试：
确认服务器实现了 OpenAI 兼容的 chat completions 接口。
设置 LOCAL_CODER_ENABLE_THINKING=false。
缩小任务规模。
直接使用 /v1/chat/completions 请求测试服务器。
确认模型服务器正在运行，并检查服务器上的端口与 LOCAL_CODER_BASE_URL 是否匹配，且没有防火墙或代理拦截 localhost 流量。
不要提交 .env、私有 Codex 配置文件、模型权重、日志、密钥或生成的缓存。
让 ALLOWED_WORKSPACE_ROOT 保持在一个较小的允许目录范围内。
本地 worker 可以在允许的的范围内编辑文件并运行受限命令；接受任何更改前，请检查每个 diff。
保持 API 服务器绑定到 127.0.0.1，除非你有独立的网络安全方案。
本仓库有意使用诸如 ${HOME}、${MODEL_DIR}、${PROJECT_ROOT} 和 ${ALLOWED_WORKSPACE_ROOT} 之类的占位符。
python -m pytest -q
python -m py_compile \
mcp_servers/local_coder/server.py \
workers/coding/client.py \
workers/coding/parser.py \
workers/coding/tools.py \
workers/coding/worker.pyDelegate a coding implementation task to the local Qwen worker.
The worker can inspect project files, patch code, create files, run tests, and inspect git diff. Codex should review the result afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| max_steps | No | ||
| workspace | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the worker can inspect files, patch code, create files, run tests, and inspect git diff, which clearly indicates a mutation of the workspace. It also suggests a follow-up review by Codex. This covers primary side effects but omits details like async behavior, failure modes, or timeouts, which are not 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, front-loading the purpose and then listing capabilities and a workflow note. There is zero fluff, and every sentence contributes meaning. It is appropriately sized for a tool of moderate complexity.
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?
While the output schema exists and could describe return values, the description omits essential parameter semantics, making it incomplete for correct invocation. It also lacks preconditions (e.g., workspace must be a local path) and any error/edge-case context. For a delegation tool, the agent needs to know how to construct the task and workspace.
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 has 0% description coverage, so the description must explain parameter meanings. It does not mention 'task', 'workspace', or 'max_steps' at all. An agent cannot infer what constitutes a valid 'workspace' (e.g., path, repo URL) or what 'max_steps' controls. This is a critical omission.
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 delegates a coding implementation task to a local Qwen worker, using the verb 'delegate' with a specific resource. It also lists the worker's capabilities, which distinguishes what the tool can do. However, it could be more explicit about the scope of 'implementation' (e.g., only code changes vs. tests), though it is not misleading.
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 it (for coding implementation tasks) but does not provide explicit guidance on when not to use it or alternatives. There are no sibling tools, so differentiation is not needed, but the description lacks conditions or prerequisites such as workspace requirements. The note to 'review the result afterwards' gives a follow-up action but not selection criteria.
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.
v0.1.0delegate_to_local_coderScored across 1 tool
There is only one tool, so there are no overlapping purposes or risk of selecting the wrong tool. The tool's purpose is clearly stated and unique within this server.
The single tool name uses a clear, descriptive verb-target structure: delegate_to_local_coder. With no other tools to conflict with, there is no naming inconsistency.
A single tool feels too thin for the broad local-coding scope described, which includes inspecting files, patching code, creating files, running tests, and checking diffs. The entire capability set is buried behind one opaque delegation endpoint.
The delegate tool covers task handoff and appears to return results for review, but there are no separate tools for status, cancellation, or finer-grained control of coding operations. This makes the surface usable for simple flows but incomplete for managing the full lifecycle of delegated work.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Remote MCP learning coach for coding agents.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
