Skip to main content
Glama
ZahiriNatZuke

local-delegate

by ZahiriNatZuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

local_summarize

Read-only

Summarize large files or text with a local model to save context: pass a path for server-side reading or text, and get a focused summary without loading full content into Claude.

Instructions

PREFER this tool over reading the file with Read when the file is large (>200 lines / >10 KB) and you only need a summary, not the literal content.

Summarizes text or the content of a file with a local model, without spending Claude's context.

Use it to summarize large files/documents: pass 'path' and the file is read server-side, so
the full content does NOT enter Claude's context (only the short summary comes back).
Alternatively pass 'text'. Routes automatically to the mechanical model (short inputs) or to
the long-context model (large documents).

Args:
    text: Text to summarize (use this or 'path').
    path: Path to a file whose content is summarized (read server-side).
    max_words: Maximum length of the summary in words.
    focus: Optional. What you care about in the document (e.g. "configuration figures",
        "risks"): the summary prioritizes it and keeps its concrete data verbatim.

Input Schema

NameRequiredDescriptionDefault
pathNo
textNo
focusNo
max_wordsNo

Output 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.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely non-obvious behavior: the file is read server-side so content does NOT enter Claude's context, and routing is automatic between a mechanical model (short inputs) and a long-context model (large documents). These are substantive operational traits not derivable from structured fields.

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

Conciseness4/5

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

Front-loaded with the decision rule, then the mechanism, then the args block. The context-saving point is restated twice ('without spending Claude's context' / 'does NOT enter Claude's context'), which is mild redundancy, but the structure is clean and each section is useful.

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

Completeness5/5

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

With an output schema present, the description need not describe the return value, and it covers everything else an agent needs: when to choose it, both input modes, the server-side read, routing, and per-parameter semantics.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the load and it does: it explains the text/path alternation, that focus makes the summary prioritize a topic and keep its concrete data verbatim, and that max_words caps summary length. All four parameters are given meaning beyond their bare names and defaults.

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?

States a specific verb and resource ('Summarizes text or the content of a file with a local model') and immediately distinguishes itself from the Read sibling by naming the exact conditions (>200 lines / >10 KB) where it should be preferred.

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

Usage Guidelines5/5

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

Explicitly says 'PREFER this tool over reading the file with Read when the file is large ... and you only need a summary' – a named alternative plus the condition that selects it. It also states the two input modes (path vs text), so nothing about when-to-use is left to inference.

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