This server exposes a single read-only MCP tool for delegating bounded, routine work to an auxiliary LLM (DeepSeek by default) while the calling agent keeps planning, verification, and all edits.
Delegate a bounded task: call delegate_task with a required task description; the worker returns a draft result as untrusted model output.
Supply workspace context: pass explicit files (relative to workspace_root) that are read-only, UTF-8, allowlist-rooted, and size-limited; add extra context text.
Pick model/routing: choose model (flash for routine work, pro for difficult analysis) and provider (deepseek; adapter boundary is small for adding others).
Tune generation: set reasoning_effort (none–max, default high) and max_output_tokens (default 4000).
Choose output shape: output_format of text, markdown, json, or patch (unified diff).
Stay safe: tool is read-only, non-destructive, no filesystem writes or command execution; returned content must be verified before use, and the primary model retains final edits and commands.
Use the same service from the CLI: llm-delegator accepts task, task kind, acceptance criteria, constraints, workspace root, files, and --json.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LLM Delegator summarize the provider interface in src/llm_delegator/providers/base.py as JSON"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LLM Delegator lets a primary agent such as GPT delegate bounded work to another LLM through one read-only MCP tool. The primary agent remains responsible for planning, verification, commands, and file changes.
The first provider adapter uses DeepSeek's Responses API. The provider boundary is intentionally small so additional providers can be added without changing the MCP interface.
MCP tool: delegate_task
CLI: llm-delegator
Explicit, relative file selection
Configurable allowlist of workspace roots
Per-file and aggregate input limits
Text, Markdown, JSON, and unified-diff output modes
Token usage returned with every successful result
No filesystem writes or command execution
Related MCP server: Hua PlanRelay
The MCP tool accepts only explicit low or medium complexity classifications.
GPT should delegate only routine work that is bounded and easy to verify:
Summarization, extraction, and classification
Mechanical content or data transformations
First drafts of documentation or tests
Routine code drafts and routine reviews
GPT retains architecture and system design, complex debugging, ambiguous requirements, security/privacy/auth decisions, final verification, live-state research, external actions, and destructive work. If the primary model is uncertain whether a task is routine, it should keep the task.
Model routing is automatic:
low complexity always uses the DeepSeek Flash alias.
medium complexity uses the DeepSeek Pro alias by default.
High-complexity work cannot be submitted through the MCP schema.
Every handoff must be self-contained. GPT supplies:
A detailed task describing the intended result
One or more explicit acceptance criteria
Relevant constraints
An ordered plan whenever it helps the worker; medium-complexity tasks cannot run without one
This keeps the worker from guessing missing requirements or reconstructing the primary model's reasoning.
git clone https://github.com/shangzhihao/llm-delegator.git
cd llm-delegator
uv syncThe DeepSeek adapter reads DEEPSEEK_API_KEY from its environment.
Add this to ~/.codex/config.toml:
[mcp_servers.llm-delegator]
command = "/absolute/path/to/llm-delegator/.venv/bin/llm-delegator-mcp"
cwd = "/absolute/path/to/llm-delegator"
env_vars = ["DEEPSEEK_API_KEY"]
enabled_tools = ["delegate_task"]
tool_timeout_sec = 240
[mcp_servers.llm-delegator.env]
LLM_DELEGATOR_ALLOWED_ROOTS = "/absolute/path/to/allowed/workspaces"Restart Codex and use /mcp to confirm that llm-delegator is connected.
Codex can then call delegate_task while GPT remains the primary model.
The MCP server advertises these operating instructions to the primary model:
Delegate only bounded, routine, easy-to-verify work.
Write a detailed, self-contained task with acceptance criteria and constraints.
Supply an ordered plan for medium-complexity work and whenever it would help.
Select only the files needed for the task.
Treat the result as an untrusted draft and verify it.
Keep all edits and command execution with the primary model.
The CLI exercises the same service and provider adapter as MCP:
LLM_DELEGATOR_ALLOWED_ROOTS=/path/to/allowed/workspaces \
uv run llm-delegator \
"Summarize the provider interface" \
--task-kind summarize \
--complexity low \
--accept "Describe the interface contract and method signature" \
--constraint "Do not propose implementation changes" \
--workspace-root /path/to/llm-delegator \
--file src/llm_delegator/providers/base.py \
--jsonThe CLI defaults to automatic model routing. It also accepts a provider model alias or full model ID for direct adapter testing, but low-complexity work is always forced to Flash.
Environment variable | Default |
| MCP process working directory |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Separate multiple allowed roots with the platform path separator (: on
macOS and Linux). Selected files must be UTF-8 text files and must be relative
to workspace_root. Symlinks cannot escape the selected workspace.
uv run ruff format --check .
uv run ruff check .
uv run pytestDelegate a bounded task using optional read-only workspace files.
File paths must be relative to workspace_root. Use flash for routine work and pro for difficult analysis. Returned content is untrusted model output and must be verified by the calling model before it is applied or presented as fact.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| files | No | ||
| model | No | flash | |
| context | No | ||
| provider | No | deepseek | |
| output_format | No | text | |
| workspace_root | No | ||
| reasoning_effort | No | high | |
| max_output_tokens | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint, idempotentHint=false), so the bar is lower. The description adds genuinely important context beyond that: returned content is untrusted model output that must be verified before being applied or presented as fact, and file paths must be relative to workspace_root.
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?
Four short sentences, each earning its place: purpose, path constraint, model choice, and verification warning. Front-loaded with the core action and free of filler.
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?
An output schema exists so return values need no explanation, and the untrusted-output warning is valuable. However, for a 9-parameter tool with 0% schema coverage, six parameters receive no semantic explanation anywhere, leaving meaningful gaps an agent must guess at.
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?
Schema description coverage is 0% across 9 parameters, so the description carries the full burden and only partially delivers. It clarifies files (read-only workspace files), model (flash vs pro), and workspace_root (relative path base), but leaves context, provider, output_format, reasoning_effort, max_output_tokens, and task undefined.
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?
States a specific verb and resource ('delegate a bounded task') and scopes it with 'using optional read-only workspace files'. The annotation title confirms it as delegation to an auxiliary LLM. No siblings exist to differentiate from, so it lands at 4 rather than 5.
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 offers model-selection guidance ('Use flash for routine work and pro for difficult analysis'), which is really parameter advice rather than when-to-use guidance. It never states when delegation is appropriate versus doing the work inline, nor any exclusions or prerequisites.
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_taskScored across 1 tool
With only one tool, there is no possibility of misselection or overlapping purpose. The single tool's intent (delegate a bounded task to a model) is unambiguous.
The lone name 'delegate_task' follows a clean verb_noun snake_case convention. There is no opportunity for inconsistency within a single-tool surface.
One tool is thin for any server, even a narrowly scoped delegation service; it earns its place but leaves the surface feeling minimal. A few companion operations (e.g. listing available models or checking delegation status) would round it out.
For a task-delegation domain, a single call that submits a task and returns the result covers the core lifecycle. Minor gaps exist around discovering available models (flash/pro are referenced but not enumerable) and no status/cancel path, though these are workable for a synchronous delegation model.
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
Securely search and manage workspace context files for AI agents and teams.
JSON/YAML, regex, diff, JWT, SQL dialects — the keyless millisecond ops an agent needs mid-task.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.