Skip to main content
Glama
deenesjakoruzh
starmania7

local-coder

by starmania7
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Local Coder MCP Agent

This project packages a local coding agent workflow:

  1. A Qwen coding model runs locally behind an OpenAI-compatible /v1/chat/completions API.

  2. A Python worker talks to that local API with the OpenAI SDK.

  3. A local-coder MCP server exposes delegate_to_local_coder to Codex.

  4. Codex delegates implementation tasks to the local worker, then reviews tests and diffs itself.

No model weights are included. Use your own local model directory through MODEL_DIR.

Architecture

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

The worker can list files, read files, write files, patch exact text, run pytest, run a small allowlist of commands, search text, inspect git status, and inspect git diff. It refuses paths outside the selected workspace.

Related MCP server: Grok-in-Codex

Install

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

Edit .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 is the directory tree the worker is allowed to edit. For multiple roots, use ALLOWED_WORKSPACE_ROOTS separated by : on macOS/Linux.

Start The Model Server

For an MLX model on Apple Silicon:

source .venv/bin/activate
./scripts/start_qwen3_coder_server.sh

The script starts:

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

Any OpenAI-compatible server works if it exposes http://127.0.0.1:8080/v1/chat/completions, or if you update LOCAL_CODER_BASE_URL.

Start The MCP Server Manually

source .venv/bin/activate
./scripts/start_local_coder_mcp.sh

Normally Codex starts the MCP server for you from config.toml.

Configure Codex MCP

Copy the local-coder block from config.example.toml into your Codex config.toml, then replace placeholders with local values:

[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}"

Use real local paths only in your private Codex config, never in committed files.

Delegate A Task From Codex

Example prompt to 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.

The included examples/sandbox folder is a tiny pytest project for smoke tests.

Common Errors

Workspace is not inside an allowed root

Set ALLOWED_WORKSPACE_ROOT or ALLOWED_WORKSPACE_ROOTS so the requested workspace is inside an approved directory. This is intentional: the worker should not be allowed to edit arbitrary local files.

Worker exceeded maximum number of steps

Increase max_steps for larger tasks, or split the task into smaller steps. Good local-worker tasks are specific and verifiable.

Model returned no usable text

The local model server returned a response without usable content, reasoning_content, reasoning, or thinking. Try:

  • Confirm the server implements OpenAI-compatible chat completions.

  • Set LOCAL_CODER_ENABLE_THINKING=false.

  • Reduce task size.

  • Test the server with a direct /v1/chat/completions request.

Connection failed

Confirm the model server is running, the port matches LOCAL_CODER_BASE_URL, and no firewall or proxy is intercepting localhost traffic.

Security Notes

  • Do not commit .env, private Codex config files, model weights, logs, keys, or generated caches.

  • Keep ALLOWED_WORKSPACE_ROOT narrow.

  • The local worker can edit and run limited commands inside allowed workspaces; review every diff before accepting changes.

  • Keep the API server bound to 127.0.0.1 unless you have a separate network security plan.

  • This repository intentionally uses placeholders such as ${HOME}, ${MODEL_DIR}, ${PROJECT_ROOT}, and ${ALLOWED_WORKSPACE_ROOT}.

Run Checks

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
taskYes
max_stepsNo
workspaceYes

Output Schema

ParametersJSON 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. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observeddelegate_to_local_coder
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
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

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/starmania7/local-coder-mcp-agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server