Skip to main content
Glama

watch_print

Destructive

Start background monitoring of an in-progress 3D print: poll printer state, capture webcam snapshots, detect stalls, and auto-stop at a set completion percentage.

Instructions

Start background monitoring of an in-progress print.

        Launches a background thread that polls the printer state every
        *poll_interval* seconds and captures webcam snapshots every
        *snapshot_interval* seconds.  Returns immediately with a
        ``watch_id`` that can be used with ``watch_print_status`` and
        ``stop_watch_print``.

        The watcher finishes automatically when:

        1. **Print terminal state** -- completed, failed, cancelled, or offline.
        2. **Snapshot batch ready** -- *max_snapshots* images collected.
        3. **Timeout** -- the print has not finished within *timeout* seconds.
        4. **cancel_at_percent** -- if set (> 0), auto-cancels when completion
           reaches or exceeds this percentage.  Use this for test prints,
           calibration runs, or any case where you want to stop at a specific
           progress point without writing a polling script.
        5. **Hardware stop** -- the print carries a hardware plan (pauses
           written in for nuts, magnets or bearings) and a stop is a few
           minutes away, the printer has stopped for the parts, or it went
           past a stop without stopping: ``outcome: "hardware_stop"`` with a
           ``hardware`` block saying what goes in.  Tell the person; at the
           stop itself, resume only on their word that every piece is in
           (``resume_print(hardware_confirmed=true)``).  Then watch again.

        **Camera ground-truth**: each captured snapshot is hashed and compared to
        the previous frame.  If the camera shows the print bed changing but
        telemetry reports zero progress, the snapshot is flagged with
        ``telemetry_mismatch: true`` so agents can detect broken monitoring
        scripts and fall back to visual inspection.

        Args:
            printer_name: Target printer.  Omit for the default printer.
            snapshot_interval: Seconds between snapshot captures (default 60).
            max_snapshots: Return after this many snapshots (default 5).
            timeout: Maximum seconds to monitor (default 7200 = 2 hours).
            poll_interval: Seconds between state polls (default 15).
            stall_timeout: Seconds of zero progress before declaring stall
                (default 600 = 10 min).  Set to 0 to disable stall detection.
            save_to_disk: Save snapshots as JPEG files to
                ``~/.kiln/timelapses/<watch_id>/`` and persist metadata to the
                database.  Use ``list_snapshots`` to query saved frames after
                the print completes (default False).
            cancel_at_percent: Auto-cancel when completion >= this value.
                Set to 0 (default) to disable.  Example: ``cancel_at_percent=50``
                cancels the print as soon as it reaches 50%.
        

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

Input Schema

