Kiln

Overview Schema Source Related Servers Discussions Admin

preflight_check

Read-only

Run pre-print safety checks on a 3D printer to confirm it is idle, error-free, at safe temperatures, and holds the expected material or file before starting a print.

Instructions

Run pre-print safety checks to verify the printer is ready.

Checks performed:
- Printer is connected and operational
- Printer is not currently printing
- No error flags are set
- Temperatures are within safe limits
- (Optional) Material loaded matches expected material
- (Optional) Local G-code file is valid and readable
- (Optional) Remote file exists on the printer
- (Optional) For a model file (STL, OBJ, 3MF, STEP, GLB), whether the
  part prints: this fails exactly where the print door would refuse the
  file, and passes wherever the door would print it.
- Multi-material: what unit the printer carries (AMS, a Klipper MMU)
  and, with ``file_path``, whether the file's filaments are loaded.
  Advisory for a unit Kiln drives (the print gate decides at start);
  a FAILURE when a multi-filament file needs more colours than a
  unit Kiln does not drive has loaded — that print comes out wrong
  and nothing downstream stops it.  Absent for a single-feed printer;
  a read that failed is reported as such, never as "no unit".

Args:
    file_path: Optional path to a local print file (``.gcode``,
        ``.gco``, ``.g`` or ``.3mf``) to validate before upload; a model
        file (STL, OBJ, STEP) fails the ``file_valid`` check.  If
        omitted, only printer-state checks are performed.
    expected_material: Optional material type (e.g. "PLA", "ABS", "PETG").
        If provided and a material is loaded, checks for a mismatch.

    remote_file: Optional filename to verify exists on the printer.
        If provided, checks the printer's file list for a matching file.
    accept_paused: When ``True``, the ``printer_idle`` check accepts
        the ``paused`` state in addition to ``idle``.  Used by
        ``start_print(resume_from_paused=True)`` for mid-print
        resume 3MFs (which start from a paused-state printer).
        Default ``False`` — only ``idle`` is accepted.
    start_door_gates_plate: Set by Kiln's own start doors, which judge
        the plate themselves (with the resume and print-beside-a-part
        exceptions) before they run this check.  Leave it unset: then
        this check asks the plate question a start would, so it is
        answered before the start instead of as a refusal after it.
    printer_name: Which printer to check.  Omit for the default
        printer.
        The state, the temperature ceilings and the material profile
        all follow the named machine — a readiness verdict is about
        one printer, and it has to be the printer that will print.

Call this before ``start_print()`` to catch problems early.  The result
includes a ``ready`` boolean and detailed per-check breakdowns.

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

Input Schema

Name	Required	Description
`file_path`	No	Optional path to a local print file (``.gcode``, ``.gco``, ``.g`` or ``.3mf``) to validate before upload; a model file (STL, OBJ, STEP) fails the ``file_valid`` check. If omitted, only printer-state checks are performed.
`remote_file`	No	Optional filename to verify exists on the printer. If provided, checks the printer's file list for a matching file.
`printer_name`	No	Which printer to check. Omit for the default printer. The state, the temperature ceilings and the material profile all follow the named machine — a readiness verdict is about one printer, and it has to be the printer that will print.
`accept_paused`	No	When ``True``, the ``printer_idle`` check accepts the ``paused`` state in addition to ``idle``. Used by ``start_print(resume_from_paused=True)`` for mid-print resume 3MFs (which start from a paused-state printer). Default ``False`` — only ``idle`` is accepted. Default: false.
`expected_material`	No	Optional material type (e.g. "PLA", "ABS", "PETG"). If provided and a material is loaded, checks for a mismatch.
`start_door_gates_plate`	No	Set by Kiln's own start doors, which judge the plate themselves (with the resume and print-beside-a-part exceptions) before they run this check. Leave it unset: then this check asks the plate question a start would, so it is answered before the start instead of as a refusal after it. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.5.1Nov 5, 2026

changedInput schema / properties / accept_paused / description

