Skip to main content
Glama
Sign In
Puppet Master

Puppet Master

by khr898
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

puppet_write

Creates a staged patch for boilerplate, scaffolding, tests, docstrings, or mechanical refactors and runs tests on it automatically; review patch_path before applying.

Instructions

USE THIS for boilerplate, scaffolding, tests from a spec, docstrings, mechanical refactors. Flint writes a STAGED patch (your working tree is untouched) and tests run on it automatically. You MUST read the patch at patch_path before calling puppet_apply. To retry, call again with the same task and your feedback in constraints (max 2 attempts). A file over ~2k tokens is edited by region: Flint sees an outline and rewrites only the blocks that match the task, so name the function or class to change. Limits: ≤3 files, ≤6k tokens of editable text total.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task": "<task>",
      "files": "<files>"
    },
    "name": "puppet_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskYes
filesYes
constraintsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does it well: it discloses that changes are staged rather than applied, that the working tree is untouched, that tests run automatically, the hard limits (≤3 files, ≤6k tokens of editable text), the max 2 attempts, and the region-based rewrite behavior for files over ~2k tokens.

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?

Dense but front-loaded: allowed uses first, then staged-patch semantics, then the mandatory puppet_apply step, then retry rules, then limits. Every sentence carries operational information, including the size limits and the region-edit hint, with no filler.

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?

For a mutation-style code tool with no annotations and no output schema, it covers the critical unknowns: staging, test execution, retry policy, and hard size caps. It stops just short of a complete picture, since the shape of the result (patch_path and diagnostics) is only implied by the instruction to read the patch.

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 the description must compensate, and it adds real meaning: constraints carries retry feedback, files is bounded by the ≤3 file / ≤6k token limit, and task must be repeated verbatim on retry. It never states the expected format of files (relative vs absolute paths) or what task should look like, leaving one gap.

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 names a specific action on a specific resource: Flint writes a STAGED patch (working tree untouched) and runs tests on it. It also scopes the job to boilerplate, scaffolding, spec-derived tests, docstrings and mechanical refactors. It stops short of a single crisp verb+resource opener ('USE THIS for...' is usage-led), and it distinguishes only puppet_apply, not the other siblings.

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?

Concrete when-to-use list (boilerplate, scaffolding, tests from a spec, docstrings, mechanical refactors) plus an explicit workflow: read the patch at patch_path before calling puppet_apply, and retry by resubmitting the same task with feedback in constraints, capped at 2 attempts. The large-file rule (name the function or class to change) is spelled out too.

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