local-llm-mcp

Overview Schema Source Related Servers Discussions Admin

Delegate a task with inline material and/or files

local_llm_delegate

Read-only

Run private or large-output tasks on a local LLM by providing text, files, or command output, and receive sanitized placeholders or digested summaries so data stays on your network.

Instructions

Hand a task to the local worker model over material you name: inline text (material), files or directories to read (paths; directories are listed), and/or the output of a shell command (command). Use for reading or summarizing files and documents, research and synthesis over provided text, calculations, format transformations, parsing, boilerplate drafting, and — in PII mode — anything that touches private data (names, addresses, credentials, personal mail; the worker reads it, you receive placeholders such as [PERSON-1] that you can reuse in later calls). Set verbatim=true ONLY when you will reproduce or edit the text itself (code, config, an error with its stack): the worker locates the lines and the server quotes them. Leave it false for anything to be answered, counted, summarised or listed. The worker also carries its own running memory of this conversation, so follow-up tasks can refer to earlier results by turn id (t_xxxxxx) or artifact ref (a_xxxxxxxx).

Input Schema

TableJSON Schema

Name	Required	Description
`cwd`	No	Base directory for relative paths and the command.
`task`	Yes	What to do, precisely: what to extract, what to report, thresholds, output shape.
`paths`	No	Files or directories to read as material (~ expands). Optional.
`command`	No	Shell command whose output is added to the material (bash -c; placeholders expanded server-side). Optional.
`material`	No	Inline text to work on (pasted output, a document, data). Optional.
`verbatim`	No	Copy the matching lines byte for byte instead of answering (the worker only locates them). Only for text you must reproduce or edit (a function, a config block, an error with its stack). NOT for questions, counts, summaries or listings: those need the digest, which is the default.
`max_output_chars`	No	Soft budget for the answer (0 = server default).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A5/5.0

Behavior5/5

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

The description adds behavioral detail beyond the annotations: it explains the delegation to the local worker model, the handling of PII with placeholders, the verbatim mode behavior ('the worker only locates them'), and the worker's running memory. It explicitly notes that command output is 'added to the material' and that max_output_chars is a 'soft budget,' all consistent with the read-only, non-destructive hints.

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?

The description is long but tightly organized: a one-sentence definition, a use-case list, a dedicated explanation of the verbatim flag, and a closing note on memory references. Each sentence adds necessary guidance without redundancy, and the flow from general purpose to specific parameter semantics is logical and easy to follow.

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?

Combined with the fully covered schema (100% parameter descriptions) and annotations (read-only, non-destructive), the description fills all gaps an agent might encounter. It covers special cases such as PII placeholders, verbatim behavior, shell command expansion, and the ability to refer to prior turn outputs. The presence of an output schema further completes the picture, so no critical guidance 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?

While the schema already describes each parameter, the tool description enriches their meaning. For example, verbatim is explained with a clear rule: 'Set verbatim=true ONLY when you will reproduce or edit the text itself... Leave it false for anything to be answered, counted, summarised or listed.' Material, paths, and command are given contextual framing ('inline text to work on', 'files or directories to read as material', 'shell command whose output is added to the material').

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's core function: 'Hand a task to the local worker model over material you name...' and enumerates the input types (inline text, files/directories, shell command output). The title 'Delegate a task with inline material and/or files' reinforces the specific action and resource, distinguishing it from sibling run/artifact/status tools.

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 provides explicit guidance on when to use it: 'Use for reading or summarizing files and documents, research and synthesis over provided text, calculations, format transformations, parsing, boilerplate drafting, and — in PII mode — anything that touches private data...' It also details when to set verbatim=true vs false and mentions the ability to reference earlier results via turn/artifact IDs, giving the agent clear decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server