Skip to main content
Glama
ZahiriNatZuke

local-delegate

by ZahiriNatZuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

local_delegate

Read-only

Delegates generic text-to-text tasks to a local model when no specific tool fits, chunking long inputs and returning text to save Claude quota.

Instructions

Generic escape tool: delegates a text->text task to a local model.

Use it when no specific tool fits. Builds the prompt with guardrails and returns text.

With long inputs it splits the input at natural boundaries (Markdown headers, paragraphs),
applies the SAME task to each chunk and concatenates the outputs in order. That is right for
transforming the whole text (translate, rewrite, reformat) but NOT for reduction tasks over the
whole (counting, picking the maximum, a single global summary): for those pass `chunk='off'` or
use `local_summarize`.

Args:
    task: Task instruction (one sentence with an explicit output format).
    input: Content to operate on.
    output_format: Exact expected output format.
    model: Model to use; one of the ids configured in the catalog. Defaults to the mechanical one.
    chunk: 'auto' (splits only if the input is long), 'on' (splits whenever possible),
        'off' (a single call; a long input may come back truncated).

Input Schema

NameRequiredDescriptionDefault
taskYes
chunkNoauto
inputYes
modelNo
output_formatYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.2
    • addedInput schema / properties / chunk
      Added value: +{
+  "default": "auto",
+  "title": "Chunk",
+  "type": "string"
+}
  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 cover readOnlyHint/openWorldHint; the description goes well beyond them by disclosing the chunking algorithm (splits at Markdown headers/paragraphs), the ordering guarantee (concatenates outputs in order), and the concrete failure mode (a long input may come back truncated with chunk='off'). That is the exact behavioral context an agent needs before invoking.

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 one-line purpose, then a usage paragraph, then a compact Args block; every section does work. It is slightly longer than strictly necessary (the Args list restates parameter names), but given 0% schema coverage that repetition is functional rather than padding.

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?

Output schema exists, so return-value explanation is correctly omitted. For a 5-parameter tool with no schema descriptions and no enum metadata, the description supplies chunking behavior, truncation risk, model default, and sibling routing — nothing an agent needs to call it correctly is missing.

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 carries the full burden, and it does: task is defined as a one-sentence instruction with an explicit output format, input as the content, output_format as the exact expected format, model's default and provenance, and chunk's three enum values are each given semantics. This fully compensates for the empty schema descriptions.

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 first line states a specific verb and resource ('delegates a text->text task to a local model') and explicitly frames itself as the generic fallback ('escape tool'). It also names a sibling (local_summarize) and the condition that routes away from it, so an agent can place it against the ten other local_* tools without opening schemas.

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?

Gives explicit when-to-use ('when no specific tool fits'), explicit when-not (reduction tasks over the whole text: counting, maximum, single global summary), and names both escapes: pass chunk='off' or use local_summarize. The chunk mode tradeoff (correct for transforms, wrong for reductions) is spelled out rather than implied.

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