local-coder
Local Coder MCP Agent
Dieses Projekt bündelt einen Workflow für einen lokalen Coding-Agenten:
Ein Qwen-Coding-Modell läuft lokal hinter einer OpenAI-kompatiblen
/v1/chat/completions-API.Ein Python-Worker kommuniziert mit dieser lokalen API über das OpenAI SDK.
Ein
local-coder-MCP-Server machtdelegate_to_local_coderfür Codex verfügbar.Codex delegiert Implementierungsaufgaben an den lokalen Worker und prüft Tests und Diffs anschließend selbst.
Es sind keine Modellgewichte enthalten. Verwenden Sie Ihr eigenes lokales Modellverzeichnis über MODEL_DIR.
Architektur
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 workspaceDer Worker kann Dateien auflisten, Dateien lesen, Dateien schreiben, exakten Text patchen, pytest ausführen, eine kleine Whitelist von Befehlen ausführen, Text durchsuchen, den Git-Status anzeigen und den Git-Diff anzeigen. Er verweigert Pfade außerhalb des ausgewählten Arbeitsbereichs.
Related MCP server: Codex Workspace Bridge
Installation
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 .envLesen Sie die Datei .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 ist der Verzeichnisbaum, den der Worker bearbeiten darf. Für mehrere Wurzelverzeichnisse verwenden Sie ALLOWED_WORKSPACE_ROOTS, getrennt durch : unter macOS/Linux.
Modellserver starten
Für ein MLX-Modell auf Apple Silicon:
source .venv/bin/activate
./scripts/start_qwen3_coder_server.shDas Skript startet:
python -m mlx_lm.server \
--model "${MODEL_DIR}" \
--host 127.0.0.1 \
--port 8080 \
--max-tokens 4096 \
--temp 0Jeder OpenAI-kompatible Server funktioniert, wenn er http://127.0.0.1:8080/v1/chat/completions bereitstellt oder wenn Sie LOCAL_CODER_BASE_URL aktualisieren.
MCP-Server manuell starten
source .venv/bin/activate
./scripts/start_local_coder_mcp.shNormalerweise startet Codex den MCP-Server für Sie über config.toml.
Codex MCP konfigurieren
Kopieren Sie den local-coder-Block aus config.example.toml in Ihre Codex-config.toml und ersetzen Sie dann die Platzhalter durch lokale Werte:
[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}"Verwenden Sie reale lokale Pfade nur in Ihrer privaten Codex-Konfiguration, niemals in committeten Dateien.
Eine Aufgabe von Codex delegieren
Beispiel-Prompt an 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.Der enthaltene Ordner examples/sandbox ist ein kleines pytest-Projekt für Smoke-Tests.
Häufige Fehler
Der Arbeitsbereich liegt nicht in einem erlaubten Wurzelverzeichnis
Setzen Sie ALLOWED_WORKSPACE_ROOT oder ALLOWED_WORKSPACE_ROOTS so, dass der angeforderte Arbeitsbereich in einem zulässigen Verzeichnis liegt. Das ist beabsichtigt: Der Worker soll keine beliebigen lokalen Dateien bearbeiten können.
Der Worker hat die maximale Anzahl an Schritten überschritten
Erhöhen Sie max_steps für größere Aufgaben oder teilen Sie die Aufgabe in kleinere Schritte auf. Gute Aufgaben für den lokalen Worker sind spezifisch und überprüfbar.
Das Modell hat keine brauchbare Antwort geliefert
Der lokale Modellserver hat eine Antwort ohne brauchbaren content, reasoning_content, reasoning oder thinking zurückgegeben. Versuchen Sie Folgendes:
Verifizieren Sie, dass der Server OpenAI-kompatible Chat-Completions implementiert.
Setzen Sie
LOCAL_CODER_ENABLE_THINKING=false.Reduzieren Sie die Aufgabengröße.
Testen Sie den Server mit einer direkten
/v1/chat/completions-Anfrage.
Verbindung fehlgeschlagen
Stellen Sie sicher, dass der Modellserver läuft, der Port zu LOCAL_CODER_BASE_URL passt und keine Firewall und kein Proxy den localhost-Verkehr abfängt.
Sicherheit
Committen Sie keine
.env, keine private Codex-Konfiguration, keine Modellgewichte, keine Logs, keine Schlüssel und keine generierten Caches.Halten Sie
ALLOWED_WORKSPACE_ROOTeng begrenzt.Der lokale Worker kann Dateien bearbeiten und in erlaubten Arbeitsbereichen begrenzte Befehle ausführen. Prüfen Sie jeden Diff, bevor Sie Änderungen übernehmen.
Lassen Sie den Server an
127.0.0.1gebunden, es sei denn, Sie haben einen separaten Netzwerksicherheitsplan.Dieses Repository verwendet absichtlich Platzhalter wie
${HOME},${MODEL_DIR},${PROJECT_ROOT}und${ALLOWED_WORKSPACE_ROOT}.
Prüfungen ausführen
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