local-delegate

by ZahiriNatZuke

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.24.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
All tools follow a consistent 'local_verb_noun' pattern (e.g., local_summarize, local_classify, local_extract). No mixing of conventions.
Tool Count5/5
11 tools is within the ideal 3-15 range, each tool serves a specific local AI task, and none seem redundant.
Completeness5/5
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.
Average 4.5/5 across 9 of 11 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 186 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
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 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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![local-delegate MCP server](https://glama.ai/mcp/servers/ZahiriNatZuke/local-delegate/badges/card.svg)](https://glama.ai/mcp/servers/ZahiriNatZuke/local-delegate)

Score Badge

Copy to your README.md:

[![local-delegate MCP server](https://glama.ai/mcp/servers/ZahiriNatZuke/local-delegate/badges/score.svg)](https://glama.ai/mcp/servers/ZahiriNatZuke/local-delegate)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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