Skip to main content
Glama

look_at_plate

Look at the build plate through the machine's camera, and record what is there.

Instructions

Look at the build plate through the machine's camera, and record what is there.

Two steps, one tool.  Called WITHOUT ``seen`` it fetches a frame and
hands it to you as a picture, after a short text record that names
``snapshot_path``, the same picture saved on this computer -- and
records nothing.  Look at it, then call again with ``seen="clear"``
(nothing on the plate) or ``seen="occupied"`` (something is), and that
answer becomes the plate record with you named as the one who looked.

The picture shows whatever the camera sees, the room around the
printer included.  This tool saves it only on this computer and hands
it only to you; it is never written to a log.

A refusal over a recorded part (a slice with no spot named, a print
start, a park or home that would cross it) already carries that frame
as ``snapshot_path`` and says how old the record is: look at it and
come straight here with ``seen``.  A record days old most likely
describes a part someone took off -- look before you ask a person.

A print held with ``ALWAYS_ALLOW_LOOK_FIRST`` carries a frame the same
way: always allow is on for that printer, nobody is being asked, so
the bed is looked at first.  Judge that frame here with ``seen`` and
start the print again; the picture is kept with the print's record.
If you cannot tell, say ``occupied`` -- the person is then the one who
says the bed is clear.

When the PERSON tells you the bed is clear -- typed to you in a chat,
after a refusal that says a part is on it -- pass their words exactly
as ``person_says``.  They have to say it flatly ("bed clear", "the
plate is empty"); a hedge or a question is not that.  Where this app
can show a dialog, Kiln asks the person itself and records their
answer; otherwise the words are recorded as passed on by you, kept on
the record.  Never write these words yourself: if they have not said
it, ask them.  It settles a plate the record says is occupied; a plate
with no such record is settled by looking.

Kiln ships no vision model and judges nothing here.  The eyes are
yours; this tool is the camera and the pen.  Say what you actually see:
a plate you are not sure about is ``occupied``, because the cost of a
wrong "clear" is a print driven into a part and the cost of a wrong
"occupied" is one question.

Works on any printer with a camera Kiln can read -- the machine's own,
or one registered against it with ``camera_snapshot_url``, which works
on every printer type including those with no camera of their own.
A machine with neither says so and stays ``unknown``.

Args:
    printer_name: Which printer.  Omit for the default one.
    seen: Omit to fetch the picture.  ``"clear"`` or ``"occupied"`` to
        record what you saw in the picture you were just given.
    person_says: The person's own words that the bed is clear, exactly
        as they typed them.  Not with ``seen``.

Returns the ``plate`` record and a ``look`` block saying whether a
frame was available and which camera it came from -- followed, when a
picture was taken, by the picture itself as image content.

Input Schema

NameRequiredDescriptionDefault
seenNo
person_saysNo
printer_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.9/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 so: it discloses that the first call records nothing, that the image is saved only locally and never logged, that a printer without a readable camera returns 'unknown', and that `person_says` may be mediated by a dialog or recorded as passed-on. It also discloses the tie-breaking policy (say 'occupied' when unsure) with the rationale.

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?

Front-loaded with the core two-step behavior and generally well organized, but it is long and repeats itself: the parameter semantics are stated in prose and then restated in an Args block, and the 'eyes are yours / wrong clear vs. wrong occupied' rationale is made twice. Most of the length is justified by genuine conditional complexity, but not all of it.

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?

No output schema exists, and the description compensates by describing the return shape (a `plate` record plus a `look` block naming camera availability and source, followed by image content). Given three optional params, no annotations, and safety-critical usage, an agent has everything needed to call it correctly.

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 0%, so the description must compensate, and it fully does: each of the three optional parameters gets a meaning the schema lacks — `printer_name` omit-for-default, `seen` omit-to-fetch vs. the two literal values, `person_says` verbatim quoting and the constraint that it is 'Not with `seen`'.

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?

Opens with a concrete verb+resource ('Look at the build plate through the machine's camera, and record what is there') and immediately makes explicit the unusual two-call shape of the tool: fetch a frame, then record a judgement. This is clearly distinguishable from neighbors like plate_status, printer_snapshot or analyze_print_snapshot, which do not combine capture with recording an agent-authored verdict.

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?

Explicit when-to-use for every branch: call without `seen` to fetch, with `seen="clear"|"occupied"` to record, pass `person_says` only with the person's own flat words. It also names the upstream triggers (a refusal carrying `snapshot_path`, a print held under ALWAYS_ALLOW_LOOK_FIRST) and states the rule for which plates are settled by looking versus by a person.

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