Skip to main content
Glama
ZahiriNatZuke

local-delegate

by ZahiriNatZuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

local_summarize

Read-only

Summarize large files without consuming Claude context: the tool reads the file server-side and returns a concise, focusable summary from a local model. Pass a path or text and optionally specify what to prioritize.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
textNo
focusNo
max_wordsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.32.0
    • addedInput schema / properties / focus
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Focus"
+}
  2. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools