What can you do with this server?

The claude-code-delegate-local MCP server lets you route Claude Code subagents to alternative AI backends (local models, cloud APIs, or any OpenAI/Anthropic-compatible endpoint) while keeping your main Claude Code orchestrator session intact. * delegate_to_local_agent: Run a named agent (defined in a .md file with frontmatter) on your configured backend (e.g., LM Studio, Ollama, vLLM, LiteLLM, DeepSeek, AWS Bedrock) with full tool calling support (read_file, write_file, run_bash). * delegate_batch: Dispatch up to 4 independent agent tasks in parallel via asyncio.gather. Reusing the same agent_name across tasks benefits from KV-cache prefix reuse (~30–50% prompt savings). * delegate_to_provider: Send an agent task to any OpenAI/Anthropic-compatible endpoint by specifying the URL, API key, and model — useful for OpenRouter, MiniMax, Alibaba, etc. * delegate_to_codex: Delegate tasks to the OpenAI Codex CLI as an autonomous agent using a ChatGPT subscription (no API key required). * list_local_agents: Discover all agent definitions available in the configured agents directories, showing names, descriptions, and declared models. * local_backend_status: Verify backend reachability, check latency, and list currently served models. Additional highlights: * 3-tier agent lookup: Searches project-level agents, project skills, then global agents. * Dual-format routing: Automatically routes to /v1/chat/completions (OpenAI) or /v1/messages (Anthropic) based on model prefix. * Thinking-mode support: Preserves reasoning_content (e.g., DeepSeek) as thinking blocks across multi-turn conversations.

Which integrations are available for this server?

Enables running Claude Code subagents on local models via Ollama backend. Allows routing Claude Code subagents to OpenAI-compatible endpoints, providing an alternative backend.

How do I use claude-code-delegate-local?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-code-delegate-local run the security-engineer agent on local model to review the project" 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.

claude-code-delegate-local

by fegone

Overview Schema Related Servers Score Discussions

Python

Local

claude-code-delegate-local

🇬🇧 English · 🇪🇸 Español

License: MIT Python 3.11+ MCP

MCP server that delegates Claude Code subagents to alternative backends — local models (LM Studio, llama.cpp, Ollama, vLLM, LiteLLM), DeepSeek, MiniMax M3, GLM Coding Plan (Z.ai), AWS Bedrock, or any OpenAI/Anthropic-compatible endpoint — without losing your Claude Code orchestrator session.

Built for users who want to keep their main Claude Code session on Anthropic (Max plan or API) for orchestration, while offloading specific subagents to cheaper, faster, or HIPAA-safe local backends.

Related MCP server: openai-agents-mcp

What it solves

You're working with Claude Code on a project and you want to:

Send a specific subagent (e.g., security-engineer) to a local model to save tokens from your Max plan, or because you're handling sensitive data that can't leave your machine.
Route another subagent to DeepSeek because it's 10× cheaper and faster for large tasks.
Keep your main Claude Code session exactly as it is — no swapping commands, no separate CLI, no losing the Max plan.

That's what delegate-local does. It's an MCP server you install once that exposes tools the orchestrator can invoke to route specific subagents to whatever backend you've configured.

Features

✅ Your Anthropic Max plan stays intact. No need to launch a separate CLI like ccr code or swap commands.
✅ 3-tier agent lookup. Same command works in any project — finds .claude/agents/<name>.md in the project first, then .claude/skills/<name>/SKILL.md, then global ~/.claude/agents/<name>.md.
✅ Dual-format backend. Auto-routes to /v1/messages (Anthropic format) or /v1/chat/completions (OpenAI format) based on model prefix. Works with DeepSeek's reasoning_content thinking mode out of the box.
✅ Full tool calling. Delegated agents get read_file, write_file, and run_bash with the same loop semantics as Claude Code's native subagents.

Quick install

Requires uv and Claude Code.

git clone https://github.com/fegone/claude-code-delegate-local.git
cd claude-code-delegate-local
uv sync

# Register as Claude Code MCP (user scope = global across projects)
claude mcp add delegate-local \
  --scope user \
  --env DELEGATE_LOCAL_URL=http://localhost:4000/v1/messages \
  --env DELEGATE_LOCAL_KEY=your-backend-api-key \
  --env DELEGATE_LOCAL_MODEL=local-qwen-3-6-35b \
  -- uv run --directory $(pwd) python server.py

Restart Claude Code. The MCP exposes 4 tools (see below).

Configuration

All env vars are optional; defaults assume a LiteLLM proxy on localhost:4000.

