It is an MCP server that delegates mechanical text→text (and image→text) tasks to a local LLM through any OpenAI-compatible endpoint, saving Claude's context/subscription quota by reading large files server-side.
Summarize large files, text, or lint/test/CI logs (local_summarize, local_lint_summary) with optional focus and map-reduce for huge inputs.
Classify text into one label from a given list (local_classify).
Extract structured fields as validated JSON from text or files (local_extract).
Generate boilerplate code from a spec and write it directly to a target path (local_boilerplate).
Delegate generic text→text tasks with configurable chunking for long inputs (local_delegate).
Write commit messages from a diff (local_commit_msg).
Translate text or files while preserving format, with automatic chunking of long documents (local_translate).
Explain code in prose, optionally focused by a question (local_explain_code).
Describe images or answer questions about them using a local vision model (local_describe_image).
Check backend status and available models read-only before delegating (local_status).
Allows delegating text-to-text tasks to Ollama's local LLMs via an OpenAI-compatible endpoint for summarization, classification, extraction, boilerplate generation, and more.
Allows delegating text-to-text tasks to any OpenAI-compatible endpoint, including OpenAI's API, enabling the use of local or remote LLMs for mechanical tasks.
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., "@local-delegate summarize the file /var/log/syslog"
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.
Delega tareas mecánicas texto→texto a un LLM local para conservar la cuota de tu suscripción de Claude.
Un servidor MCP (stdio o daemon HTTP compartido) que es cliente genérico de cualquier
endpoint OpenAI-compatible — llama-swap, Ollama, LM Studio, vLLM.
zahirinatzuke.github.io/local-delegate — qué
hace y por qué, en una página (es/en). Su fuente está en site/.
Dashboard embebido (datos de ejemplo): estado del backend local (modelos montados, delegación en curso con su progreso por trozos, tools MCP), RAM/VRAM del sistema con consumo por proceso, tokens de contexto conservados, ahorro por herramienta y modelo, dónde corrió el cómputo —esta máquina o un backend remoto— y actividad reciente paginada en tu hora local. Se sirve en http://127.0.0.1:9393.
Related MCP server: lmstudio-mcp
Cuando Claude tiene que resumir un log enorme, clasificar, extraer campos o generar boilerplate,
gasta cuota de tu suscripción en trabajo mecánico. local-delegate expone esas tareas como
tools MCP que corren en un LLM local: pasas path en vez de text y el archivo se lee
del lado del servidor, así el contenido grande nunca entra al contexto de Claude. Solo
vuelve el resultado corto — cuota que no gastaste.
Con uv no hay nada que instalar: uvx baja y ejecuta el paquete aislado.
Añádelo a tu config de MCP (Claude Desktop / Claude Code) en modo compatible stdio:
{
"mcpServers": {
"local-delegate": {
"command": "uvx",
"args": ["local-delegate-mcp"]
}
}
}Ver plantillas completas en examples/.
O deja que el paquete lo configure todo por ti —entrada MCP, hooks, skill y la regla de
delegación en tu CLAUDE.md/AGENTS.md global— con un solo comando:
uv tool install local-delegate-mcp # deja `local-delegate` en el PATH
local-delegate install --dry-run # muestra exactamente qué tocaría
local-delegate install # aplicaTambién sirve uvx local-delegate-mcp install para probarlo sin instalar nada, pero ten en cuenta
que uvx no deja el comando disponible: monta un entorno efímero y lo borra al terminar, así
que después local-delegate doctor responderá «command not found». El propio install te lo avisa
si detecta ese caso.
Es idempotente, deja .bak de lo que edita, no toca configuración ajena y se revierte con
local-delegate uninstall. Detalle y opciones en Instalación de la integración.
Si usas varias sesiones o varios clientes en la misma máquina, se recomienda un solo daemon:
uvx local-delegate-mcp serveEl daemon sirve MCP en http://127.0.0.1:9393/mcp y el dashboard en
http://127.0.0.1:9393/. Codex, Claude Code, opencode y cualquier cliente compatible con Streamable HTTP
pueden compartir esa URL sin levantar procesos MCP duplicados. Guía completa:
Daemon compartido.
Para usar la GPU de otra máquina manteniendo los paths locales del cliente, usa un MCP local que apunte al backend remoto: guía Mac → PC y recipe técnica completa.
No fijes una versión vieja «por estabilidad». Un pin (
==X.Y.Z) congela también los rangos de dependencias que declaraba aquel wheel, y eso envejece mal: las versiones anteriores a la 0.12.2 pedíanmcpsin techo, así que hoy resuelven al SDK 2.x y mueren en el import. Si necesitas fijar, fija la actual, y súbela cuando salga una nueva.
En Windows, si lo registras como tarea al iniciar sesión, ejecuta el pythonw.exe del entorno
donde instalaste el paquete con -m local_delegate serve --log-level warning. pythonw no crea
consola ni botón en la barra de tareas. La tarea pertenece al usuario de Windows, no a Codex
ni a Claude: cualquier cliente local comparte el mismo daemon. El dashboard identifica ese único
proceso con la insignia DAEMON MCP; las sesiones conectadas son clientes HTTP, no procesos MCP
adicionales.
Python 3.11+ — con uvx no tienes que instalarlo tú, lo resuelve él; solo importa si instalas
con pip en un entorno propio.
Y un endpoint OpenAI-compatible ya corriendo, accesible en LOCAL_DELEGATE_BASE_URL
(default http://127.0.0.1:9292/v1). Cualquiera sirve:
llama-swap — ver recipe con GPU Blackwell.
Ollama — http://127.0.0.1:11434/v1.
LM Studio, vLLM, o cualquier servidor que hable la API de OpenAI.
El paquete no arranca ningún backend por defecto (LOCAL_DELEGATE_AUTOSTART=0). El
auto-arranque de llama-swap es opt-in (ver tabla de configuración).
¿Qué versiones de llama-server/llama-swap usar y cómo disponer el workspace? Ver
Versiones del backend y workspace de referencia (sugerencia
probada, no requisito). local-delegate doctor compara tu instalación contra esas versiones y, de
paso, comprueba el resto del andamiaje —hooks, skill, memoria, entradas MCP y el daemon— sin
escribir nada (qué mira cada check).
Pasar path (en vez de text) hace que el MCP lea el archivo server-side → ahorro real de cuota.
Tool | Qué hace | Rol de modelo (default) |
| Resume texto o archivo; | mecánico / largo (auto) |
| Devuelve UNA etiqueta de una lista | mecánico |
| Extrae campos → objeto validado, no una cadena que haya que parsear | mecánico / largo (auto) |
| Genera código desde una spec y lo escribe en | código |
| Escape genérico texto→texto | mecánico (o el que pases) |
| Resume logs de lint/tests/CI | mecánico / largo (auto) |
| Mensaje de commit desde un diff | código |
| Traduce texto o archivo | mecánico / largo (auto) |
| Explica código en prosa | código |
| Describe una imagen o responde una pregunta sobre ella (imagen→texto) | visión |
| Diagnóstico de solo lectura: backend, catálogo, log, VRAM, RAM de sistema | — (no llama al backend de chat) |
Los modelos locales no usan tool-calling: el server arma el prompt + guardrails, hace POST al endpoint y devuelve solo texto.
Documentos largos. local_translate (y local_delegate con entradas largas) parten el texto
por límites naturales —headers Markdown, párrafos, líneas— y procesan un trozo por llamada
respetando el techo de max_tokens, concatenando las salidas en orden y conservando el formato en
las costuras. Un documento de 20 000+ caracteres vuelve completo en vez de cortado a mitad. El log
registra chunks: N y el dashboard muestra el progreso (trozo 3/7) mientras corre.
Resúmenes de documentos enormes. local_summarize y local_lint_summary hacen map-reduce
cuando la entrada no cabe en el modelo: resumen cada parte y luego resumen los resúmenes, por
niveles si hace falta. Antes truncaban —de un log de CI enorme se resumía el principio y el resto
se descartaba en silencio, que es justo donde suelen estar los errores— y ahora se lee entero. Si
algún trozo se corta por max_tokens, el resultado lo avisa y el log registra finish_reason: length.
local_extract sigue truncando a propósito: fusionar el JSON de varios trozos no tiene una
respuesta única y adivinarla sería peor que avisar.
Todo por variables de entorno; nada hardcodeado. Los ids de modelo default son solo eso — cámbialos por los de tu backend.
Variable | Default | Descripción |
|
| Endpoint OpenAI-compatible |
| (vacío) | Bearer token, si tu endpoint lo exige |
|
|
|
|
| Timeout HTTP (segundos) |
|
| Backpressure máximo por proceso; compartido por todos los clientes del daemon |
|
| Preguntar al usuario (vía |
|
| Segundos de espera por una respuesta; agotados, la tool sigue como si no hubiera preguntado |
| (dir de datos de usuario) | Directorio de los |
| (vacío = rotación activa) | Si se fija, ruta de un |
|
| Modelo para clasificar/extraer/resumen corto |
|
| Modelo para documentos largos |
|
| Modelo para código |
|
| Modelo de visión para |
|
| Tope de tamaño de imagen para |
|
| Umbral mecánico↔largo |
|
| Tamaño de trozo al partir documentos largos ( |
|
| Techo de |
|
| Trozo mínimo: por debajo ya no se vuelve a partir |
|
|
|
|
| Línea de ahorro anexada al resultado cuando |
| (vacío = sin restricción) | Raíces permitidas para |
|
| Web embebida del modo |
|
| Host/puerto de la web o del daemon |
|
| Tipografía de marca desde Google Fonts ( |
|
| Auto-arranque de llama-swap (opt-in) |
| — | Solo si |
|
|
|
|
| Respaldo entre modelos: si el modelo de un rol falla por su culpa, responde el siguiente de su cadena ( |
|
| Enfriamiento por modelo: 3 fallos seguidos ( |
El MCP registra cada llamada en un log rotado por mes y sirve un dashboard en
http://127.0.0.1:9393, con selector de rango y visibilidad de delegaciones en curso.
El ahorro de contexto = la entrada leída server-side (llamadas con source=path) ≈ tokens que
nunca entraron al contexto de Claude, contados una vez por delegación aunque el MCP la trocee.
Enfrente, el coste local = los tokens que consumió de verdad tu GPU sumando todas las
llamadas: una delegación troceada repite el prompt de sistema en cada trozo, y esa diferencia es
lo que costó trocear. Se usa siempre el token real que reporta el backend; chars ÷ 4 es solo el
respaldo cuando no lo da. Detalle en la wiki.
Los rangos, los días del gráfico y las horas de la tabla usan tu zona horaria (el log se
escribe en UTC, que es un instante sin ambigüedad; la conversión es de presentación). El
dashboard también separa dónde corrió el cómputo: local si el backend escucha en loopback,
remote si la inferencia se fue a otra máquina —por ejemplo esta Mac usando la GPU de la PC—.
Los eventos anteriores a la v0.11.0 no traen el campo y aparecen como n/d.
local-delegate es deliberadamente texto/imagen→texto: arma el prompt (o el payload
multimodal), hace POST a /chat/completions y devuelve solo texto. Cosas que no hace
a propósito:
Tool-calling local. Los modelos locales no invocan herramientas ni ejecutan código; eso lo sigue haciendo Claude. Añadirlo convertiría este paquete en un orquestador paralelo, que no es el objetivo.
Generación o edición de imágenes. local_describe_image es solo imagen→texto
(describir, leer texto visible, responder una pregunta puntual); nada de generar ni
editar imágenes.
Audio. Para transcripción usa el companion
whisper-transcribe-mcp en
vez de intentar meter audio aquí.
Sustituir la suscripción. El objetivo es conservar cuota delegando pasos mecánicos acotados, no enrutar todo el trabajo a modelos locales.
local-delegate install deja lista la integración completa en tu HOME:
Componente | Dónde | Qué hace |
Entrada MCP | config de Claude Code / | registra el servidor (stdio con |
Hooks |
| sugieren delegar; los de lectura además pueden rechazar una lectura completa de documentación, si se enciende |
Skill |
| regla de oro y catálogo de tools |
Memoria | bloque gestionado en | la regla en una nota corta siempre cargada |
Por defecto se configuran solo los clientes que tengas instalados; se elige a mano con
--clients claude|codex|opencode. Los hooks son solo de Claude Code: opencode extiende con
plugins en TypeScript, que es otra superficie, y Claude Desktop no tiene hooks en absoluto. Cada
pieza se puede excluir (--no-hooks, --no-skill, --no-memory, --no-mcp).
El único hook que se instala solo es UserPromptSubmit (intenciones mecánicas). Los dos de
lectura —PreToolUse/Read y PreToolUse/Bash|PowerShell— quedan apagados salvo
--enable-read-hook, que los registra y los enciende juntos (uninstall los apaga). Van juntos
porque son una regla sola sobre dos caminos: cerrar la tool Read y dejar cat informe.md
abierto no cambia la conducta, la muda de sitio.
Esos dos avisan; rechazar una lectura es otra cosa y viene aparte y apagada
(LD_HOOK_READ_BLOQUEAR). Solo alcanza a la lectura completa de un .md o un .txt grande, con
el backend local respondiendo, y el mensaje del rechazo nombra la tool que sirve y la salida de
emergencia: leer por franjas nunca se bloquea. El motivo de que exista es que está medido —cuatro
veces— que sugerir no cambia la conducta.
Ver Instalación de la integración y
docs/recipes/claude-code-hooks.md.
Con pip install "local-delegate-mcp[llamaswap]" quedan disponibles dos CLIs para gestionar
groups de llama-swap (un modelo residente siempre cargado + un pool que se turna) con
guardrail de VRAM y RAM de sistema incorporado (--ram-gb es opcional: llama-server
mapea el GGUF también en RAM aunque el cómputo sea 100% GPU, así que un catálogo que cabe en
VRAM puede igual agotar la RAM en máquinas con menos de 32 GB):
local-delegate check-llamaswap --config config.yaml --vram-gb 16 --ram-gb 32
local-delegate init-llamaswap --config config.yaml --resident gemma3-4b --swap gemma4-26b-a4b,qwen36-35b-a3b --vram-gb 16 --ram-gb 32El paquete nunca toca tu config.yaml por su cuenta — estos comandos solo corren si vos
los invocás. init-llamaswap corre el/los guardrail(es) antes de escribir (no escribe nada si
no cabe en VRAM o, si pasaste --ram-gb, en RAM) y nunca sobreescribe sin --force (dejando
.bak). Detalle completo, semántica de groups verificada contra el código de llama-swap, y
ritual de aplicación en docs/recipes/llama-swap-groups.md.
Genera código boilerplate a partir de una especificación, con un modelo local de código.
**Escribe el código en `target`** y devuelve solo un recibo de dos líneas (ruta, tamaño). El
código generado nunca entra a tu contexto: ahí está el ahorro, y por eso `target` no es
opcional. Para verlo, abre el archivo; para usarlo, ya está en su sitio.
Args:
spec: Descripción de lo que debe generar el código.
language: Lenguaje de programación (p. ej. 'python', 'typescript').
target: Ruta ABSOLUTA del archivo a escribir. Los directorios que falten se crean.
overwrite: Pisar `target` si ya existe. Por defecto falla, y falla ANTES de generar nada.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| target | Yes | ||
| language | Yes | ||
| overwrite | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
La descripción añade contexto muy valioso más allá de las anotaciones: escribe en target, crea directorios intermedios, devuelve solo un recibo de dos líneas, y falla antes de generar nada si target existe y overwrite no está activado. También revela la propiedad clave de que el código generado nunca entra al contexto del agente.
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?
La información está bien jerarquizada: propósito al inicio, advertencia clave en negrita, contrato de salida, y luego una lista compacta de argumentos. Cada frase aporta información necesaria sin repetir el esquema.
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?
La descripción cubre entradas, efecto lateral, salida, condiciones de error y el caso de uso especial de no contaminar el contexto. Con las anotaciones y el esquema de salida disponibles, es suficiente para que un agente invoque la herramienta correctamente.
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?
Con 0% de cobertura en el esquema, la descripción asume toda la responsabilidad y lo hace completamente: define spec, language con ejemplos concretos, target como ruta ABSOLUTA, y overwrite con su comportamiento por defecto y orden de fallo. Ningún parámetro queda sin explicar.
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?
La primera frase combina verbo específico ('Genera'), recurso ('código boilerplate') y origen ('a partir de una especificación'), además de indicar que usa un modelo local. El propósito es inconfundible y no se solapa con los hermanos de resumen, clasificación o extracción.
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?
Explica claramente el contexto de uso: el código se escribe en target y nunca entra al contexto del agente, por lo que target es obligatorio. No menciona alternativas ni exclusiones explícitas respecto a otras herramientas, pero deja claro cuándo tiene sentido usar esta herramienta.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clasifica un texto en UNA de las etiquetas dadas, con un modelo local.
Devuelve exactamente una etiqueta de la lista, sin texto adicional.
Args:
text: Texto a clasificar.
labels: Lista de etiquetas candidatas.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| labels | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and description adds key behavioral notes: exactly one label returned, no extra text, and local model usage. No contradictions.
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 and well-structured, though some information about returning a single label is repeated across sentences.
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 description covers core functionality and behavior, but lacks information on error handling or edge cases. Given the presence of an output schema, completeness is adequate.
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?
Despite 0% schema description coverage, the description includes an Args section with clear explanations for both required parameters (text and labels), compensating fully.
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 it classifies text into exactly one label using a local model, distinguishing it from sibling tools like local_summarize or local_extract.
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 on when to use this tool versus other tools (e.g., when to prefer local vs remote, or alternatives for multi-label classification).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas un mensaje de commit, no el contenido literal.
Redacta un mensaje de commit a partir de un diff, con un modelo local de código.
Pasa 'path' a un archivo de diff (p. ej. la salida de `git diff` volcada a fichero) y se lee
server-side, de modo que el diff completo NO entra al contexto de Claude. Alternativamente
pasa 'diff' como texto. Revisa SIEMPRE el mensaje antes de usarlo.
Args:
diff: El diff como texto (usa esto o 'path').
path: Ruta a un archivo con el diff (leído server-side).
style: 'conventional' (Conventional Commits) o 'plain'.
| Name | Required | Description | Default |
|---|---|---|---|
| diff | No | ||
| path | No | ||
| style | No | conventional |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that it uses a local model, diffs are read server-side, and the content is not sent to context. No contradictions.
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?
Reasonably concise with clear sections and bullet-point-like argument list. Slightly verbose but every sentence adds value.
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?
Covers purpose, when to use, parameter details, and behavioral notes. Output schema exists, so return value explanation is unnecessary. Complete for the tool's complexity.
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 has 0% description coverage, but the description fully explains 'diff' (text or null), 'path' (file path, server-side), and 'style' (conventional/plain), adding meaning 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 it generates a commit message from a diff (verb+resource). It distinguishes from a Read tool but does not explicitly differentiate from sibling tools like local_summarize or local_classify.
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?
Explicitly states when to prefer this tool (large files, only need commit message), provides two input options (diff text or path), and warns to review the message. No alternative tools are mentioned 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.
Tool genérica de escape: delega una tarea texto->texto a un modelo local.
Úsala cuando ninguna tool específica encaje. Arma el prompt con guardrails y devuelve texto.
Con entradas largas parte el input por límites naturales (headers Markdown, párrafos),
aplica la MISMA tarea a cada trozo y concatena las salidas en orden. Eso es lo correcto
para transformar todo el texto (traducir, reescribir, reformatear) pero NO para tareas de
reducción sobre el conjunto (contar, elegir el máximo, un único resumen global): para esas
pasa `chunk='off'` o usa `local_summarize`.
Args:
task: Instrucción de la tarea (una frase con formato de salida explícito).
input: Contenido sobre el que operar.
output_format: Formato exacto de salida esperado.
model: Modelo a usar; uno de los ids configurados en el catálogo. Por defecto el mecánico.
chunk: 'auto' (parte solo si el input es largo), 'on' (parte siempre que se pueda),
'off' (una sola llamada; el input largo puede volver truncado).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| chunk | No | auto | |
| input | Yes | ||
| model | No | ||
| output_format | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals detailed behavioral traits: chunking strategy (splits by natural boundaries, applies same task, concatenates), and limitations for reduction tasks. Annotations provide readOnlyHint, and description adds non-contradictory, useful context.
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 well-structured with purpose first, then chunking explanation, then parameter list. Slightly verbose but every sentence adds value. Could be more concise by merging some lines.
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 (5 params, 3 required, no schema descriptions, has output schema but not explained), the description covers usage, chunking, parameter details, and alternatives completely. It is self-sufficient for correct invocation.
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?
All five parameters are described in the description (task, input, output_format, model, chunk) with clear semantics and default behaviors. This fully compensates for the 0% schema description coverage.
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 it is a generic escape tool that delegates text-to-text tasks to a local model. It distinguishes itself from siblings by specifying 'úsala cuando ninguna tool específica encaje' (use when no specific tool fits) and contrasts with local_summarize.
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?
Explicit guidance on when to use ('cuando ninguna tool específica encaje') and when not to use (reduction tasks: use local_summarize or set chunk='off'). Also mentions alternatives like local_summarize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de adjuntar o leer la imagen tú mismo cuando solo necesitas una descripción, lectura de texto visible (OCR simple) o una respuesta puntual sobre una imagen, no la imagen en sí en tu contexto.
Describe una imagen (o responde una pregunta sobre ella) con un modelo local de visión.
La imagen se lee del lado del servidor: NUNCA entra al contexto de Claude, solo vuelve la
respuesta en texto.
Guardrail de alcance: SOLO imagen->texto (describir, leer texto visible, responder una
pregunta puntual sobre la imagen). Esta tool NUNCA genera ni edita imágenes.
Args:
path: Ruta a la imagen (png/jpg/jpeg/webp/gif), leída server-side.
question: Pregunta o foco concreto sobre la imagen (opcional; por defecto la describe).
max_words: Longitud máxima de la respuesta en palabras.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| question | No | ||
| max_words | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that image is read server-side, never enters Claude's context, and uses a local vision model – valuable behavioral context beyond annotations.
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?
Well-structured: usage guidance first, then tool summary, guardrail, and parameter list. Every sentence adds value; 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?
Covers purpose, usage, parameters, and privacy. Could mention file size limits or error handling, but given annotations and output schema, it is sufficiently complete.
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 coverage is 0%, so description fully compensates by listing path (with supported formats), question (optional, default behavior), and max_words (max length). Provides useful semantics beyond schema titles.
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 it describes an image or answers a question, using the verb 'describe' and 'respuesta'. It specifies image-to-text only and is distinct from sibling text-based tools.
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?
Explicitly tells when to prefer this tool over attaching the image, and guardrail clarifies it never generates images. Does not explicitly name alternatives but context implies them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas una explicación, no el contenido literal.
Explica en prosa qué hace un fragmento/archivo de código, con un modelo local de código.
Pasa 'path' para leer el archivo server-side (el código completo NO entra al contexto de
Claude; solo vuelve la explicación) o 'code'. Opcionalmente enfoca la explicación con
'question'. Revisa la explicación: la genera un modelo local.
Args:
code: Código a explicar (usa esto o 'path').
path: Ruta a un archivo de código (leído server-side).
question: Pregunta o foco concreto (opcional).
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| path | No | ||
| question | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces this by stating the code is read server-side and does not enter Claude's context. It also reveals that a local model generates the explanation, implying potential limitations.
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 well-structured but slightly verbose, with some repetition (e.g., 'Revisa la explicación: la genera un modelo local' echoes earlier statements). It could be more concise.
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 3 parameters, an output schema, and no complex nested objects, the description adequately covers what the tool does, when to use it, and how to use it. It leaves no critical gaps.
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 coverage, the description compensates by explaining the three parameters: code, path (mutually exclusive), and question (optional). It adds clarity on usage beyond the schema types.
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 explains code in prose using a local model, and explicitly distinguishes it from reading files with Read, especially for large files. It lists the parameters and their purposes.
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 explicit guidance on when to prefer this tool over Read (large files, need explanation not literal content), but does not compare with sibling tools like local_summarize or local_classify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas campos estructurados, no el contenido literal.
Extrae campos estructurados de un texto/archivo como JSON, con un modelo local.
Pasa 'path' para leer el archivo server-side (no gasta contexto de Claude) o 'text'.
Devuelve un objeto con exactamente las claves pedidas, ya validado: quien llama no tiene que
parsear una cadena. Si la entrada hubo que truncarla, se añade además la clave reservada
`_local_delegate` con el aviso — antes ese aviso iba como texto delante del JSON, donde
obligaba a limpiar la cadena antes de poder parsearla. Enruta al modelo mecánico
(entradas cortas) o al de contexto largo (documentos grandes) automáticamente: el sondeo
de tamaño usa bytes del archivo para 'path' y caracteres para 'text' (~5-10% de diferencia
en UTF-8, aceptable). Por defecto pide al backend un JSON restringido por schema
(`LOCAL_DELEGATE_JSON_SCHEMA=auto`); si el backend no lo soporta, reintenta en modo libre.
Args:
fields: Nombres de los campos a extraer (claves del JSON).
text: Texto fuente (usa esto o 'path').
path: Ruta a un archivo fuente (leído server-side).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| text | No | ||
| fields | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details that the tool returns a validated JSON with exact keys, uses local models, routes based on size, and uses schema-restricted JSON with fallback. It also explains the _local_delegate key for truncation, which is valuable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded usage guideline, but includes some historical context (e.g., previous behavior of warning before JSON) that is slightly verbose. However, it remains focused and informative.
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 (multiple parameters, automatic routing, truncation handling, schema fallback) and the presence of an output schema, the description covers all necessary aspects: when to use, what it does, how parameters work, and behavioral nuances.
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 fully compensates by explaining that 'path' reads server-side (saving Claude context), 'text' is direct input, and 'fields' are the JSON keys to extract. This adds essential meaning beyond the schema's type definitions.
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 extracts structured fields from text/files as JSON using a local model. It explicitly distinguishes itself from Read for large files and from sibling tools like local_summarize by focusing on field extraction.
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 first line explicitly advises when to prefer this tool over Read: when the file is large (>200 lines/>10 KB) and only structured fields are needed. It also explains automatic model routing and truncation handling, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas un resumen agrupado, no el contenido literal. Si ejecutaste un comando cuya salida es larga, vuélcala a un archivo y pasa 'path'.
Resume salida de linters/tests/CI con un modelo local, sin gastar contexto de Claude.
Pensada para logs largos y ruidosos (ESLint, clippy, pytest, tsc, CI). Pasa 'path' y el
archivo se lee del lado del servidor, de modo que el log completo NO entra al contexto de
Claude: solo vuelve un resumen agrupado por archivo con el conteo por tipo de error/regla y
lo más importante primero. Alternativamente pasa 'text'. Enruta al modelo mecánico (corto) o
al de contexto largo (largo) automáticamente.
Args:
path: Ruta al archivo de salida de lint/tests (leído server-side). Usa esto o 'text'.
text: Salida de lint/tests como texto.
max_words: Longitud máxima del resumen en palabras.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| text | No | ||
| max_words | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds that the file is read server-side, returns a grouped summary with counts, and routes to short/long context model automatically. This provides useful behavioral context beyond annotations.
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 well-structured with a strong recommendation upfront, followed by function explanation and parameter docs. It is slightly verbose but effective, around 10 sentences. No waste.
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 (3 parameters, output schema exists), the description provides complete context: what it does, when to use, parameters, and output nature (grouped summary by file). An output schema is present, so not detailing return values is acceptable.
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 coverage is 0%, but the description fully documents all three parameters: path (server-side read to avoid Claude context), text (direct input), and max_words (summary length with default 200). It adds significant meaning and usage 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 summarizes lint/test/CI output using a local model, saving Claude context. It lists specific use cases (ESLint, clippy, pytest, tsc, CI) and distinguishes from sibling tools like Read.
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 explicitly recommends this tool over Read for large files (>200 lines / >10 KB) needing a grouped summary. It advises dumping long command output to a file and using 'path'. It lacks explicit 'when not to use', but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnóstico de solo lectura del backend local y el catálogo de modelos.
Úsala para saber qué modelos locales hay disponibles y verificar que el backend está vivo
antes de delegar en masa, o para diagnosticar por qué una tool local_* falló.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, and the description reinforces read-only nature with 'solo lectura'. It adds context about checking backend liveness and model catalog availability, which goes beyond the annotation's binary hint. No negative behaviors omitted.
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?
Two concise, front-loaded sentences. No wasted words. Every sentence adds value: first states what it is, second tells when to use it.
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?
With zero parameters, an output schema present, and no nested objects, the description fully covers purpose and usage. It is complete for a diagnostic tool.
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?
No parameters exist (empty schema, 0 params, coverage 100%). Baseline is 4 per rubric. Description does not need to add param info.
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 'Diagnóstico de solo lectura del backend local y el catálogo de modelos' and explicitly distinguishes its diagnostic role from sibling local_* tools by mentioning it diagnoses why a local_* tool failed. The verb 'diagnóstico' and resource 'backend local y catálogo de modelos' are specific.
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?
Explicitly tells when to use: 'para saber qué modelos locales hay disponibles y verificar que el backend está vivo antes de delegar en masa, o para diagnosticar por qué una tool local_* falló'. This gives clear context and exclusions (use before delegation or after failure).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas un resumen, no el contenido literal.
Resume texto o el contenido de un archivo con un modelo local, sin gastar contexto de Claude.
Usa esto para resumir archivos/documentos grandes: pasa 'path' y el archivo se lee del lado
del servidor, de modo que el contenido completo NO entra al contexto de Claude (solo vuelve el
resumen corto). Alternativamente pasa 'text'. Enruta al modelo mecánico (entradas cortas) o al
modelo de contexto largo (documentos grandes) automáticamente.
Args:
text: Texto a resumir (usa esto o 'path').
path: Ruta a un archivo cuyo contenido se resume (leído server-side).
max_words: Longitud máxima del resumen en palabras.
focus: Opcional. Qué te interesa del documento (p. ej. "cifras de configuración",
"riesgos"): el resumen lo prioriza y conserva literales sus datos concretos.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| text | No | ||
| focus | No | ||
| max_words | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavior: the file is read server-side, the full content does not enter Claude's context, and routing between short-input and long-context models is automatic. It also explains how the focus parameter alters summarization behavior by preserving literal data points. This is substantial value added beyond annotations.
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 somewhat long but each sentence earns its place: the primary recommendation is front-loaded, followed by the core mechanismhare, then parameter details. The opening 'PREFIERE' is direct and memorable. Minor redundancy exists between the first and third sentences, but overall it is 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?
The description is complete enough for an agent to select and invoke the tool correctly: it covers purpose, alternatives, input modes, model routing, and parameter semantics. Given the output schema exists hanjak and annotations are provided, the lack of explicit error/edge-case documentation is acceptable. It could briefly clarify how this differs from extraction-style siblings like local_extract, but that is not a blocking gap.
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%, but the description explains all four parameters in plain language: text vs path, max_words as summary length, and focus as optional prioritization. It could go further by explicitly noting that exactly one of text/path should be provided and that max_words should be positive, but the existing explanations largely compensate for the schema's silence.
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 ('Resume') with a clear resource (text or file path) and explicitly contrasts itself with Read ('PREFIERE esta tool en vez de leer el archivo con Read'), which distinguishes it from the most likely alternative. It also names the exact condition for use: large files where a summary, not literal content, is needed.
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 explicit when-to-use guidance: 'cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas un resumen'. It also explains the preferred input mode (path vs text) and can be inferred when not to use it (when literal content is required). This is strong, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFIERE esta tool en vez de leer el archivo con Read cuando el archivo es grande (>200 líneas / >10 KB) y solo necesitas la traducción, no el contenido literal.
Traduce texto o el contenido de un archivo con un modelo local, sin gastar contexto de Claude.
Pasa 'path' para leer el archivo server-side (el original no entra al contexto de Claude) o
'text'. Conserva el formato del original y devuelve SOLO la traducción. Enruta al modelo
mecánico (corto) o al de contexto largo (largo) automáticamente.
Los documentos largos se parten por límites naturales (headers Markdown, párrafos) y cada
trozo se traduce en su propia llamada; el resultado vuelve completo y en orden, sin el
aviso de salida truncada.
Args:
target_lang: Idioma destino (p. ej. 'español', 'inglés', 'francés').
text: Texto a traducir (usa esto o 'path').
path: Ruta a un archivo cuyo contenido se traduce (leído server-side).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| text | No | ||
| target_lang | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral detail beyond annotations: uses local model, does not consume Claude context, preserves format, splits long documents by natural boundaries, returns complete and ordered result. No contradiction with readOnlyHint=true.
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?
Well-structured with bold guidance first, then function, then parameter details. Front-loaded with key usage rule. Slightly verbose but every sentence adds value. Could be trimmed slightly but effective.
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?
Comprehensive for a tool with 3 parameters and file handling. Covers large file splitting, routing, output format, and parameter semantics. Output schema exists so return values are covered elsewhere.
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 has 0% description coverage, but the description fully compensates by explaining target_lang with examples, and the mutual exclusivity of text and path. Adds context about server-side file reading and automatic routing.
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 translates text or file content using a local model, preserving format and returning only translation. It distinguishes from Read for large files and from sibling tools (summarize, classify, etc.). The verb 'translate' and resource 'text/file' are specific.
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?
Explicitly recommends this tool over Read for large files (>200 lines/10KB) when only translation is needed. Provides context on when to use path vs text parameters. Does not explicitly list alternatives among siblings, but the usage context is clear.
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.32.0local_summarize1 field changedInput schema / properties / focusAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Focus"
+}v0.27.0local_boilerplate3 fields changedInput schema / properties / overwriteAdded value: +{
+ "default": false,
+ "title": "Overwrite",
+ "type": "boolean"
+}Input schema / properties / targetAdded value: +{
+ "title": "Target",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "spec",
- "language"
-]New value: +[
+ "spec",
+ "language",
+ "target"
+]v0.16.0local_extract4 fields changedOutput schema / additionalPropertiesAdded value: +trueOutput schema / propertiesRemoved value: -{
- "result": {
- "title": "Result",
- "type": "string"
- }
-}Output schema / requiredRemoved value: -[
- "result"
-]Output schema / titlePrevious value: -"local_extractOutput"New value: +"local_extractDictOutput"v0.12.2local_delegate1 field changedInput schema / properties / chunkAdded value: +{
+ "default": "auto",
+ "title": "Chunk",
+ "type": "string"
+}v0.3.0local_describe_imagev0.2.0local_boilerplatelocal_classifylocal_commit_msglocal_delegatelocal_explain_codelocal_extractlocal_lint_summarylocal_statuslocal_summarizelocal_translateScored across 11 tools
Most tools are clearly distinct (classify, summarize, extract, boilerplate, commit_msg, translate, explain_code, describe_image, status), but local_delegate is a generic escape that overlaps with all others, and local_summarize vs local_lint_summary both summarize with grouping/counts, though their input domains differ. The overlap is acknowledged but could still cause selection ambiguity.
All tools follow a consistent 'local_' prefix with a clear verb_noun pattern (classify, summarize, extract, boilerplate, delegate, lint_summary, commit_msg, translate, explain_code, describe_image, status). Minor inconsistency: local_lint_summary and local_commit_msg are noun-first rather than verb-first, but the pattern is otherwise consistent.
11 tools is within the ideal 3-15 range and each tool serves a distinct purpose, though the generic local_delegate could arguably be merged or removed since it duplicates the others. The count is reasonable for a local model delegation server.
The server covers a broad range of local model tasks (text classification, summarization, extraction, code generation, lint summary, commit messages, translation, code explanation, image description) with a generic fallback. Minor gaps: no tool for local model chat or text generation beyond transformation tasks, and no tool for editing/generation of images (explicitly out of scope). Overall, the surface is well-suited to its purpose.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Check if a task runs locally vs cloud. Save money on calls that don't need cloud inference.
Convert files too big or exotic for a sandbox: 140+ formats, batch, OCR, AI extraction, TTS/STT
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
