Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

start_printer_health_monitoring

Destructive

Start continuous background health checks for a printer to detect connectivity, temperature, job progress, and error issues, and receive alerts when anomalies occur.

Instructions

Start continuous background health monitoring for a printer.

Runs periodic checks covering connectivity, temperature stability,
print job health (layer progress stalls, error codes), and active
error detection.  Alerts are generated when anomalies are found.

Kiln keeps a live watch on as many machines at once as your plan
runs — one on Free and Pro.  Checking a printer yourself is not a
watch and is never limited: ``printer_status``, ``monitor_print``
and ``printer_snapshot`` answer for any machine at any tier, and so
does stopping one.

:param printer_name: Printer to monitor.
:param interval_seconds: Seconds between health checks (default 30).

See also: ``stop_printer_health_monitoring()``,
``check_printer_health()``, ``printer_status()``.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "printer_name": "<printer_name>"
    },
    "name": "start_printer_health_monitoring"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_nameYesPrinter to monitor.
interval_secondsNoSeconds between health checks (default 30). Default: 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / interval_seconds / description
      Previous value: -"Default: 30."New value: +"Seconds between health checks (default 30). Default: 30."
    • addedInput schema / properties / printer_name / description
      Added value: +"Printer to monitor."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / interval_seconds / default
      Removed value: -30
    • addedInput schema / properties / interval_seconds / description
      Added value: +"Default: 30."
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Adds real context beyond the annotations: periodic checks generate alerts on anomalies, and a persistent watch consumes a limited per-plan slot while ad-hoc status checks do not. It does not explain how alerts are delivered, what the immediate response is, or why the destructiveHint=true annotation applies (e.g. whether starting a watch displaces an existing one), so a small gap remains.

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 action and monitored signals, then moves to quota constraints and alternatives. The :param lines and See-also list duplicate schema and sibling data, adding some redundancy, but the total length stays reasonable for a tool with quota implications.

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?

Covers what the watch does, what triggers alerts, plan limits, and the stopping path, which is sufficient for a mutation tool with no output schema. Missing only operational detail on how alerts surface and what the call returns immediately.

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 coverage is 100%, so both parameters are already documented, and the description's :param lines simply restate the schema text verbatim with the same default of 30 seconds. No additional meaning such as acceptable ranges or interval trade-offs is offered.

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?

States a specific verb and resource ("Start continuous background health monitoring for a printer") and then enumerates exactly what is monitored: connectivity, temperature stability, layer progress stalls, error codes. That specificity separates it from one-shot siblings like check_printer_health or printer_status.

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?

Explicitly frames the tool as an ongoing watch that consumes a plan slot, and contrasts it with ad-hoc checks ("Checking a printer yourself is not a watch and is never limited: printer_status, monitor_print and printer_snapshot..."). It also names the paired stop tool, so the when-to-use and when-not-to-use boundaries are both clear.

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