Env var	Default	Description
`DELEGATE_LOCAL_URL`	`http://localhost:4000/v1/messages`	Anthropic-format endpoint. For OpenAI-format models, the server auto-converts the URL to `/v1/chat/completions`.
`DELEGATE_LOCAL_KEY`	`""`	Bearer token / API key. Sent as both `x-api-key` and `Authorization: Bearer`.
`DELEGATE_LOCAL_MODEL`	`local-qwen-3-6-35b`	Default model alias if the caller doesn't specify one.
`DELEGATE_LOCAL_CODING_MODEL`	(= `DELEGATE_LOCAL_MODEL`)	Opt-in: coding agents (`coder`, `webdev`, `backend`, `devops`, `frontend`, `fullstack`, `security`) auto-route to this alias when the caller doesn't pass a model. Defaults to `DELEGATE_LOCAL_MODEL` (no rewrite). Set it to a coder-tuned alias to split coding onto a different model. Must be an alias your backend actually serves — otherwise coding agents fail with "model not found".
`DELEGATE_LOCAL_AGENTS_DIR`	`~/.claude/agents`	Where to look for global agent definitions.

See docs/CONFIGURATION.md for full details and example setups with LiteLLM, llama.cpp, Ollama, DeepSeek direct, and AWS Bedrock.

Concurrency pools and failover

Each model gets a pool of six concurrent dispatches, shared across every open Claude Code session — not per session, and not per provider. The pools are real files under ~/.cache/claude-delegate-local/slots/<bucket>/, each requiring an exclusive flock; the kernel releases the lock if a process dies, so a crashed session leaves no phantom slots.

The bucket is chosen by longest matching prefix, so specific entries win over family ones:

Bucket	Slots	Covers
`deepseek-v4-flash`	6	`-flash`, `-flash-max`
`deepseek-v4-pro`	6	`-pro`, `-pro-max`
`qwen-3-8-max`	6	`-max`, `-max-think`
`glm-coding-plan`	6	plain, `-think`, `-max`
`ornith`	6	`ornith*`
`local-`	2	everything else local

Variants of one model share a pool on purpose: they sit behind the same flat plan.

Override any of them with DELEGATE_CONCURRENCY_<BUCKET> (e.g. DELEGATE_CONCURRENCY_GLM_CODING_PLAN=4).

Failover

When a pool is full, the dispatch walks a chain of equivalent models rather than failing:

glm-coding-plan-think → qwen-3-8-max → deepseek-v4-flash → deepseek-v4-pro
deepseek-v4-flash     → deepseek-v4-pro → glm-coding-plan-think → qwen-3-8-max

Flash goes straight to Pro because Flash already bills per token — hopping to Pro does not turn a flat plan into an invoice. For the same reason DeepSeek sits last in the other chains: GLM and Qwen bill $0 against their plans, so a busy afternoon should not quietly become a bill.

Fallbacks wait only DELEGATE_FAILOVER_GRACE (default 10s) for their own slot — the point is to find room now, not to queue four times over. A result that failed over carries failed_over_from and model_used.

⚠️ The chain preserves the NAME of a thinking tier, not measured equivalence. GLM's -max does not reason more than -think; Qwen 3.8's reasoning_effort does not scale; DeepSeek's medium/high/max are indistinguishable. The mapping is the best available, not a claim that the models reason alike.

Local models and Codex never fail over

local-, ornith, codex and gpt- are pinned to themselves, in both directions.

Local models run on hardware that may see regulated data; a silent hop to a cloud provider would move that data off-premise and nobody would notice, because the failure mode of an automatic fallback is that it does not announce itself. Codex bills against a ChatGPT subscription, where failing over means nothing and failing over to it burns plan quota.

The guard filters the chain itself, not just the origin, so editing FAILOVER_CHAINS later cannot route a local model outward.

Tools exposed

