Skip to main content
Glama

monitor_print_vision

Destructive

Captures a webcam snapshot and structured print metadata for AI visual inspection, helping detect failures and optionally auto-pause an in-progress 3D print.

Instructions

Snapshot + structured data for AI visual inspection of an in-progress print.

        Use when analyzing camera images for print failures. Returns webcam image
        (base64 or saved file) alongside structured metadata (temps, progress,
        phase, cost estimate, failure hints). Can auto-pause on detected issues.
        For a quick text status report, use ``monitor_print`` instead.
        For persistent background monitoring, use ``watch_print``.

        Args:
            printer_name: Target printer.  Omit for the default printer.
            include_snapshot: Whether to capture a webcam snapshot (default True).
            save_snapshot: Optional path to save the snapshot image.
            failure_type: Optional detected failure type (e.g. "spaghetti",
                "layer_shift", "warping").  Reported by the agent after visual
                inspection of a previous snapshot.
            failure_confidence: Confidence score (0.0-1.0) of the failure detection.
            auto_pause: If True, pause the print when the reported
                ``failure_confidence`` is high enough; the reply says
                whether it did.  Defaults to the ``KILN_VISION_AUTO_PAUSE``
                environment variable (off).
            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.  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_vision"
  }
}

Input Schema

NameRequiredDescriptionDefault
auto_pauseNoIf True, pause the print when the reported ``failure_confidence`` is high enough; the reply says whether it did. Defaults to the ``KILN_VISION_AUTO_PAUSE`` environment variable (off).
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. Read by the inline monitor's result hook (``kiln.local_monitor``), not here. Default: false.
failure_typeNoOptional detected failure type (e.g. "spaghetti", "layer_shift", "warping"). Reported by the agent after visual inspection of a previous snapshot.
printer_nameNoTarget printer. Omit for the default printer.
save_snapshotNoOptional path to save the snapshot image.
include_snapshotNoWhether to capture a webcam snapshot (default True). Default: true.
failure_confidenceNoConfidence score (0.0-1.0) of the failure detection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • addedInput schema / properties / auto_pause / description
      Added value: +"If True, pause the print when the reported ``failure_confidence`` is high enough; the reply says whether it did.  Defaults to the ``KILN_VISION_AUTO_PAUSE`` environment variable (off)."
    • addedInput schema / properties / failure_confidence / description
      Added value: +"Confidence score (0.0-1.0) of the failure detection."
    • addedInput schema / properties / failure_type / description
      Added value: +"Optional detected failure type (e.g. \"spaghetti\", \"layer_shift\", \"warping\").  Reported by the agent after visual inspection of a previous snapshot."
    • changedInput schema / properties / include_snapshot / description
      Previous value: -"Default: true."New value: +"Whether to capture a webcam snapshot (default True). Default: true."
    • addedInput schema / properties / printer_name / description
      Added value: +"Target printer.  Omit for the default printer."
    • addedInput schema / properties / save_snapshot / description
      Added value: +"Optional path to save the snapshot image."
    • 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.  Read by the inline monitor's result hook (``kiln.local_monitor``), not here. Default: false."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / auto_pause / default
      Removed value: -null
    • removedInput schema / properties / failure_confidence / default
      Removed value: -null
    • removedInput schema / properties / failure_type / default
      Removed value: -null
    • 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
    • removedInput schema / properties / save_snapshot / 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.5/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description explains the mechanism behind that ('Can auto-pause on detected issues') and the env-var default for auto_pause, so it adds context rather than contradicting. It also discloses non-obvious behavior — repeat calls while the panel is live return a text report plus a card, not a second panel, and the feature is 'free with a Kiln sign-in'. It stops short of stating what else a paused print affects, so not a 5.

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 lead sentence and the sibling routing are well front-loaded, but the 'Args:' block restates all seven parameters that already have 100% schema coverage, and the inline-live-monitor paragraph runs long on caveats. Real information is present, yet a meaningful share is duplication.

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, so the description carries the return contract and does so concretely (webcam image as base64 or saved file, plus temps, progress, phase, cost estimate, failure hints). Panel-state semantics, auto-pause defaults, and the refresh path via printer_status/first_layer_status are all covered for a complex 7-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes past that by framing failure_type as 'reported by the agent after visual inspection of a previous snapshot' (establishing the two-step inspect-then-report flow) and by linking failure_confidence to auto_pause's trigger, which the schema does not connect.

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 ('Snapshot + structured data for AI visual inspection of an in-progress print') and immediately names the two siblings it is not — 'monitor_print' for a text status report and 'watch_print' for persistent background monitoring — so an agent can route 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?

Explicit when-to-use ('Use when analyzing camera images for print failures'), explicit when-not ('For a quick text status report, use monitor_print instead', 'For persistent background monitoring, use watch_print'), plus a conditional instruction for show_panel ('Pass only when the person asks to see the panel again'). It even covers anti-use: 'do not call this tool again to refresh it'.

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