Skip to main content
Glama

plate_status

Read-only

Checks whether the build plate is clear, occupied, or unknown before homing or parking, helping avoid collisions with parts that a stale record may hide.

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.

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": "plate_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_nameNoWhich printer. Omit for the default one.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default one."
  2. Addedv1.5.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already carried structurally; the description goes far beyond that by explaining how records are created, why 'unknown' is the fallback (no record, torn record, print started at the printer's own screen), what recorded_ago means, and why a stale record must never answer a Z-home press. This is exactly the kind of trust model an agent needs but annotations cannot express.

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?

The first sentence is well front-loaded, but the body sprawls across parenthetical asides, backticked state names, and rhetorical framing ('Why it matters', 'There is deliberately no tool...'). The closing Returns paragraph largely restates the output schema, which already exists, so several sentences do not earn their place for an agent deciding how to call a one-parameter read.

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?

Given a status-read tool with an output schema, one optional parameter, and clear annotations, everything an agent needs is present: what the states mean, that a camera field indicates whether an unknown can be resolved, and why the record should not be trusted indefinitely. Nothing material 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?

The single parameter has 100% schema description coverage, and the description's 'printer_name: Which printer. Omit for the default one.' merely restates it verbatim. Baseline 3 for high coverage with no additional meaning contributed.

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?

States a specific verb and resource up front ('What Kiln knows is on the build plate -- read-only, no printer round trip') and explicitly separates itself from look_at_plate (which writes a record) and from home_axes/park_head (which consume it). An agent can place this tool relative to its siblings without opening any schema.

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?

Gives explicit when and when-not guidance: read this record, but when it says 'occupied' and recorded_ago is old, use look_at_plate rather than trusting it; a 'clear' record is what lets home_axes/park_head stop asking. It also names the deliberate absence of a 'mark clear from nothing' tool, which prevents an agent hunting for one.

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