Skip to main content
Glama
Sign In
Puppet Master

Puppet Master

by khr898
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

puppet_ask

Drafts prose such as docs, emails, commit messages, rewrites, and text explanations. Use for writing only—not code or file questions, and treat output as unverified.

Instructions

Drafts and prose only (docs, emails, commit messages, rewrites, explanations of text you provide). Output is UNVERIFIED. For any question about code or files, use puppet_read instead.

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": {
      "prompt": "<prompt>"
    },
    "name": "puppet_ask"
  }
}

Input Schema

NameRequiredDescriptionDefault
promptYes
contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It discloses the most important trait — 'Output is UNVERIFIED' — and implies no retrieval happens ('text you provide'). It says nothing about what context does, whether any repository state is consulted, or the response shape.

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 short sentences, scope first, the unverified-output caveat and the sibling routing both front-loaded. Nothing redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Scope, trustworthiness, and routing are covered, which is most of what a simple two-param tool needs with no output schema. But the context parameter and the expected output form are left for the agent to guess, which is a real gap given zero schema descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and neither of the two parameters is explained. 'Text you provide' hints that context exists as supplied material, but the agent gets no guidance on how prompt and context differ or how to split content between them.

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?

For an opaque name like 'puppet_ask', the description does the work of defining scope: prose drafts and rewrites, explicitly excluding code/file questions. The verb is implicit ('Drafts and prose only'), but the boundary against puppet_read makes the tool's identity unambiguous.

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?

'For any question about code or files, use puppet_read instead' names the alternative and the routing condition explicitly. It does not address the other siblings (puppet_write, puppet_apply), but for a draft-only tool the code-vs-prose split is the decision that matters.

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