Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

check_print_health

Read-only

Run a single-cycle health check of the current 3D print to verify printer connectivity, temperatures, progress, and error states; optionally assess adhesion risk from the model.

Instructions

Perform a single-shot health assessment of the current print.

        Unlike ``watch_print`` (which starts a background monitoring
        thread), this tool runs one check cycle and returns immediately.
        It is designed for quick "is the print OK right now?" queries
        from an agent without starting persistent background tasks.

        Checks performed:

        * **Printer connectivity** — is the printer online?
        * **Temperature** — are hot-end and bed within 15 °C of target?
        * **Print progress** — current completion, layer count, ETA.
        * **Error state** — any active firmware error codes.

        If *model_path* is supplied, adhesion risk is also evaluated via
        ``analyze_printability``.

        Args:
            printer_name: Named printer to query.  Omit for the default.
            model_path: Optional path to the model being printed.
                Enables geometry-based adhesion risk analysis.
            material: Filament material (e.g. ``"PLA"``, ``"ABS"``).
                Passed to adhesion analysis when *model_path* is provided.
            printer_id: Printer model ID (e.g. ``"bambu_a1"``).
                Used for printer-intelligence lookups.

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

Input Schema

NameRequiredDescriptionDefault
materialNoFilament material (e.g. ``"PLA"``, ``"ABS"``). Passed to adhesion analysis when *model_path* is provided.
model_pathNoOptional path to the model being printed. Enables geometry-based adhesion risk analysis.
printer_idNoPrinter model ID (e.g. ``"bambu_a1"``). Used for printer-intelligence lookups.
printer_nameNoNamed printer to query. Omit for the default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / material / description
      Added value: +"Filament material (e.g. ``\"PLA\"``, ``\"ABS\"``). Passed to adhesion analysis when *model_path* is provided."
    • addedInput schema / properties / model_path / description
      Added value: +"Optional path to the model being printed. Enables geometry-based adhesion risk analysis."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer model ID (e.g. ``\"bambu_a1\"``). Used for printer-intelligence lookups."
    • addedInput schema / properties / printer_name / description
      Added value: +"Named printer to query.  Omit for the default."
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / material / default
      Removed value: -null
    • removedInput schema / properties / model_path / default
      Removed value: -null
    • removedInput schema / properties / printer_id / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description goes well beyond that by enumerating exactly what is checked (connectivity, temperature within 15 °C of target, progress/layer/ETA, firmware error codes) and that it returns immediately rather than spawning a thread. It also discloses the conditional side effect of triggering analyze_printability adhesion analysis when model_path is given, which is not inferable from annotations.

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 leading paragraphs are front-loaded and earn their place, but the trailing 'Args:' block duplicates, nearly word for word, four parameter descriptions already at 100% schema coverage. Combined with docstring-style indentation artifacts and bolded inline markup, a meaningful fraction of the text is redundant or noisy.

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?

There is no output schema, so the description usefully serves as the return contract via the 'Checks performed' list, and the 15 °C threshold gives an agent concrete evaluation criteria. It stops short of describing how failures are reported (e.g., what a result looks like when the printer is offline or a firmware error is active), which would fully close the gap.

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 parameter text in the description is essentially a verbatim restatement of the schema's own descriptions. The only marginally additive point is the coupling note that material feeds adhesion analysis when model_path is set, which the schema already states. Baseline 3 applies since the schema carries the parameter burden.

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 ('single-shot health assessment of the current print') and immediately distinguishes itself from the closest sibling by naming 'watch_print' and the background-thread behavior it avoids. An agent can select this over watch_print without reading either schema.

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?

Explicitly frames the use case ('quick "is the print OK right now?" queries ... without starting persistent background tasks') and explains the conditional path when model_path is supplied. It does not mention other plausible near-neighbors present in the sibling list such as check_printer_health, printer_status, or preflight_check, so the routing guidance is clear but not exhaustive.

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