Skip to main content
Glama

plate_status

What Kiln knows is on the build plate -- read-only, no printer round trip.

Instructions

What Kiln knows is on the build plate -- read-only, no printer round trip.

Kiln records the plate at the moments it can be sure of: a print Kiln
started puts a part there (``occupied``, with the file and, where Kiln
could read it, the part's height); a print seen ending leaves it there;
a PERSON says it is empty (``plate_clear=true`` on ``home_axes`` or
``park_head``, or ``kiln plate clear`` at the command line); and a LOOK
through the machine's camera settles it either way (``look_at_plate``).  Anything
else -- no record, a torn record, a print started at the printer's own
screen -- reads as ``unknown``, and the answer then says whether a
camera could settle it.

Why it matters: ``home_axes`` and ``park_head`` start with the vendor's
raise and then cross the head's row a few millimetres up -- and a
collision there raises no fault.  When the record names a part taller
than that raise, both refuse and say so; a ``clear`` record is what
lets them stop asking about the row.  A Z home that presses the nozzle
onto the plate (the A1 mini) asks on every call regardless -- the
record cannot see a print started from the printer's own screen, and
that press is the one motion a stale record must never answer for.

An ``occupied`` record says a part WAS there.  ``recorded_ago`` says
how long ago, and every refusal that rests on it carries a look at the
plate where the machine has a camera -- so look (``look_at_plate``)
rather than take an old record's word that the part is still there.

There is deliberately no tool that marks the plate clear from nothing:
that is a statement someone has to make, at the machine, at the command
line, by looking through the camera and saying what they see, or -- a
person in a chat -- in their own words, which ``look_at_plate`` records
as theirs (``person_says``) and labels as passed on when it could not
ask them itself.

Args:
    printer_name: Which printer.  Omit for the default one.

Returns ``plate`` with ``status`` (``unknown`` / ``occupied`` /
``clear``), ``source``, ``since``, ``job`` (``file``, ``footprint_mm``,
``max_z_mm``, ``printer_id``), ``from_camera`` and ``looked_by`` when a
look wrote it, ``recorded_ago`` (how old the record is, in words), and a
one-line ``description``; plus ``camera``, whether this machine has one
that could settle an unknown plate.

Input Schema

NameRequiredDescriptionDefault
printer_nameNo

Output Schema

NameRequiredDescriptionDefault

No arguments

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 burden and does: it declares read-only / no round trip, explains the unknown fallback for absent or torn records and prints started at the printer's own screen, and discloses staleness via recorded_ago and the camera flag. It even explains downstream behavioral consequences (home_axes/park_head refusing on a tall part).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the 'Why it matters' block is a long mechanical digression about head-row collisions and A1 mini Z homing that mostly justifies the tool rather than helping an agent invoke it. The Returns block also restates what the output schema already provides.

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 single-parameter read tool with an output schema, nothing an agent needs is missing: record provenance, staleness, the unknown path, and camera availability are all addressed. The extra return-value narration is redundant against the output schema but not harmful to completeness.

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 the Args block does: 'Which printer. Omit for the default one' supplies the default-on-omission semantics the schema lacks. With only one optional parameter there is little more to say, so this is close to fully covered.

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 first line states a specific verb+resource (reads what Kiln knows is on the build plate) plus its scope (read-only, no printer round trip). It also distinguishes the tool from the sibling that would give ground truth by naming look_at_plate explicitly and contrasting a cached record against a fresh look.

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 spells out the conditions that produce each status (print started by Kiln, print seen ending, a person asserting empty, a camera look) and, crucially, routes the agent to look_at_plate rather than trusting a stale 'occupied' record. It does not open with an explicit 'use this when' statement, so selection guidance is embedded in narrative rather than front-loaded.

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