NameRequiredDescriptionDefault
timeoutNoMaximum seconds to monitor (default 7200 = 2 hours). Default: 7200.
printer_nameNoTarget printer. Omit for the default printer.
save_to_diskNoSave snapshots as JPEG files to ``~/.kiln/timelapses/<watch_id>/`` and persist metadata to the database. Use ``list_snapshots`` to query saved frames after the print completes (default False). Default: false.
max_snapshotsNoReturn after this many snapshots (default 5). Default: 5.
poll_intervalNoSeconds between state polls (default 15). Default: 15.
stall_timeoutNoSeconds of zero progress before declaring stall (default 600 = 10 min). Set to 0 to disable stall detection. Default: 600.
cancel_at_percentNoAuto-cancel when completion >= this value. Set to 0 (default) to disable. Example: ``cancel_at_percent=50`` cancels the print as soon as it reaches 50%. Default: 0.0.
snapshot_intervalNoSeconds between snapshot captures (default 60). Default: 60.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • changedInput schema / properties / cancel_at_percent / description
      Previous value: -"Default: 0.0."New value: +"Auto-cancel when completion >= this value. Set to 0 (default) to disable.  Example: ``cancel_at_percent=50`` cancels the print as soon as it reaches 50%. Default: 0.0."
    • changedInput schema / properties / max_snapshots / description
      Previous value: -"Default: 5."New value: +"Return after this many snapshots (default 5). Default: 5."
    • changedInput schema / properties / poll_interval / description
      Previous value: -"Default: 15."New value: +"Seconds between state polls (default 15). Default: 15."
    • addedInput schema / properties / printer_name / description
      Added value: +"Target printer.  Omit for the default printer."
    • changedInput schema / properties / save_to_disk / description
      Previous value: -"Default: false."New value: +"Save snapshots as JPEG files to ``~/.kiln/timelapses/<watch_id>/`` and persist metadata to the database.  Use ``list_snapshots`` to query saved frames after the print completes (default False). Default: false."
    • changedInput schema / properties / snapshot_interval / description
      Previous value: -"Default: 60."New value: +"Seconds between snapshot captures (default 60). Default: 60."
    • changedInput schema / properties / stall_timeout / description
      Previous value: -"Default: 600."New value: +"Seconds of zero progress before declaring stall (default 600 = 10 min).  Set to 0 to disable stall detection. Default: 600."
    • changedInput schema / properties / timeout / description
      Previous value: -"Default: 7200."New value: +"Maximum seconds to monitor (default 7200 = 2 hours). Default: 7200."
  2. Changed15 schema fields changedv1.5.0
    • removedInput schema / properties / cancel_at_percent / default
      Removed value: -0
    • addedInput schema / properties / cancel_at_percent / description
      Added value: +"Default: 0.0."
    • removedInput schema / properties / max_snapshots / default
      Removed value: -5
    • addedInput schema / properties / max_snapshots / description
      Added value: +"Default: 5."
    • removedInput schema / properties / poll_interval / default
      Removed value: -15
    • addedInput schema / properties / poll_interval / description
      Added value: +"Default: 15."
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / save_to_disk / default
      Removed value: -false
    • addedInput schema / properties / save_to_disk / description
      Added value: +"Default: false."
    • removedInput schema / properties / snapshot_interval / default
      Removed value: -60
    • addedInput schema / properties / snapshot_interval / description
      Added value: +"Default: 60."
    • removedInput schema / properties / stall_timeout / default
      Removed value: -600
    • addedInput schema / properties / stall_timeout / description
      Added value: +"Default: 600."
    • removedInput schema / properties / timeout / default
      Removed value: -7200
    • addedInput schema / properties / timeout / description
      Added value: +"Default: 7200."
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing that a background thread is spawned, that the call returns immediately, the five termination conditions, the auto-cancel behavior, and the camera-hash telemetry_mismatch fallback. The destructiveHint=true is substantiated by the cancel_at_percent explanation. It does not cover permission or locking requirements, which is the main remaining gap.

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-loads the core behavior and uses a numbered list for termination conditions, which is easy to scan. The trailing Args block duplicates the fully-covered schema and accounts for a meaningful share of the length, so it is not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 does the needed work: it states the returned watch_id and describes notable outcomes such as hardware_stop and telemetry_mismatch. One gap is that stall_timeout is documented as a parameter but the stall condition is omitted from the numbered list of ways the watcher finishes.

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 baseline is 3. The Args block largely restates the schema verbatim; the only added meaning is tying poll_interval and snapshot_interval to the background polling/snapshot loop and giving a use case for cancel_at_percent. That is marginal value over structured data.

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 and resource ('Start background monitoring of an in-progress print') and immediately names the companion tools watch_print_status and stop_watch_print, so an agent can distinguish it from siblings like monitor_print or await_print_completion.

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?

Explains the operating context clearly: it returns immediately with a watch_id rather than blocking, and it names the follow-up tools. It also gives a concrete use case for cancel_at_percent (test prints, calibration runs). It stops short of explicitly contrasting itself with monitor_print, monitor_print_vision, or await_print_completion, so the when-not guidance is inferred rather than stated.

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