Skip to main content
Glama
ZahiriNatZuke

local-delegate

by ZahiriNatZuke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

local_boilerplate

Generate boilerplate code from a spec with a local model, writing it to a target file and returning only a path and size. Use it to add code without loading generated content into context.

Instructions

Generates boilerplate code from a specification, with a local code model.

**Writes the code to `target`** and returns only a two-line receipt (path, size). The generated
code never enters your context: that is where the saving is, and that is why `target` is not
optional. To see it, open the file; to use it, it is already in place.

Args:
    spec: Description of what the code must do.
    language: Programming language (e.g. 'python', 'typescript').
    target: ABSOLUTE path of the file to write. Missing directories are created.
    overwrite: Overwrite `target` if it already exists. By default it fails, and it fails
        BEFORE generating anything.

Input Schema

NameRequiredDescriptionDefault
specYes
targetYes
languageYes
overwriteNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.27.0
    • addedInput schema / properties / overwrite
      Added value: +{
+  "default": false,
+  "title": "Overwrite",
+  "type": "boolean"
+}
    • addedInput schema / properties / target
      Added value: +{
+  "title": "Target",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "spec",
-  "language"
-]New value: +[
+  "spec",
+  "language",
+  "target"
+]
  2. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations, which only say readOnly=false, destructive=false, idempotent=false. The description discloses that output is a two-line receipt rather than code, that generated content never enters context, that missing directories are created, and that failure on an existing target happens BEFORE generation. That ordering detail is genuinely useful 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?

Front-loads the key constraint with bold emphasis, and the Args block is tight and scannable. The 'that is where the saving is' sentence is slightly rhetorical but does justify why target is required, so it roughly earns its place.

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?

A mutation tool with a schema, annotations, and an output schema. The description covers the write behavior, the receipt-only return, directory creation, and overwrite failure ordering, so an agent can call it correctly with no further inference.

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 does so: it defines spec, language, target (absolute path, missing dirs created), and overwrite (default failure semantics and pre-generation check). That is a complete contract for all four parameters.

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 (generates), a specific resource (boilerplate code), and names the mechanism (a local code model), which cleanly separates it from siblings like local_translate or local_summarize. An agent knows exactly what this tool produces without opening the schema.

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

Usage Guidelines3/5

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

The description explains the rationale for `target` being mandatory and tells the agent to open the file to see the code, which implies the intended workflow. However, it never states when to choose this over alternatives such as local_delegate, nor any explicit exclusions.

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