Tool	Purpose
`delegate_to_local_agent(agent_name, task, workdir, max_turns, model)`	Run a `.md`-defined agent on the default backend with full tool calling. `max_turns` defaults to auto (v0.6.0): 15 for local backends (`local-*`, MoE-A3B), 25 for cloud (MiniMax M3, DeepSeek, Sonnet/Opus). Pass an explicit value to override. Hard cap 40.
`delegate_batch(tasks)`	NEW v0.5.0 — Dispatch up to 4 agent tasks in parallel via `asyncio.gather`. Each task is a dict `{agent_name, task, workdir?, max_turns?, model?, max_tokens?}`. Returns per-task results in input order. Reuses same agent_name across tasks for KV-cache prefix benefit (~30-50% prompt savings on local llama.cpp).
`delegate_to_provider(provider_url, api_key, model, agent_name, task, ...)`	Run an agent on any arbitrary endpoint (DeepSeek, OpenRouter, etc.)
`delegate_to_codex(task, workdir, model, sandbox, timeout_s)`	NEW — Delegate to the OpenAI Codex CLI as an autonomous agent, authenticated by the user's ChatGPT subscription (Plus/Pro) — OpenAI's official path, no API key, no proxy. Codex does its own file edits + shell in its sandbox; the tool shells out to `codex exec` and returns the final message. Default model `gpt-5.6-sol`. Plan-allowed: the three GPT-5.6 flavors `gpt-5.6-sol`/`terra`/`luna` (default sol) + `gpt-5.5`/`5.4`/`5.4-mini`. Short aliases work: `sol`, `terra`, `luna`. (`gpt-5.6`/`-codex` 400 on a subscription.) ⚠️ Cloud model — never for PHI. ⚠️ Plus plan = ~15-80 msgs / 5h window. Env: `DELEGATE_CODEX_BIN`, `DELEGATE_CODEX_MODEL`.
`list_local_agents()`	List agents found in `DELEGATE_LOCAL_AGENTS_DIR` with their frontmatter metadata
`local_backend_status()`	Health check + list of models available on the configured backend

Note on `delegate_batch` and sub-agents

Claude Code sub-agents launched via the native Agent/Task tool do not inherit the parent session's MCP servers. This means delegate_batch (and any other MCP tool) is only callable from the main orchestrator session. Sub-agents that need parallel local-backend dispatch should use httpx.AsyncClient + asyncio.gather directly against the LiteLLM endpoint instead. This is a Claude Code architecture constraint, not a delegate-local limitation.

3-tier agent lookup

When you call delegate_to_local_agent("webdev", ...) with a workdir, the server looks for the agent definition in this order:

<workdir>/.claude/agents/webdev.md — project agent (highest priority)
<workdir>/.claude/skills/webdev/SKILL.md — project skill (alternative location)
~/.claude/agents/webdev.md — global agent (fallback)

This means the same delegate call works in any project, using whichever scope owns the agent. The response includes agent_source so the orchestrator knows which one was loaded.

Dual-format backend routing

Models with these prefixes are routed to OpenAI-format /v1/chat/completions:

deepseek-*
openai-*
gpt-*
qwen-* (external Qwen APIs — note that local-qwen-* aliases route via Anthropic /v1/messages)

All other models go to Anthropic-format /v1/messages. Inside the server everything is normalized to Anthropic-style content blocks (text / tool_use / thinking) so the agent loop stays uniform.

GLM Coding Plan (Z.ai): the glm-coding-plan alias has no openai/gpt/deepseek/qwen prefix, so it routes via Anthropic /v1/messages — which is what Z.ai's Anthropic-compatible endpoint (https://api.z.ai/api/anthropic) expects. Flat-rate subscription with automatic server-side prompt caching. In LiteLLM use the plain model code anthropic/glm-5.2 — the [1m] (1M-context) suffix errors against this endpoint there; it only works when Claude Code points directly at Z.ai (see examples/claude-glm.sh). Setup: docs/CONFIGURATION.md.

Thinking-mode support

For models that emit reasoning_content (DeepSeek V4, OpenAI o1-style), the server preserves it as a {"type": "thinking", "thinking": "..."} content block between turns. This is required by LiteLLM and most providers — if you drop reasoning_content from the assistant message in multi-turn, the next request fails with 400 Bad Request.

max_tokens defaults to 65536 (parameter of the tool — caller can override). High default is intentional so thinking-mode models have budget for both reasoning and content output, and so large monolithic outputs (e.g., complete HTML files with embedded JS) don't get truncated. Lower it explicitly only if your backend has a stricter cap.

Example: LiteLLM proxy

A minimal litellm/config.yaml to use with this MCP:

model_list:
  - model_name: local-qwen-3-6-35b
    litellm_params:
      model: openai/Qwen3-6-35B
      api_base: http://localhost:8000/v1   # your llama.cpp / vLLM server
      api_key: sk-no-key-required

  - model_name: deepseek-v4-flash
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

  - model_name: bedrock-sonnet-4-6
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6-20260101-v1:0
      aws_region_name: us-east-1

Then run litellm --config config.yaml --port 4000 and point this MCP at it.

Tested with

