Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

printer_bench

Destructive

Teaches Kiln how a specific 3D printer moves by running a guided test print that pauses, resumes, cancels and ends, then records head positions so occupied-plate placement is safer.

Instructions

Help Kiln get to know your printer in a few minutes: a guided session, one ask at a time.

Kiln judges where a second part can go on an occupied plate from a
record of how each printer moves its head on its own.  Where that
record has a blank -- a pause, cancel or end nobody has described, a
head nobody has measured -- Kiln assumes the worst.  This session
fills the blanks for THIS printer: it prints a coin-sized square,
pauses, resumes, cancels and ends it, and watches where the head goes.
A Klipper or Marlin printer says where its head is, so nothing about
the moves is asked; a closed-firmware printer is asked which numbered
zone the head stopped in (a picture is included) and about how high it
lifted.  Numbers only ever leave the machine, and only while telemetry
is on.  Runout is never tested.

Call it with no ``answer`` to start or resume.  Every reply carries
``ask`` (one sentence -- relay it word for word), ``images`` (what each
picture is; the pictures themselves follow the reply as images, in the
same order -- show them), ``options`` when the answer is a choice, and ``waiting`` with
``check_again_in_seconds`` when Kiln is watching the print and there is
nothing to ask yet.  Hand the person's answer back as ``answer``.  The
test print is a real print: when the reply says so, show the file with
``visualize_model``, get a token with ``issue_preview_token`` and start
it with ``run_quick_print`` -- the normal approval dialog shows, once.
``restart=True`` throws the session away and begins again.

Args:
    printer_name: Which printer.  Omit for the default one.
    answer: The person's answer to the previous ask, verbatim.
    restart: Begin again from the first ask.

Returns the next ask, or ``done`` with what Kiln learned, the payoff
line, and what it still does not know.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "printer_bench"
  }
}

Input Schema

NameRequiredDescriptionDefault
answerNoThe person's answer to the previous ask, verbatim.
restartNoBegin again from the first ask. Default: false.
printer_nameNoWhich printer. Omit for the default one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / answer / description
      Added value: +"The person's answer to the previous ask, verbatim."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default one."
    • changedInput schema / properties / restart / description
      Previous value: -"Default: false."New value: +"Begin again from the first ask. Default: false."
  2. Addedv1.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say destructive=true and openWorld=false; the description goes well beyond that by disclosing that the test print is a real print, that a single approval dialog appears, that restart destroys the existing session, that data leaves the machine only while telemetry is on, and that firmware type changes what is asked. It also states the failure mode the tool addresses (Kiln assumes the worst on blanks) and the limitation (runout untested).

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?

Purpose is front-loaded and the structure (motivation, procedure, reply contract, args, returns) is logical. There is some narrative flourish ('Kiln assumes the worst', 'fills the blanks') that could be trimmed, but every paragraph conveys operational information an agent needs.

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?

For a stateful, multi-turn, destructive tool with no output schema, the description covers the turn protocol, the contents of every reply (``ask``, ``images``, ``options``, ``waiting``), how to relay it, and what a done reply contains. Nothing essential to calling it correctly is missing.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a description, so the Args block largely restates the schema. It adds real meaning only for ``restart`` (throws the session away and begins again) and emphasizes 'verbatim' for ``answer``. Baseline 3 is appropriate given the schema does the heavy lifting.

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 opening sentence names a specific resource (Kiln's knowledge of this printer) and mechanism (a guided, one-question-at-a-time session), and the second paragraph explains precisely what the session does — prints a coin-sized square, pauses, resumes, cancels, ends it, and watches head movement. This is readily distinguishable from siblings like run_benchmark, calibrate_direct, or run_calibrate, which are not interviewing sessions about head-motion records.

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?

It gives explicit invocation guidance: call with no ``answer`` to start or resume, hand back the person's answer as ``answer``, and ``restart=True`` to restart. It also names the downstream calls in order (visualize_model, issue_preview_token, run_quick_print) and excludes one scope ('Runout is never tested'). It stops short of saying when a sibling such as run_calibrate or run_benchmark should be chosen instead, so it is clear context without explicit alternatives.

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