このプロジェクトは、ローカルコーディングエージェントのワークフローをパッケージしたものです:
Qwen コーディングモデルが、OpenAI 互換の /v1/chat/completions API の背後でローカルに実行されます。
Python ワーカーは、OpenAI SDK を使用してそのローカル API とやり取りします。
local-coder MCP サーバーは delegate_to_local_coder を Codex に公開します。
Codex は実装タスクをローカルワーカーに委任し、テストと diff は Codex 自身でレビューします。
モデルの重みは含まれていません。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ワーカーは、ファイルの一覧表示、ファイルの読み取り、ファイルの書き込み、完全一致テキストによるパッチ適用、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 は、ワーカーが編集を許可されているディレクトリツリーです。複数のルートを指定する場合は、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 0http://127.0.0.1:8080/v1/chat/completions を公開する OpenAI 互換サーバーであればどれでも動作します。または 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 を設定してください。これは意図的な仕様です。ワーカーが任意のローカルファイルを編集できないようにするためです。
大きなタスクでは max_steps を増やすか、タスクをより小さなステップに分割してください。ローカルワーカーに適したタスクは、具体的で検証可能なものです。
ローカルモデルサーバーが、使用可能な 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 は狭い範囲に保ってください。
ローカルワーカーは許可されたワークスペース内での編集と限定されたコマンドの実行ができます。変更を受け入れる前にすべての 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).
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
