local-coder
Local Coder MCP Agent
Este proyecto empaqueta un flujo de trabajo de agente de programación local:
Un modelo de codificación Qwen se ejecuta localmente detrás de una API compatible con OpenAI
/v1/chat/completions.Un worker de Python se comunica con esa API local mediante el SDK de OpenAI.
Un servidor MCP
local-coderexponedelegate_to_local_codera Codex.Codex delega las tareas de implementación al worker local y luego revisa los tests y los diffs por sí mismo.
No se incluyen pesos de modelos. Usa tu propio directorio de modelos local mediante MODEL_DIR.
Arquitectura
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 workspaceEl worker puede listar archivos, leer archivos, escribir archivos, aplicar parches de texto exacto, ejecutar pytest, ejecutar una pequeña lista de comandos permitidos, buscar texto, inspeccionar el estado de git e inspeccionar el diff de git. Rechaza rutas fuera del espacio de trabajo seleccionado.
Related MCP server: Codex Workspace Bridge
Instalación
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 .envEdita .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 es el árbol de directorios que el worker puede editar. Para varias raíces, usa ALLOWED_WORKSPACE_ROOTS separadas por : en macOS/Linux.
Iniciar el servidor del modelo
Para un modelo MLX en Apple Silicon:
source .venv/bin/activate
./scripts/start_qwen3_coder_server.shEl script arranca:
python -m mlx_lm.server \
--model "${MODEL_DIR}" \
--host 127.0.0.1 \
--port 8080 \
--max-tokens 4096 \
--temp 0Cualquier servidor compatible con OpenAI funciona si expone http://127.0.0.1:8080/v1/chat/completions, o si actualizas LOCAL_CODER_BASE_URL.
Iniciar el servidor MCP manualmente
source .venv/bin/activate
./scripts/start_local_coder_mcp.shNormalmente Codex inicia el servidor MCP por ti desde config.toml.
Configurar Codex
Copia el bloque local-coder de config.example.toml a tu config.toml de Codex y reemplaza los marcadores de posición con valores locales:
[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}"Usa rutas locales reales solo en tu configuración privada de Codex, nunca en archivos versionados.
Delegar una tarea desde Codex
Ejemplo de prompt para 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.La carpeta examples/sandbox incluida es un pequeño proyecto pytest para pruebas de humo.
Errores Comunes
El espacio de trabajo no está dentro de un directorio raíz permitido
Configura SALLOWED_WORKSPACE_ROOT o ALLOWED_WORKSPACE_ROOTS para que el espacio de trabajo solicitado quede dentro de un directorio aprobado. Esto es intencional: el worker no debería poder editar archivos locales arbitrarios.
El worker superó el número máximo de pasos
Aumenta max_steps para tareas más grandes, o divide la tarea en pasos más pequeños. Las tareas buenas para el worker local son específicas y verificables.
El modelo no devolvió ningún texto utilizable
El servidor del modelo local devolvió una respuesta sin content, reasoning_content, reasoning ni thinking utilizables. Prueba esto:
Asegurate de que el servidor implementa chat completions compatibles con OpenAI.
Establece
LOCAL_CODER_ENABLE_THINKING=false.Reduce el tamaño de la tarea.
Prueba el servidor con una solicitud directa a
/v1/chat/completions.
La conexión falló
Confirmar que el servidor del modelo se está ejecutando, que el puerto coincide con LOCAL_CODER_BASE_URL y que ningún firewall ni proxy esté interceptando el tráfico de localhost.
Notas de Seguridad
No hagas commit de
.env, archivos de configuración privados de Codex, pesos de modelos, logs, claves ni cachés generadas.Mantén
ALLOWED_WORKSPACE_ROOTrestringido.El worker local puede editar y ejecutar comandos limitados dentro de los espacios de trabajo permitidos; revisa cada diff antes de aceptar los cambios.
Mantén el servidor API enlazado a
127.0.0.1a menos que tengas un plan de seguridad de red aparte.Este repositorio utiliza intencionadamente marcadores de posición como
${HOME},${MODEL_DIR},${PROJECT_ROOT}y${ALLOWED_WORKSPACE_ROOT}.
Ejecutar comprobaciones
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.pyAvailable Tools
1 tooldelegate_to_local_coderB
Delegate 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
delegate_to_local_coder
TDQS
Scored 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.
Maintenance
Related MCP Connectors
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).
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables ChatGPT to operate authorized local projects through MCP, including reading and modifying code, viewing Git changes, running configured programs, and reading local Codex sessions to continue work.53 npm7MIT
- AlicenseNot gradedqualityCmaintenanceEnables ChatGPT to submit tasks to a single explicitly bound local Codex workspace and conversation, then retrieve execution results, file contents, and diffs through MCP tools.MIT
- AlicenseAqualityCmaintenanceEnables MCP clients to delegate routine coding tasks to a local model in isolated git worktrees, using test results as a gate and the client as the reviewer before changes are merged.5MIT
- AlicenseNot gradedqualityBmaintenanceEnables Codex to delegate scoped coding tasks to DeepSeek Harness subagents over MCP using the official ACP, then wait for results, resume the same session with corrections, and forward permission requests. Read-only and workspace-write modes let results be reviewed and independently verified before acceptance.MIT