Skip to main content
Glama
codeofaxel

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

printer_bench

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

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.

Input Schema

NameRequiredDescriptionDefault
answerNo
restartNoDefault: false.
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.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 behavioral burden and does so thoroughly: it discloses that the test print is a real print, that an approval dialog appears once, that telemetry controls whether numbers leave the machine, that runout is never tested, and that restart discards the session.

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?

The description is front-loaded with the session's purpose and then walks through the interactive flow, return shape, and real-print implications. It is somewhat long and narrative, but most sentences add operational value for a complex multi-step tool.

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 complex interactive tool with no output schema and no annotations, the description covers the workflow, parameter handling, real-print behavior, firmware-dependent asks, telemetry constraints, and the shape of replies including ask, images, options, waiting, and done.

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 coverage is low at 33%, but the description compensates fully by defining printer_name, answer, and restart. It explains that omitting printer_name selects the default, that answer must be the person's previous answer verbatim, and that restart starts over from the first ask.

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 clearly identifies a guided printer-profiling session, including the test square, pause/resume/cancel/end sequence, and head-position observation. It is distinct from generic print/calibration tools by describing its interactive, firmware-aware workflow, though it does not explicitly name alternatives such as run_calibrate or run_benchmark.

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 clear operational guidance: call with no answer to start or resume, pass the person's answer verbatim, and use restart=True to begin again. It also says when to invoke run_quick_print during the session, but it does not explicitly state when not to use this tool versus other calibration/benchmark tools.

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