Delega el trabajo pesado de Claude Code en un modelo que se ejecuta en tu propio hardware.
localagents es un servidor MCP que le da a Claude Code una herramienta run_agent. Cada llamada inicia una sesión headless completa de Claude Code — las mismas herramientas, el mismo CLAUDE.md, el mismo árbol de trabajo — salvo que su tráfico de API va a un servidor llama.cpp o vLLM que tú ejecutas en lugar de a Anthropic. Claude escribe el encargo, el modelo local hace el trabajo, Claude revisa el resultado. Tu presupuesto de tokens de Anthropic se gasta en las partes que lo necesitan.
Un Qwen de 27B en una GPU es perfectamente capaz de «añade una CLI para este módulo y los tests correspondientes»; Opus está mejor empleado en la conversación de diseño que en ver correr pytest. Dos agentes locales en paralelo pueden construir las dos mitades de un paquete contra una interfaz fijada.
Estado: fase inicial. Funciona, lo uso a diario, y la interfaz cambiará. Está dirigido específicamente a llama.cpp y vLLM; Ollama no es un objetivo.
Claude Code (your session)
│ MCP: run_agent(task, model=...)
▼
localagents ── spawns ──▶ headless `claude` (Agent SDK)
│ │ ANTHROPIC_BASE_URL
│ ▼
└──── in-process shim ◀────┘ normalises requests, logs them,
│ translates backend errors
▼
llama-server / vllm (/v1/messages, on your machine or your LAN)Tres cosas hacen que esto sea algo más que una variable de entorno:
Un registro que se sondea en vivo. models.yaml indica dónde están los servidores y ofrece un menú de nombres de modelos. Lo que cada servidor está sirviendo realmente en ese momento, su ventana de contexto real y cuántos slots están ocupados se descubren en cada llamada. Tú levantas y detienes los modelos manualmente — el servidor nunca lanza nada — y cuando Claude necesita un modelo que no está en ejecución, te lo pide por su nombre.
Un shim entre Claude Code y el backend. Claude Code envía cosas que las plantillas de chat locales rechazan, y los servidores locales fallan de maneras que Claude Code no reconoce. El shim corrige ambas direcciones (detalles más abajo) y escribe un requests.jsonl por trabajo para que puedas ver exactamente qué pasó por el cable.
El mismo modelo de aislamiento que los subagentes propios de Claude. Por defecto, un trabajo opera en tu árbol, como hace la herramienta Agent. isolation: worktree le da un worktree de git nuevo en una rama local-agent/<job>, que se conserva solo si cambió algo, con un diffstat en el registro del trabajo para que Claude pueda revisarlo como un diff.
Related MCP server: lmstudio-mcp
Python 3.12+ y uv
Claude Code. El Agent SDK incluye su propio binario claude, así que no hay nada más que instalar.
Un servidor que hable el /v1/messages de Anthropic:
llama.cpp llama-server — arráncalo con --jinja; añade --slots --metrics para obtener ocupación y estadísticas de caché en la salida de la herramienta.
vLLM con --enable-auto-tool-choice --tool-call-parser <parser>.
Un modelo que pueda manejar realmente Claude Code: llamada a herramientas nativa sólida y una ventana de contexto de 128k o más por petición. Qwen3.8-27B funciona bien. Ventanas más pequeñas funcionan pero compactan constantemente; ver Ventanas de contexto.
git clone https://github.com/ccebelenski/localagents.git && cd localagents
uv tool install -e . # `localagents` on PATH; editable, so repo edits apply
cp models.example.yaml models.yaml # edit for your servers (gitignored)
claude mcp add --scope user local -- localagents --config "$PWD/models.yaml"El ámbito de usuario (user scope) significa que todos los proyectos obtienen el servidor local. Este hereda el directorio de trabajo (cwd) de la sesión de Claude Code que lo lanzó, así que run_agent usa por defecto el árbol de ese proyecto. Un proyecto puede tener su propio ./models.yaml para sobrescribir el registro.
Si prefieres limitarlo a un solo proyecto, pon esto en el .mcp.json de ese proyecto:
{"mcpServers": {"local": {"command": "localagents", "args": ["--config", "/path/to/models.yaml"]}}}Reinicia Claude Code (o /mcp → reconnect) después de añadirlo; los servidores MCP se cargan al inicio.
Claude lo usa como cualquier otra herramienta. Pídeselo por su nombre y hará lo correcto:
Usa el agente local para añadir una opción
--jsona la CLI y cúbrela en los tests.
Lo que Claude hace detrás de eso: list_models para ver qué hay disponible, run_agent(task=…) que devuelve un id de trabajo, luego wait_job / job_status / job_log hasta que termina, después lee files_touched (o el diff del worktree) y comprueba el trabajo. Los trabajos que superan el tiempo de espera de 2 minutos de las herramientas de Claude Code pasan a segundo plano y se retoman más tarde; no tienes que hacer nada.
Si no hay nada adecuado en ejecución, se te pedirá que lo levantes:
qwen3.8-27bno se está ejecutando en ningún sitio. Pide al usuario que lo levante. Notas: codificador mediano por defecto en llama.cpp; ejecutar con --reasoning on
Levántalo como lo hagas normalmente, di «ya está», y Claude lo reintentará.
herramienta | qué hace |
| endpoints con estado de salud en vivo, ids servidos, ventana de contexto, ocupación de slots; el pool con |
| iniciar un trabajo: |
| seguir y controlar trabajos |
| qué decirle al usuario para que levante un modelo del pool |
| añadir al pool desde dentro de una sesión (escrito en |
| generación one-shot sin herramientas — resúmenes, borradores, clasificación |
Los registros de los trabajos viven en ~/.local/state/localagents/jobs/<job>/: transcript.txt (lo que el agente dijo e hizo), events.jsonl (cada mensaje del SDK), requests.jsonl (cada petición al backend con tiempos, tamaño y uso), y requests_full.jsonl si activas el volcado de peticiones.
models.yamlParte de models.example.yaml. Se relee en cada llamada, así que los cambios tienen efecto inmediato, y el servidor nunca lo reescribe — register_* escribe en un sidecar models.local.yaml que se fusiona por encima.
endpoints:
llamacpp:
base_url: http://127.0.0.1:8080
backend: llama.cpp
gpu-server:
base_url: http://gpu-server.lan:8000
backend: vllm
host: gpu-server
models:
qwen3.8-27b:
notes: default mid-size coder on llama.cpp; run with --reasoning on
deepseek-v4-flash:
host: gpu-server
notes: vllm needs --enable-auto-tool-choice --tool-call-parser deepseek_v3endpoints son lugares que sirven /v1/messages. Lo que sirven se sondea.
models son solo nombres. Un nombre se compara de forma difusa contra los ids servidos (qwen3.8-27b encuentra unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL), así que una entrada solo necesita notes y quizá un host para transmitir cuando se te pida que lo levantes. served_name (id exacto o glob), endpoint, context (ventana de respaldo) y bring_up (un comando de arranque) existen como sobrescrituras si las quieres. Los comandos de arranque se quedan obsoletos rápidamente; un nombre y una nota suelen envejecer mejor.
defaults cubren el modelo por defecto, permission_mode (acceptEdits), herramientas permitidas y no permitidas (los subagentes no pueden crear subagentes), qué ajustes de Claude cargar, max_turns, timeout_s, y un sufijo de prompt de sistema que le dice al agente que es un delegado y cómo informar.
Tanto llama.cpp como vLLM hablan /v1/messages de forma nativa, así que apuntar ANTHROPIC_BASE_URL a ellos casi funciona. El shim cierra las brechas:
Mensajes de sistema en mitad de la conversación. Claude Code pone entradas role: system dentro de messages — la lista de habilidades, un marcador de presupuesto de tokens, y una más por turno. La plantilla de chat de Qwen lo rechaza: "System message must be at the beginning". El shim pliega cada una dentro del mensaje de usuario adyacente como un bloque de texto <system>…</system>, en su lugar. Elevarlas al campo system de nivel superior en su lugar cambia el inicio del prompt cada turno, lo que invalida el prefijo de la caché KV del servidor y re-evalúa todo el prompt de ~35k tokens cada vez (21–47 s por turno en un 27B). Plegar en su lugar mantiene el prompt de solo añadidura: f_sim_best 0.88–0.99 en el log de llama-server, 2.5–14 s por turno.
Desbordamiento de contexto. Claude Code asume una ventana de 200k para cualquier modelo que no reconoce; con un slot más pequeño se topa con exceed_context_size_error de llama.cpp, que no entiende, y el trabajo muere. Ver la siguiente sección.
Todo lo que hace el shim es un no-op cuando no se necesita, y cada petición se registra con su tiempo, número de mensajes, tamaño en bytes y uso notificado.
Dos capas mantienen una sesión dentro de la ventana real:
La sonda la lee — llama.cpp /props n_ctx (por slot: -c dividido por --parallel cuando la KV unificada está desactivada), vLLM max_model_len — y la sesión recibe CLAUDE_CODE_MAX_CONTEXT_TOKENS. El auto-compactado propio de Claude Code se dispara entonces en el punto correcto. Por debajo de 128k, el presupuesto de salida también se reduce a n_ctx/8, porque el umbral de compactación es window − max_output y de otro modo se quedaría en cero.
Si una petición aún se desborda, el shim reescribe el error del backend en el prompt is too long: N tokens > M maximum de Anthropic, al que Claude Code responde compactando y reintentando.
Con 64k esto funciona pero sufre thrashing: los ~20k de prompt fijo y esquemas de herramientas de Claude Code, más un resumen de compactación de ~7k tokens (~55 s en un 27B) y los archivos que vuelve a adjuntar, rellenan la ventana en pocos turnos y su guardia anti-thrash termina el trabajo. Dale a cada slot 128k o más.
llama.cpp: llama-server -hf <gguf> --jinja -fa on --slots --metrics, más --reasoning on para modelos de razonamiento y --parallel N para trabajos concurrentes. Con /slots activado, list_models muestra {total, busy, free} para que Claude sepa si un segundo agente se ejecutará ahora o hará cola. Con /metrics activado, cada trabajo registra tokens de prompt procesados frente a cacheados, ratio de aciertos de caché, tok/s de prompt y de generación, y aceptación de decodificación especulativa — los contadores son de todo el servidor, así que los trabajos superpuestos comparten el delta.
vLLM: vllm serve <model> --served-model-name <alias> --enable-auto-tool-choice --tool-call-parser <parser>. La ventana de contexto viene de max_model_len en /v1/models; la ocupación (requests_running/waiting, kv_cache_usage) y las estadísticas de caché por trabajo vienen de su /metrics, siempre activo. vLLM notifica el desbordamiento de contexto en el endpoint de Anthropic como HTTP 500 internal_error; el shim también lo traduce. La sesión se inicia con CLAUDE_CODE_ATTRIBUTION_HEADER=0 porque el hash de atribución por petición impide el cacheo de prefijos. Verificado con DeepSeek-V4-Flash: los bloques de razonamiento se reproducen con sus firmas, aciertos de caché de prefijo en cada turno después del primero.
El primer turno de un trabajo cuesta unos 20k tokens de prompt en un slot frío (prompt de sistema más esquemas de herramientas), ~10 s en un 27B. Todo lo demás es un acierto de caché más el delta.
uv sync --dev
uv run pytest -qConsulta CONTRIBUTING.md para la estructura y cómo probar cambios contra un servidor real.
MIT. Consulta LICENSE.
Copyright © 2026 Chris Cebelenski
Cancel a running job (kills the headless Claude session).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait—that cancellation kills the headless session—but does not elaborate on reversibility, side effects on job output, or whether the cancellation is asynchronous. This is partial disclosure but not comprehensive.
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 a single sentence with no unnecessary words. The core action ('Cancel a running job') is front-loaded, and the parenthetical adds essential behavioral detail. It is highly concise and well-structured.
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?
For a simple one-parameter cancellation tool, the description covers the essential action and primary side effect. However, it lacks details about error handling (e.g., what happens if the job is already finished), whether cancellation is synchronous, or any prerequisites. The presence of an output schema reduces the need to describe return values, but overall the description is adequate yet not rich.
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%, so the description must compensate. The only parameter, job_id, is never explained; its meaning is only implied by the tool's purpose. The description does not clarify how to obtain a valid job_id or that it must reference a running job.
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 uses a specific verb ('Cancel') and a clear resource ('a running job'), and adds the clarifying detail that it 'kills the headless Claude session.' This clearly distinguishes it from related tools like job_status, wait_job, and list_jobs without needing to inspect their schemas.
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 states only what the tool does, not when to use it relative to alternatives. It does not mention conditions for use (e.g., only when a job is running) or contrast with siblings like job_status or wait_job. No guidance on when to avoid this tool is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tail of a job's human-readable transcript (assistant text, tool calls, results).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| tail_lines | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose that the tool returns the tail of a transcript and what content categories are included, but it does not describe behavior for missing jobs, incomplete jobs, or error conditions. This is adequate but not rich.
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?
One concise sentence with no filler. 'Tail of a job's human-readable transcript' is front-loaded and the parenthetical content list adds useful scope without bloating the text.
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?
The tool is simple and has an output schema, so return values need not be re-described. However, with no annotations and no parameter-level details, the description leaves some context implicit, such as the unit for tail_lines and whether the tool is safe for active jobs. An agent can still call it, but the context is minimally sufficient.
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%, so the description must compensate, but it does not explicitly explain job_id or tail_lines. The word 'Tail' loosely implies tail_lines controls how much is returned, and job_id is inferable from 'a job's transcript', but the meaning of the default and the line-count semantics are left to the schema titles only.
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 states a specific resource and action: retrieving the tail of a job's human-readable transcript. It also clarifies content type (assistant text, tool calls, results), which distinguishes it from status-oriented siblings like job_status or list_jobs, though it does not name them.
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?
There is no explicit guidance about when to use this tool versus alternatives such as job_status, wait_job, or list_jobs. The phrase 'tail of a job's transcript' weakly implies a read-after-run scenario, but no exclusions or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current status, last activity, files touched, and result (if finished) of a job.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the transparency burden. It does disclose what the tool reports and notes the conditional result field for finished jobs, but it does not explicitly state that the call is non-mutating, non-blocking, or what happens for unknown jobs.
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 compact and efficiently lists the key return categories without filler. Minor structural issue: it is a noun phrase rather than a complete verb-led sentence.
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?
Because an output schema exists, the lack of return-value detail is acceptable, and the essentials for invoking with job_id are present. However, the tool lacks usage context and behavioral caveats, leaving an agent to infer how this relates to wait_job and job_log.
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%, so the description needs to compensate, but it only implies job_id through 'of a job'. It does not explain the expected format, where to find the ID, or any constraints beyond the schema's generic string type.
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 identifies a specific resource (a job) and lists the exact information returned: current status, last activity, files touched, and result when finished. It is clear enough to separate from list_jobs or wait_job, though it lacks an explicit verb like 'Gets' or 'Returns'.
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?
No guidance is given about when to call this instead of siblings such as wait_job or job_log. The 'if finished' caveat is the only hint about polling behavior; there is no explicit context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List jobs from this server session (newest last).
| Name | Required | Description | Default |
|---|---|---|---|
| include_finished | No |
| 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 behavioral burden. It usefully discloses ordering and session scoping, but it does not mention side-effect guarantees, pagination, or how include_finished affects results.
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?
A single concise sentence with no filler. The action is front-loaded, and the scope and ordering details are included efficiently.
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?
For a simple list operation with one self-explanatory optional boolean and an output schema, the description is mostly sufficient. The main gap is the lack of connection to sibling tools and explicit include_finished behavior.
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%, and the description never mentions the include_finished parameter. The parameter name and default value imply its meaning, but the description adds no semantic value for it.
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 states a concrete action and object ('List jobs'), scopes them to 'this server session', and adds ordering ('newest last'). This clearly distinguishes it from siblings like job_status, job_log, and cancel_job.
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 gives no guidance on when to use list_jobs versus job_status, job_log, or wait_job. It implies a session scope but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured endpoints (with live health + what they're serving now) and the model pool.
Pool entries that are currently reachable are marked `available: true` with the endpoint name
and the served id. Unavailable ones are the menu to ask the user for (by name, on `host`).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses live health semantics, the meaning of 'available: true', and how unavailable entries should be treated. Read-only behavior is only implicit via the verb 'List', but that is reasonable for this tool.
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?
Three terse sentences front-load the primary purpose and each subsequent sentence adds useful semantic or behavioral detail. No filler or redundancy.
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?
For a zero-parameter listing tool with an output schema, the description is complete: it explains what is listed, what availability means, and how to interpret unavailable entries. Nothing needed for correct invocation is missing.
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 tool has zero parameters, so there is no parameter documentation burden. The description appropriately focuses on behavior and output meaning instead.
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 ('List') and distinct resources: configured endpoints with live health and the model pool. It also clarifies what availability means, differentiating this from list-style siblings like list_jobs.
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: to inspect live endpoint availability and decide which unavailable models to ask the user about. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot completion on a local model, no tools, no agent loop. Cheap offload for summaries, drafts, classification, translation, boilerplate. Returns the text.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| prompt | Yes | ||
| system | No | ||
| endpoint | No | ||
| max_tokens | No | ||
| temperature | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the core behavior (one-shot, no tools, returns text) and notes it's 'cheap' (low cost), but omits potential failure modes, authorization requirements, or network behavior (despite an endpoint parameter). It adds some value but not full transparency.
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 3 succinct sentences, front-loading the primary action and immediately differentiating from siblings. Every sentence contributes: purpose, use cases, and return value. No filler or redundancy.
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?
For a tool with 6 parameters and sibling tools for registering models/endpoints, the description doesn't mention prerequisites or how to choose a model. It assumes the agent knows it can just pass prompt and rely on defaults, but lacks guidance on when to specify model/endpoint. Given the output schema exists, return format is covered, but operational context is incomplete.
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 parameter description coverage is 0%, and the tool description offers no parameter-specific explanation. It doesn't clarify how 'model', 'endpoint', or 'system' interact, nor does it mention defaults or dependencies. The parameter names are self-explanatory, but the description adds no semantic value beyond the schema.
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 performs one-shot completion on a local model, explicitly contrasting with agent loops and tools. It lists concrete use cases (summaries, drafts, classification, translation) and specifies the output, leaving no ambiguity about what the tool does.
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?
It explicitly identifies when to use it ('cheap offload' for simple tasks) and when not to ('no tools, no agent loop'), implicitly routing to sibling tools like run_agent for agentic needs. While it doesn't name the alternative directly, the exclusion is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update an inference endpoint (persisted to models.yaml) and probe it.
`base_url` is the server root that exposes `/v1/messages`, e.g. `http://127.0.0.1:8080`.
`backend` is one of llama.cpp | vllm | ollama | other (informational).
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | local | |
| name | Yes | ||
| notes | No | ||
| backend | No | other | |
| base_url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool persists to models.yaml and probes the endpoint, which is useful, but it omits critical behavioral details such as whether the operation is idempotent, what happens on probe failure, error handling, or potential side effects like network timeouts. For a tool that mutates state and performs network calls, this is insufficient.
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 brief at two sentences plus a code block, which is concise. However, it lacks a clear structure: the parameter explanations are dropped inline rather than presented as a list, and key scoping info is not front-loaded. It's not bloated, but it could be more organized.
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?
Given the tool has five parameters, no annotations, no output schema (schema is present but no output schema referenced), and 0% schema description coverage, the description is incomplete. It does not explain the return value of probing, error conditions, or how the endpoint is validated. An agent cannot fully predict the tool's behavior from the description alone.
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%, so the description must explain parameters. It explicitly covers base_url (server root exposing /v1/messages) and backend (enum of llama.cpp, vllm, ollama, other), but fails to describe the other three parameters: name, host, and notes. Two of five parameters are explained, leaving the rest undocumented.
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's purpose: 'Add or update an inference endpoint (persisted to models.yaml) and probe it.' The verb 'add or update' combined with the resource 'inference endpoint' is specific, and the persistence detail distinguishes it from related tools like register_model or list_models.
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 provides no explicit guidance on when to use this tool versus alternatives. It mentions the tool registers endpoints but doesn't indicate when to prefer it over other registry-related tools, nor does it list any prerequisites or exclusions. The context about base_url and backend is informative but not usage-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or update a model in the pool (persisted to models.yaml).
Only `name` is required: it is fuzzy-matched against served ids (alphanumerics, case-folded,
substring), so `qwen3.8-27b` finds `unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL`. `host` and `notes`
are what gets relayed when asking the user to bring it up. The rest are overrides:
`served_name` (exact id or glob) when fuzzy matching is ambiguous, `endpoint` to prefer one,
`context` as a fallback window when the backend doesn't report one, `bring_up` a start command
(goes stale quickly; usually leave empty).
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| name | Yes | ||
| tags | No | ||
| notes | No | ||
| context | No | ||
| bring_up | No | ||
| endpoint | No | ||
| served_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses key behaviors: upsert semantics, persistence to a YAML file, the fuzzy-matching algorithm, and the caveat that bring_up goes stale. It clearly indicates mutation and side effects. It omits auth/permission requirements and error scenarios, but the disclosed details are substantial.
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 front-loaded with the core purpose, then breaks down parameters with clear rationale. Each sentence adds value, though it is somewhat long. The structure is logical and efficient, with no wasted words.
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?
Given the tool's complexity (8 params, matching algorithm, overrides) and lack of annotations, the description covers most operational aspects: required field, matching behavior, param purposes, and a caveat. The omission of tags and lack of error/edge-case discussion are gaps, but the output schema presumably covers return values. Overall, it is largely complete for an agent to invoke correctly.
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?
With 0% schema description coverage, the description explains most parameters (name matching, host/notes relay, served_name, endpoint, context, bring_up) with usage context. However, the 'tags' parameter is completely ignored, leaving one of eight parameters undocumented. The detail given for the others is strong and compensates for the schema gap.
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?
Clearly states a specific action ('Add or update a model in the pool') with a concrete resource and persistence detail ('persisted to models.yaml'). The verb+object is unambiguous and distinct from sibling tools like register_endpoint.
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 the tool (to add or update a model) but does not explicitly contrast it with alternatives such as register_endpoint or request_model. No when-not-to-use guidance, prerequisites, or conditions that select this tool over siblings are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What to relay to the user to bring up a model that is not currently running.
Returns the pool entry's `host`/`notes` (and a start command only if one is on file). If the
model is already up, says so instead.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior, and it does so well. It discloses the return payload (host/notes, plus a start command only if one is on file) and the conditional behavior when the model is already up. It implies a read-only, informational operation by saying it relays content to the user, though it does not explicitly state that no start action is triggered.
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 compact: a one-sentence purpose, a one-sentence return summary, and a one-sentence conditional behavior note. Every sentence adds distinct information, and the key purpose is front-loaded. No redundant phrasing or unnecessary detail.
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?
For a simple one-parameter tool, the description is largely complete: it explains what to pass, what to expect in return, and the main conditional case. It does not address what happens if the model is unknown or not registered in the pool, but the presence of an output schema and the clear conditional wording make this a minor gap rather than a blocking one.
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 only a 'model' string parameter and no parameter description, so schema coverage is 0%. The description adds some context by framing 'model' as the identifier of a model that is not currently running, but it does not specify expected values, naming conventions, or where the model identifier comes from. This is partially compensated by the self-explanatory parameter name and the surrounding context.
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's purpose: relay to the user what is needed to bring up a model that is not currently running. It identifies the resource (model) and a specific action (request/relay), and the conditional 'if the model is already up, says so instead' further clarifies scope. It does not explicitly name a sibling tool, but the unique purpose is recognizable.
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 gives a clear usage condition: use this when a model is not currently running and you need instructions to give the user. It also handles the alternative case by noting that if the model is already up, the tool says so. It does not name alternative tools like list_models or register_model, but the intended context is reasonably explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate a task to an agent on a local model. Returns a job id immediately.
The agent is a headless Claude Code session (Read/Edit/Write/Glob/Grep/Bash, project
CLAUDE.md, same working tree) whose API calls go to the local endpoint. Write the task like a
brief for a capable but junior engineer: what to do, where, how to verify, and what to report.
Args:
task: The brief. Be explicit; local models follow less implicit context than Claude.
model: Pool name (see list_models) or a served model id/glob. Default from models.yaml.
endpoint: Force a specific endpoint; with no `model`, uses whatever it is serving.
cwd: Working directory (default: this server's cwd, i.e. the current project).
isolation: "none" (work in cwd, like a normal subagent) or "worktree" (fresh git worktree
on branch local-agent/<job>; kept only if the agent changed something, reported in
job.worktree with a diffstat). Use worktree for risky/large edits you want to review as a diff.
wait_s: If > 0, block up to this many seconds and return the result when done (else job id).
permission_mode: acceptEdits (default) | bypassPermissions | default | plan.
max_turns: Cap on agent turns (default from models.yaml).
allowed_tools: Override auto-approved tools.
system_prompt_append: Extra instructions appended to the Claude Code system prompt.
resume_job: Continue a previous job's session (same model) with `task` as the next message.
timeout_s: Wall-clock cap for the job.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| task | Yes | ||
| model | No | ||
| wait_s | No | ||
| endpoint | No | ||
| isolation | No | none | |
| max_turns | No | ||
| timeout_s | No | ||
| resume_job | No | ||
| allowed_tools | No | ||
| permission_mode | No | ||
| system_prompt_append | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses the agent's toolset (Read/Edit/Write/Glob/Grep/Bash, project CLAUDE.md, same working tree), immediate-return behavior, isolation details including worktree retention and diffstat reporting, permission modes, resume semantics, and blocking behavior via wait_s. This goes well beyond what the name and schema reveal.
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 appropriately sized for a 12-parameter tool. Each sentence earns its place: the opening sentence states purpose and return behavior, the second gives task-writing guidance, and the arg list is dense but scannable. No redundancy.
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?
Given 12 parameters, no annotations, and an output schema to cover return values, the description is complete. It covers all parameters, defaults, the immediate-return/blocking distinction, worktree behavior, permission modes, and resume capability. Nothing an agent needs to invoke this tool correctly is missing.
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%, so the description must fully compensate, and it does. Every one of the 12 parameters gets a meaningful explanation with defaults, allowed values, and behavioral effects (e.g., isolation explains 'none' vs 'worktree', permission_mode lists all options, resume_job explains continued sessions).
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 opens with 'Delegate a task to an agent on a local model,' which is a specific verb and resource, and immediately states the key behavioral distinction: 'Returns a job id immediately.' This clearly differentiates run_agent from the job-management siblings (job_log, cancel_job, job_status, wait_job).
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 gives strong usage context: how to write the task brief, when to use isolation='worktree' ('Use worktree for risky/large edits you want to review as a diff'), when wait_s should be used, and points to a sibling tool via 'Pool name (see list_models)'. It doesn't explicitly name alternatives for follow-up status checks (e.g., job_status/wait_job), but the immediate-return semantics make that implication clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block up to timeout_s seconds for a job to finish; returns its status/result either way.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| timeout_s | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the blocking behavior, the timeout bound, and the fact that it returns a status/result even when the job has not finished. This is meaningful transparency, though it does not mention error cases like invalid job_id.
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 entire description is one sentence with no filler. It front-loads the blocking behavior, states the timeout parameter, and conveys the return guarantee efficiently.
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?
For a simple two-parameter wait tool, the description covers the core behavior and return guarantee, and an output schema exists to document the result shape. It could add a note about already-finished jobs or invalid IDs, but nothing essential is missing for correct usage.
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%, so the description needed to compensate. It clarifies that timeout_s is measured in seconds and controls the blocking duration, but it does not explain job_id beyond the implicit 'a job'. The parameter names are largely self-explanatory, so this is adequate but not exceptional.
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 ('Block'), the resource ('a job'), and the outcome ('returns its status/result either way'). This clearly distinguishes wait_job from siblings like job_status or list_jobs, which check or list rather than block.
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 conveys a clear usage context: call this when you are willing to block up to a timeout for a job to finish, and you will get the result whether or not it completed. It does not explicitly name alternatives or state when not to use it, such as 'use job_status for non-blocking checks', so it stops short of a 5.
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.0cancel_jobjob_logjob_statuslist_jobslist_modelslocal_completeregister_endpointregister_modelrequest_modelrun_agentwait_jobScored across 11 tools
Most tools target distinct resources and actions: job lifecycle (run_agent, job_status, job_log, wait_job, cancel_job, list_jobs) and model/endpoint management (list_models, request_model, register_model, register_endpoint) are clearly separated. The main overlap risk is between wait_job and job_status, both returning status/result, but blocking vs non-blocking behavior distinguishes them.
The naming mostly follows a clear verb_noun pattern (cancel_job, list_models, register_model, run_agent, wait_job, list_jobs). Minor deviations exist with job_log, job_status, and local_complete, which use noun-first or adjective-verb constructions but are still readable and predictable.
11 tools is well-scoped for a local agent orchestration server. Each tool covers a distinct operational concern, and none feel redundant or superfluous.
The core domain is well covered: job creation, waiting, status, logs, cancellation, listing, plus model pool and endpoint registration and a one-shot completion fallback. Minor gaps include no explicit unregister/delete tool for models or endpoints, but these are not major blockers for typical workflows.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Connect ChatGPT, Claude, Cursor or VS Code to your Windows PC: files, terminal, browser, apps.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Agent personas for Claude. 16 tools, 13 personas, 3 workflows. Zero extra API cost. Free.
