Skip to main content
Glama

look_at_plate

Destructive

Capture a build-plate image from a printer camera and record whether the plate is clear or occupied before printing.

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.

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

Input Schema

NameRequiredDescriptionDefault
seenNoOmit to fetch the picture. ``"clear"`` or ``"occupied"`` to record what you saw in the picture you were just given.
person_saysNoThe person's own words that the bed is clear, exactly as they typed them. Not with ``seen``.
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 / person_says / description
      Added value: +"The person's own words that the bed is clear, exactly as they typed them.  Not with ``seen``."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default one."
    • addedInput schema / properties / seen / description
      Added value: +"Omit to fetch the picture.  ``\"clear\"`` or ``\"occupied\"`` to record what you saw in the picture you were just given."
  2. Addedv1.5.0

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations it discloses a great deal: the two-step fetch/record protocol, that the frame is saved to a local snapshot_path and never written to a log, that the image includes the surrounding room, that the response includes a `look` block plus image content, and that machines without a camera stay `unknown`. The one gap is that destructiveHint=true is never explained — recording over an existing plate record (e.g. overwriting 'occupied' with 'clear') is treated as consequence-free, with no note on reversibility or evidence retention.

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?

It is front-loaded well (the two-step contract arrives in paragraph one) and the prose is readable, but at roughly 370 words it is bloated for a three-parameter tool: the 'look then come straight back with seen' instruction recurs three times, the privacy point is repeated, and the Args block duplicates the schema descriptions verbatim. Tightening toward half the length would lose nothing behavioural.

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?

With no output schema, the description carries the return contract itself — '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.' It also covers camera-source variability (machine camera vs camera_snapshot_url vs neither), the safety asymmetry of wrong verdicts, and the human-confirmation path, which is everything an agent needs to call it correctly.

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 description coverage is 100%, so the schema already documents all three parameters, and the Args section largely restates those same sentences. The description adds a little genuinely new meaning — that `seen` records what was in the picture 'you were just given', that `person_says` must be verbatim typed words and must not accompany `seen`, and that printer_name falls back to the default. That is a modest supplement over an already-complete schema, so the baseline 3 fits.

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 gives a specific verb and resource ('Look at the build plate through the machine's camera, and record what is there') and the closing paragraphs explicitly separate it from sibling vision tools: 'Kiln ships no vision model and judges nothing here. The eyes are yours; this tool is the camera and the pen.' An agent can tell it apart from printer_snapshot, webcam_stream, or analyze_print_snapshot 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?

It gives explicit when-to-call branches: call without `seen` to fetch a frame, call again with `seen="clear"` or `"occupied"` to record, come straight here with `seen` after a refusal that carries a snapshot, re-judge under ALWAYS_ALLOW_LOOK_FIRST, and use `person_says` only for a person's flat typed statement. It also names the exclusion cases ('a hedge or a question is not that', 'Never write these words yourself') and the fallback when uncertain ('If you cannot tell, say "occupied"').

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