Backend	Model	Single-turn	Multi-turn
LiteLLM + llama.cpp	`local-qwen-3-6-35b` (Qwen3.6 35B-A3B)	✅	✅
LiteLLM + DeepSeek API	`deepseek-v4-flash`	✅	✅
LiteLLM + DeepSeek API	`deepseek-v4-pro`	✅	✅
LiteLLM + Z.ai	`glm-coding-plan`	✅	✅
LiteLLM + AWS Bedrock	`bedrock-sonnet-4-6`, `bedrock-llama4-*`	✅	✅

Picking a DeepSeek tier: deepseek-v4-flash is the better default for coding and agentic work — the 2026-07-31 rebuild beats deepseek-v4-pro across DeepSeek's published benchmarks at roughly a third of the output cost, and it already reasons at high effort by default (which is why it has no -think variant). Reserve deepseek-v4-pro for very long reasoning chains. Note these are the vendor's own self-reported numbers on their own harness — good enough to pick a default, worth validating on your own task before you move serious work.
⚠️ Both tiers can spend their whole token budget reasoning and return nothing. The server auto-raises the default budget for them; see max_tokens troubleshooting.

Validation tasks: SQL injection review (security-engineer agent), HTML calculator (creative agent, 500-800 LOC monolithic), Pac-Man game (884 LOC monolithic single-shot).

Best practices

⚠️ If you dispatch multi-file sprints to local backends, read this first. Naive single-dispatch of 6+ files at once causes ReadTimeout at high turn counts as context saturates the slot. Splitting the work and reusing the same agent name across parallel workers can cut wall-clock time by ~60% and tokens by ~78%.

🎯 docs/BEST-PRACTICES.md — empirical thresholds for when to split work, KV-cache prefix reuse for parallel dispatches, scope-bounded prompts, estimated savings table

Caveats

run_bash runs shell commands inside workdir without sandboxing. Trust the agents you delegate. If you delegate to an unvetted public agent, the tool can read/write anywhere the calling user has access. There is no Docker isolation by default.
Caps (v0.6.0): read_file supports offset/limit (line ranges) and returns up to ~50KB per call with line numbers and a [lines N-M of TOTAL] header — paginate large files instead of re-reading. run_bash truncates stdout to 12KB and stderr to 4KB, timeout 120s.
max_turns hard cap is 40. Long-running orchestrations should be designed as multiple delegate calls rather than one huge loop.

License

MIT. See LICENSE.

Available Tools

5 tools

delegate_batchA

Despacha hasta N agentes EN PARALELO en una sola llamada, usando asyncio.gather. Útil cuando el orquestador quiere ejecutar N sub-tareas independientes simultáneamente en backends que soportan paralelismo nativo (e.g., llama.cpp con --parallel 4).

USE WHEN you have multiple independent sub-tasks and your backend has parallel slots available (delegate cap = 4 = heavy-coding throughput sweet-spot; oMLX allows 8). With same agent_name reused across tasks, you also benefit from KV cache prefix reuse on the shared system prompt (~30-50% prompt-processing savings).

LIMITATION: Sub-agents launched via Claude Code's Agent/Task tool do NOT inherit parent's MCP servers, so this tool cannot be called from within a sub-agent. It only works from the main orchestrator session. Sub-agents that need parallelism should use httpx.AsyncClient + asyncio.gather directly against your LiteLLM endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`tasks`	Yes	List of task dicts. Each dict has the same keys as delegate_to_local_agent's parameters: {agent_name, task, workdir?, max_turns?, model?, max_tokens?}. agent_name and task are required; rest use defaults. Hard cap MAX_BATCH_SIZE (4) tasks per call. For more, split into multiple calls or use sequential delegate_to_local_agent calls.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses parallelism, batch size cap, KV cache benefits, and the sub-agent limitation. However, lacks details on error handling or behavior on partial failures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded main purpose, but some sections (limitation, alternatives) are lengthy. Still efficient overall.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, usage, parameters, and limitations well. With output schema present, return format is not needed. Minor gaps like error behavior do not detract significantly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only parameter 'tasks' is described beyond schema: explains it is a list of dicts with keys matching delegate_to_local_agent and a hard cap, adding value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it dispatches up to N agents in parallel using asyncio.gather, contrasting with the sibling delegate_to_local_agent which handles single agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (multiple independent sub-tasks with parallel slots) and when not to use (cannot be called from sub-agent), with clear alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delegate_to_local_agentA

