Skip to main content
Glama

monitor_print

Read-only

Get a one-shot, human-readable 3D printer status report covering progress, temperatures, speed, errors, cost estimate, ETA, and optional camera snapshot for quick checks.

Instructions

One-shot print status report (human-readable text: progress, temps, speed, cost, ETA).

Use for quick status checks. Returns a fixed-format text report with
progress, temps, speed, errors, cost estimate, camera snapshot, and
health commentary. For structured data + AI vision inspection, use
``monitor_print_vision``. For persistent background monitoring, use
``watch_print``.

This is the text report from the computer the printer is attached
to.  When Kiln's hosted connector is also connected,
``monitor_printer`` there is the door for the inline live monitor and
camera; call that one to show the person a live panel.  The report's
closing ``Live monitor:`` line says whether a panel came with THIS
result or where the live monitor is instead — repeat it as written.

:param printer_name: Target printer name.  Omit for the default printer.
:param include_snapshot: Whether to capture and save a camera snapshot.
:param brief_id: Optional saved-goal id from ``design_session``.  When
    the brief resolves, the report appends a single ``Goal:`` line
    with the design's duty and environment — so the agent watching
    a print can answer "is this the right design for the goal?"
    without a separate lookup.  Best-effort: a missing kiln-pro
    install or an unresolvable brief silently skips the line.
:param show_panel: Open the inline live monitor panel again even
    though one opened by an earlier call is still live above.  Pass
    only when the person asks to see the panel again; the report
    itself is unchanged.  Read by the inline monitor's result hook
    (``kiln.local_monitor``), not here.

INLINE LIVE MONITOR: in apps that draw MCP Apps panels, this tool's result also carries Kiln's inline print monitor — a live panel with progress, temperatures, and the camera while a print runs. The result's own 'Live monitor:' line says whether that panel is open here, attached but unconfirmed, or not available in this app (then it names the web monitor instead); repeat what that line says and never tell the person a panel is open on the strength of this description. The panel polls the printer itself once open, so do not call this tool again to refresh it: later checks go through printer_status or first_layer_status, and a repeat while the panel is live returns the text report with a one-line card, not a second panel. Pass show_panel=True only when the person asks to see the panel again. Free with a Kiln sign-in; the text report below is always complete on its own.

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

Input Schema

NameRequiredDescriptionDefault
brief_idNoOptional saved-goal id from ``design_session``. When the brief resolves, the report appends a single ``Goal:`` line with the design's duty and environment — so the agent watching a print can answer "is this the right design for the goal?" without a separate lookup. Best-effort: a missing kiln-pro install or an unresolvable brief silently skips the line. Default: "".
show_panelNoOpen the inline live monitor panel again even though one opened by an earlier call is still live above. Pass only when the person asks to see the panel again; the report itself is unchanged. Read by the inline monitor's result hook (``kiln.local_monitor``), not here. Default: false.
printer_nameNoTarget printer name. Omit for the default printer.
include_snapshotNoWhether to capture and save a camera snapshot. Default: true.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"Optional saved-goal id from ``design_session``.  When the brief resolves, the report appends a single ``Goal:`` line with the design's duty and environment — so the agent watching a print can answer \"is this the right design for the goal?\" without a separate lookup.  Best-effort: a missing kiln-pro install or an unresolvable brief silently skips the line. Default: \"\"."
    • changedInput schema / properties / include_snapshot / description
      Previous value: -"Default: true."New value: +"Whether to capture and save a camera snapshot. Default: true."
    • addedInput schema / properties / printer_name / description
      Added value: +"Target printer name.  Omit for the default printer."
    • changedInput schema / properties / show_panel / description
      Previous value: -"Default: false."New value: +"Open the inline live monitor panel again even though one opened by an earlier call is still live above.  Pass only when the person asks to see the panel again; the report itself is unchanged.  Read by the inline monitor's result hook (``kiln.local_monitor``), not here. Default: false."
  2. Changed6 schema fields changedv1.5.0
    • removedInput schema / properties / brief_id / default
      Removed value: -""
    • addedInput schema / properties / brief_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / include_snapshot / default
      Removed value: -true
    • addedInput schema / properties / include_snapshot / description
      Added value: +"Default: true."
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • addedInput schema / properties / show_panel
      Added value: +{
      +  "description": "Default: false.",
      +  "title": "Show Panel",
      +  "type": "boolean"
      +}
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description goes further by describing report contents, the 'Live monitor:' line semantics, the best-effort Goal line for brief_id, and the repeat-call behavior. However, the panel narration is delivered in two overlapping passages (body paragraph plus the INLINE LIVE MONITOR block) plus the per-parameter 'show_panel' text, which muddies rather than sharpens the behavioral contract.

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?

Purpose and sibling routing are front-loaded in the first two sentences, which is exactly right. The remainder, though, duplicates content: the live-monitor caveat appears both inline and as a separate headed block, and all four parameter docs are restated verbatim from the schema, adding length without new information.

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?

The tool has an output schema and full annotations, and everything the agent needs for correct invocation is present: what the report contains, that it is read-only, the snapshot behavior, the brief_id best-effort semantics, and the rule about not re-calling while the live panel is open. 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?

Schema description coverage is 100% and the schema's parameter descriptions repeat verbatim the same sentences that appear in the tool description, so the description adds no meaning beyond the structured fields. The only nuance is the note that show_panel is read by the local_monitor result hook — but that is already documented on the parameter itself.

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 specific verb+resource+format: 'One-shot print status report (human-readable text: progress, temps, speed, cost, ETA).' It then names the two closest siblings, monitor_print_vision and watch_print, and states what each is for, so an agent can distinguish this tool from them without opening a 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 selection rules: 'Use for quick status checks', structured data plus vision goes to monitor_print_vision, persistent background monitoring goes to watch_print, and the hosted-connector live panel case goes to monitor_printer. It also states a negative rule — do not call again to refresh an open panel; use printer_status or first_layer_status instead.

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