Skip to main content
Glama

Local Coder MCP Agent

Dieses Projekt bündelt einen Workflow für einen lokalen Coding-Agenten:

  1. Ein Qwen-Coding-Modell läuft lokal hinter einer OpenAI-kompatiblen /v1/chat/completions-API.

  2. Ein Python-Worker kommuniziert mit dieser lokalen API über das OpenAI SDK.

  3. Ein local-coder-MCP-Server macht delegate_to_local_coder für Codex verfügbar.

  4. 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 workspace

Der 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 .env

Lesen 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=local

ALLOWED_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.sh

Das Skript startet:

python -m mlx_lm.server \
  --model "${MODEL_DIR}" \
  --host 127.0.0.1 \
  --port 8080 \
  --max-tokens 4096 \
  --temp 0

Jeder 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.sh

Normalerweise 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_ROOT eng 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.1 gebunden, 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.py

Available Tools

1 tool
delegate_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.

NameRequiredDescriptionDefault
taskYes
max_stepsNo
workspaceYes

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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. 1 tool updatev0.1.0
    • First observeddelegate_to_local_coder

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count2/5

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.

Completeness3/5

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

ActivitySlowing
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables 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 npm
    7
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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