Despacha un agente (cargado desde un .md con frontmatter) a un backend OpenAI/Anthropic- compatible con tool calling completo (read_file / write_file / run_bash). Devuelve resultado consolidado.

USAR cuando el usuario quiera ejecutar un agente específico en un backend alternativo (local, cloud, etc.) en vez del default del orquestador. El orquestador sigue intacto.

Para despachar VARIOS agentes en paralelo en una sola llamada, ver delegate_batch.

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	Tarea concreta para el agente. Sé específico, el agente leerá ese prompt.
`model`	No	Model alias as configured in your LiteLLM proxy (or direct provider). Default 'local-qwen-3-6-35b'. Override via DELEGATE_LOCAL_MODEL env var.	local-qwen-3-6-35b
`workdir`	No	Directorio de trabajo del agente (default: '.' del MCP). Recomendado pasar ruta absoluta al proyecto donde trabajará.	.
`max_turns`	No	Tope de iteraciones de tool-calling (hard cap 40). Default 0 = AUTO: 15 para backends locales (local-*, MoE-A3B con techo de ctx ~262K), 25 para backends cloud (MiniMax M3 512K, DeepSeek API, Sonnet/Opus). Pasar un valor explícito lo fuerza. Para tareas cortas conocidas: 5-10. Para review/análisis multi-archivo pesado en cloud: 25-30.
`agent_name`	Yes	Nombre del agente sin .md. Ej: 'seo-content', 'security-engineer', 'database-optimizer'. Debe existir en ~/.claude/agents/
`max_tokens`	No	Tope de tokens por turno del modelo. Default = 65536, EXCEPTO si `model` termina en "-max" (p.ej. glm-coding-plan-max, deepseek-v4-pro-max) -> default sube a 150000 automático. Motivo: en deep-reasoning tiers el modelo puede gastar TODO el budget pensando y no dejar nada para la respuesta (verificado: deepseek-v4-pro-max con 32K devolvió 0 tool_calls, respuesta vacía). Pasar un valor explícito siempre gana sobre el auto-bump.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries full burden. It discloses that the agent is loaded from a .md file with frontmatter, that tool calling includes read_file/write_file/run_bash, that the backend must be OpenAI/Anthropic-compatible, and that the orchestrator remains intact. This sufficiently informs the agent of behavioral traits.

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 concise and front-loaded with the core action. Each sentence serves a purpose: stating the action, clarifying when to use, and pointing to an alternative. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, output schema exists), the description covers the agent source, backend compatibility, alternative tool, and basic behavior. The presence of an output schema means return values do not need explanation. The description is complete for the agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The main description does not add additional meaning beyond what is already in the input schema parameter descriptions, which are already detailed. Therefore, no extra value is provided by the description for parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Despacha un agente (cargado desde un .md con frontmatter) a un backend OpenAI/Anthropic-compatible con tool calling completo (read_file / write_file / run_bash).' It distinguishes from the sibling tool delegate_batch by specifying 'Para despachar VARIOS agentes en paralelo en una sola llamada, ver delegate_batch.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'USAR cuando el usuario quiera ejecutar un agente específico en un backend alternativo (local, cloud, etc.) en vez del default del orquestador.' It also provides an exclusion by pointing to delegate_batch for multiple agents in parallel.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delegate_to_providerB

