The local-delegate server offloads mechanical text-to-text tasks to a local LLM (via any OpenAI-compatible backend: Ollama, LM Studio, vLLM, etc.) to preserve Claude subscription quota, processing large files server-side to keep content out of Claude's context.
local_summarize — Summarize text or a file; auto-routes to a long-context model for large documents.
local_classify — Classify text into exactly one label from a provided list.
local_extract — Extract structured fields from text or a file as JSON, with optional schema enforcement.
local_boilerplate — Generate boilerplate code from a specification using a local code model.
local_delegate — Generic escape hatch for any text→text task not covered by a specific tool.
local_lint_summary — Summarize noisy lint/test/CI logs (ESLint, clippy, pytest, tsc, etc.) grouped by file and error type.
local_commit_msg — Generate a Conventional Commits or plain-style commit message from a diff.
local_translate — Translate text or a file to a target language, preserving formatting.
local_explain_code — Explain what a code snippet or file does in prose, with an optional focused question.
local_describe_image — Describe an image or answer a question about it using a local vision model.
local_status — Read-only diagnostic: check backend health, available model catalog, usage log, and VRAM info.
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 "Install 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: mcp-local-llm
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 | 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.
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 ultrarrápido / trivial |
|
| 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 |
|
|
|
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 sin bloquear nunca la tool original |
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. Cada pieza se puede excluir (--no-hooks, --no-skill,
--no-memory, --no-mcp). Los hooks recomendados tras el piloto A/B son
UserPromptSubmit (intenciones mecánicas) y PreToolUse/Bash (salidas largas de lint/tests);
el experimento PreToolUse/Read queda apagado salvo --enable-read-hook, que lo registra y lo
enciende (uninstall lo apaga).
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 llama31-8b,qwen25-coder-14b --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.
Devuelve solo el código, sin explicaciones ni fences markdown.
Args:
spec: Descripción de lo que debe generar el código.
language: Lenguaje de programación (p. ej. 'python', 'typescript').
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| language | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying the return format: 'Devuelve solo el código, sin explicaciones ni fences markdown.' It does not contradict annotations (readOnlyHint is consistent with code generation that doesn't modify external state).
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 concise with two short paragraphs, no filler, and a clear docstring-style parameter section. It could be slightly more compact, but it earns its place.
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 simplicity (2 required params) and the existence of an output schema, the description covers the return format and the tool's core function. It omits potential details like model behavior or size limits, but these are not critical for such a straightforward 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?
Schema description coverage is 0%, so the description fully bears the burden. It explains 'spec' as 'Descripción de lo que debe generar el código' and 'language' as 'Lenguaje de programación', providing necessary semantics beyond the bare 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 verb 'Genera' and the resource 'código boilerplate a partir de una especificación', with the added context of using a local model. This is specific and distinguishes from sibling tools like local_summarize or local_classify, which have different 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?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusion criteria or prerequisites. The description only states what the tool does, leaving the agent to infer usage context.
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.
| 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, consistent with a non-destructive tool. The description adds significant transparency: it explains that the tool uses a local model, routes to short or long context automatically, and for 'path' reads the file server-side so full content doesn't enter Claude's 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?
The description is structured with a strong opening recommendation, bulleted usage notes, and a parameter block in a consistent format. It is slightly verbose but every sentence adds value, and the Spanish wording is natural.
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 presence of an output schema (not shown but indicated), the description does not need to detail return values. It covers the two input modes, automatic routing, and the context-saving advantage. Missing details: error handling for invalid paths or very large files, but overall complete for a summarization 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?
With schema description coverage at 0%, the description compensates by clearly explaining each parameter: 'text' and 'path' as alternatives, and 'max_words' controlling summary length. It also clarifies the behavioral difference between using 'path' (server-side read) vs 'text'. However, it lacks details on allowed file types or path constraints.
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 text or file content using a local model, and explicitly recommends it over reading large files, distinguishing it from a likely sibling tool (Read). The verb 'summarize' and resource ('text or 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?
The description gives explicit when-to-use criteria: large files (>200 lines/>10 KB) when only a summary is needed, and when not to use: when literal content is required. It also contrasts with reading the file directly, providing clear usage context.
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. Dates show when Glama detected each change.
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_translateEach tool has a clearly distinct purpose: summarizing, classifying, extracting, generating boilerplate, general delegation, lint summarization, commit messages, translation, code explanation, image description, and status. No overlapping tool descriptions.
All tools follow a consistent 'local_verb_noun' pattern (e.g., local_summarize, local_classify, local_extract). No mixing of conventions.
11 tools is within the ideal 3-15 range, each tool serves a specific local AI task, and none seem redundant.
The tool surface covers text processing (summarize, classify, extract), code tasks (boilerplate, explain, commit), translation, image description, and a status diagnostic. No obvious gaps for the stated purpose of delegating tasks to local models.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Check if a task runs locally vs cloud. Save money on calls that don't need cloud inference.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Same functionality, consuming only 1/20 of the context window tokens.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZahiriNatZuke/local-delegate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