Previous value: -"Default: false."New value: +"When ``True``, the ``printer_idle`` check accepts the ``paused`` state in addition to ``idle``.  Used by ``start_print(resume_from_paused=True)`` for mid-print resume 3MFs (which start from a paused-state printer). Default ``False`` — only ``idle`` is accepted. Default: false."

addedInput schema / properties / expected_material / description

Added value: +"Optional material type (e.g. \"PLA\", \"ABS\", \"PETG\"). If provided and a material is loaded, checks for a mismatch."

addedInput schema / properties / file_path / description

Added value: +"Optional path to a local print file (``.gcode``, ``.gco``, ``.g`` or ``.3mf``) to validate before upload; a model file (STL, OBJ, STEP) fails the ``file_valid`` check.  If omitted, only printer-state checks are performed."

addedInput schema / properties / printer_name / description

Added value: +"Which printer to check.  Omit for the default printer. The state, the temperature ceilings and the material profile all follow the named machine — a readiness verdict is about one printer, and it has to be the printer that will print."

addedInput schema / properties / remote_file / description

Added value: +"Optional filename to verify exists on the printer. If provided, checks the printer's file list for a matching file."

addedInput schema / properties / start_door_gates_plate

Added value: +{
+  "description": "Set by Kiln's own start doors, which judge the plate themselves (with the resume and print-beside-a-part exceptions) before they run this check.  Leave it unset: then this check asks the plate question a start would, so it is answered before the start instead of as a refusal after it. Default: false.",
+  "title": "Start Door Gates Plate",
+  "type": "boolean"
+}

Changed6 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / accept_paused / default
```
Removed value: -false
```
- addedInput schema / properties / accept_paused / description
```
Added value: +"Default: false."
```
- removedInput schema / properties / expected_material / default
```
Removed value: -null
```
- removedInput schema / properties / file_path / default
```
Removed value: -null
```
- removedInput schema / properties / printer_name / default
```
Removed value: -null
```
- removedInput schema / properties / remote_file / default
```
Removed value: -null
```

Changed1 schema field changedv1.3.1Aug 19, 2026

addedInput schema / properties / printer_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Printer Name"
+}

First observedv0.1.0Jul 4, 2026

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 and destructiveHint=false, and the description still adds substantial behavioral context: the full check inventory, the distinction between advisory and hard-failing multi-material outcomes ('a FAILURE when a multi-filament file needs more colours than a unit Kiln does not drive has loaded'), and the guarantee that a failed read is reported as such rather than as 'no unit'. That is real disclosure beyond the annotations, not restatement.

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 purpose and check list are front-loaded, which is good, but the Args block largely duplicates the input schema descriptions verbatim, and the multi-material bullet sprawls across several dense sentences about Kiln-driven units. It is well organized yet noticeably longer than a preflight check needs to be.

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?

For a six-parameter read-only tool with no output schema, the description covers everything an agent needs: what is checked, what the optional parameters change, what the result contains ('a ready boolean and detailed per-check breakdowns'), and when to invoke it relative to start_print. Nothing material is missing.

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, but the description adds genuine semantics: accept_paused is tied to start_print(resume_from_paused=True), start_door_gates_plate carries an explicit 'leave it unset' instruction, and printer_name explains that state, temperature ceilings, and material profile all follow the named machine. Much of the Args text is mirrored in the schema descriptions, which limits the added value somewhat.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Run pre-print safety checks to verify the printer is ready') and then enumerates the exact checks performed, so an agent knows precisely what it does. What keeps it from a 5 is that it never distinguishes itself from close siblings such as check_print_readiness, may_i_print, or validate_gcode, leaving the agent to infer the boundary.

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?

It gives a clear call site: 'Call this before start_print() to catch problems early', and it explains the narrow conditions under which accept_paused (mid-print resume 3MFs) and start_door_gates_plate (internal start doors) apply. It offers no explicit when-not-to-use guidance or named alternative tools, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server