Versión genérica: despacha un agente a CUALQUIER endpoint OpenAI/Anthropic-compatible. Usar para rutear explícitamente a providers no configurados como default (DeepSeek, MiniMax, Alibaba, OpenRouter, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes
`model`	Yes	Identificador del modelo (depende del provider)
`api_key`	Yes	API key del provider
`workdir`	No		.
`mode_tag`	No	Tag a prepender en system prompt (default MODE:LOCAL — puede ser MODE:DEEPSEEK etc.)	MODE:LOCAL
`max_turns`	No
`agent_name`	Yes
`max_tokens`	No
`provider_url`	Yes	URL completa al endpoint /v1/messages (o equivalente)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavioral traits. It only states 'generic version' and the act of dispatching, but does not explain error handling, authentication requirements (beyond api_key), response format, or whether the call is synchronous/streaming.

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 very short and front-loaded: one sentence defining function, one for usage. No fluff or repetition. Every sentence earns its place.

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?

Given the tool's complexity (9 parameters, 5 required) and generic nature, the description is too sparse. It lacks details on constructing provider_url, task format, and what the output schema contains aside from its mere existence. An agent would struggle to invoke correctly without additional manual or external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (44%), and the description adds no parameter-level information. It does not explain the format of provider_url, task, agent_name, or other critical fields beyond what the schema already provides, failing to compensate for gaps.

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 that the tool dispatches an agent to any OpenAI/Anthropic-compatible endpoint, and contrasts with default providers by naming alternatives (DeepSeek, MiniMax, etc.). It is specific and hints at differentiation from siblings like delegate_to_local_agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to use this for non-default providers, providing concrete examples. It gives clear usage context but does not explain when not to use (e.g., when default provider is sufficient) or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_local_agentsA

Lista los agentes disponibles en ~/.claude/agents/ que pueden delegarse con delegate_to_local_agent(). Devuelve nombre, descripción (del frontmatter) y modelo declarado de cada uno.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It clearly states it is a listing operation with no side effects, and specifies return values. Sufficiently transparent.

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?

Single sentence conveying all necessary information without redundancy. Highly concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and a clear output schema (described), the description fully covers what the tool does and returns. Complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so the description adds no value beyond schema. Baseline score of 4 is appropriate as schema coverage is 100% and no extra parameter info is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available agents from a specific directory, mentions the sibling function for delegation, and specifies the returned fields (name, description, model). It is specific and distinguishes from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when needing to know available local agents for delegation, but does not explicitly state when not to use or compare to alternatives. Sibling context helps, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

local_backend_statusA

Health check del backend configurado (LiteLLM proxy por default). Devuelve estado, modelos disponibles y latencia básica. Útil antes de delegar para validar que el backend está alcanzable.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that the tool is a read-only health check returning status, models, and latency, which is sufficient behavioral context.

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?

Two sentences, front-loaded with purpose and specific outputs. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and a clear output schema, the description adequately covers the tool's purpose and return values. Completes the context for its role as a pre-delegation check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so no additional info needed. Schema coverage is 100% vacuously. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs a health check on the backend, returning status, models, and latency. It distinguishes from sibling tools like delegation and listing agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions it is useful before delegating to validate backend reachability. No explicit when-not-to or alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation4/5

Tools have distinct purposes, but delegate_to_local_agent and delegate_to_provider are both delegation variants that could be confused; descriptions clarify the difference but conceptual overlap remains.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structure (delegate_batch, delegate_to_local_agent, list_local_agents, local_backend_status).

Tool Count4/5

5 tools is a reasonable number for a focused delegation server, though it covers the core workflows without feeling overly slim.

Completeness3/5

Covers delegation, listing, and health check, but misses obvious lifecycle operations like adding/removing agents or providers, and lacks a way to stop or monitor ongoing delegations.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Quallaa
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
toolweave
io.github.andreysparish
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
App Automation AI & Machine Learning Agent Orchestration
2

Related MCP Servers

mcp-local-llm
AI & Machine Learning Text Summarization
aplaceforallmystuff
A
license
Not graded
quality
C
maintenance
MCP server that lets Claude Code delegate mechanical tasks to a local LLM for summarization, classification, extraction, and drafting.
Updated 24 days ago (2026-08-12 18:56 UTC)
12
10
MIT
openai-agents-mcp
AI & Machine Learning Agent Orchestration
merlinrabens
A
license
A
quality
D
maintenance
MCP server that bridges OpenAI's Agents SDK with Claude Code, enabling web search, file search, and computer use capabilities directly in your development environment.
Updated a year ago (2025-08-22 11:32 UTC)
2
9
1
MIT
agent-network
Agent Orchestration Communication Coding Agents
sharifli4
A
license
Not graded
quality
D
maintenance
MCP server that enables Claude Code to communicate with other Claude Code agents over HTTP, allowing users to ask questions about remote codebases or delegate coding tasks.
Updated 6 months ago (2026-03-13 07:21 UTC)
MIT
Clanker
Coding Agents Code Execution Autonomous Agents
kckylechen1
A
license
A
quality
F
maintenance
MCP server for running external coding agents as background tasks inside Claude Code. Supports multiple backends including Codex, Grok, GLM, DeepSeek, and more.
Updated 2 months ago (2026-07-09 13:59 UTC)
7
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/fegone/claude-code-delegate-local'

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

claude-code-delegate-local

Table of contents

What it solves

Features

Quick install

Configuration

Concurrency pools and failover

Failover

Local models and Codex never fail over

Tools exposed

Note on delegate_batch and sub-agents

3-tier agent lookup

Dual-format backend routing

Thinking-mode support

Example: LiteLLM proxy

Tested with

Best practices

Further reading

Caveats

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Note on `delegate_batch` and sub-agents