Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

firmware_resume_print

Destructive

Resume failed or power-interrupted OctoPrint+Marlin prints by restoring the last checkpoint, repositioning the printer, and preparing it to continue from the saved layer.

Instructions

Execute firmware-level print resume for OctoPrint+Marlin printers.

After a power loss or failure, this tool positions the printer at the
last known checkpoint and prepares it to resume printing. Uses Marlin
M413 power-loss recovery protocol: homes X/Y (never Z), re-heats bed
then hotend, sets Z position from checkpoint, primes the nozzle, and
restores fan/flow settings.  A Kiln Pro feature.  Without it, the printer's own power-loss
recovery can continue a print run from its own memory card; a print
OctoPrint streamed over USB cannot be continued by the printer itself.

The printer will be positioned and ready after this call. Use
start_print with a re-sliced file (starting at the target layer) or
let the printer resume from its own recovery buffer.

Only works with OctoPrint printers running Marlin firmware. Moonraker/Klipper
printers should use Klipper's SAVE_VARIABLE system instead (not yet supported).

Args:
    printer_name: Name of the printer to resume on.
    job_id: The failed job's identifier (for checkpoint lookup).
    z_height_mm: Z height to resume from (from checkpoint).
    hotend_temp_c: Hotend temperature to restore.
    bed_temp_c: Bed temperature to restore.
    file_name: Original file name (for logging/tracking).
    layer_number: Layer number to resume from (informational).
    fan_speed_pct: Fan speed to restore (0-100).
    flow_rate_pct: Flow rate multiplier to restore (default 100).
    prime_length_mm: Filament to extrude for nozzle priming (mm).
    z_clearance_mm: How far above the part to raise the nozzle (mm).

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>",
      "job_id": "<job_id>",
      "z_height_mm": "<z_height_mm>",
      "hotend_temp_c": "<hotend_temp_c>",
      "bed_temp_c": "<bed_temp_c>",
      "file_name": "<file_name>"
    },
    "name": "firmware_resume_print"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idYesThe failed job's identifier (for checkpoint lookup).
file_nameYesOriginal file name (for logging/tracking).
bed_temp_cYesBed temperature to restore.
z_height_mmYesZ height to resume from (from checkpoint).
layer_numberNoLayer number to resume from (informational).
printer_nameYesName of the printer to resume on.
fan_speed_pctNoFan speed to restore (0-100). Default: 100.0.
flow_rate_pctNoFlow rate multiplier to restore (default 100). Default: 100.0.
hotend_temp_cYesHotend temperature to restore.
z_clearance_mmNoHow far above the part to raise the nozzle (mm). Default: 2.0.
prime_length_mmNoFilament to extrude for nozzle priming (mm). Default: 30.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.5.1
    • addedInput schema / properties / bed_temp_c / description
      Added value: +"Bed temperature to restore."
    • changedInput schema / properties / fan_speed_pct / description
      Previous value: -"Default: 100.0."New value: +"Fan speed to restore (0-100). Default: 100.0."
    • addedInput schema / properties / file_name / description
      Added value: +"Original file name (for logging/tracking)."
    • changedInput schema / properties / flow_rate_pct / description
      Previous value: -"Default: 100.0."New value: +"Flow rate multiplier to restore (default 100). Default: 100.0."
    • addedInput schema / properties / hotend_temp_c / description
      Added value: +"Hotend temperature to restore."
    • addedInput schema / properties / job_id / description
      Added value: +"The failed job's identifier (for checkpoint lookup)."
    • addedInput schema / properties / layer_number / description
      Added value: +"Layer number to resume from (informational)."
    • changedInput schema / properties / prime_length_mm / description
      Previous value: -"Default: 30.0."New value: +"Filament to extrude for nozzle priming (mm). Default: 30.0."
    • addedInput schema / properties / printer_name / description
      Added value: +"Name of the printer to resume on."
    • changedInput schema / properties / z_clearance_mm / description
      Previous value: -"Default: 2.0."New value: +"How far above the part to raise the nozzle (mm). Default: 2.0."
    • addedInput schema / properties / z_height_mm / description
      Added value: +"Z height to resume from (from checkpoint)."
  2. Changed9 schema fields changedv1.5.0
    • removedInput schema / properties / fan_speed_pct / default
      Removed value: -100
    • addedInput schema / properties / fan_speed_pct / description
      Added value: +"Default: 100.0."
    • removedInput schema / properties / flow_rate_pct / default
      Removed value: -100
    • addedInput schema / properties / flow_rate_pct / description
      Added value: +"Default: 100.0."
    • removedInput schema / properties / layer_number / default
      Removed value: -null
    • removedInput schema / properties / prime_length_mm / default
      Removed value: -30
    • addedInput schema / properties / prime_length_mm / description
      Added value: +"Default: 30.0."
    • removedInput schema / properties / z_clearance_mm / default
      Removed value: -2
    • addedInput schema / properties / z_clearance_mm / description
      Added value: +"Default: 2.0."
  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?

The annotations already declare destructiveHint=true and non-read-only, and the description adds real physical detail: homes X/Y but never Z, re-heats bed then hotend, sets Z from checkpoint, extrudes priming filament, restores fan/flow. It also reveals the post-call device state ('positioned and ready'). It does not cover permissions, failure/idle preconditions, or how a bad checkpoint is handled, so it stops short of 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and protocol, then constraints, then follow-up actions — a sensible ordering. It is somewhat padded by the duplicated Args list and the marketing line 'A Kiln Pro feature.', but nothing is actively confusing.

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?

For a destructive, hardware-moving, 11-parameter tool with no output schema, the description covers the physical sequence, device constraints, and the next step an agent should take. Remaining gaps are preconditions (printer must be idle, checkpoint must exist — presumably from save_print_checkpoint) and error behavior, which are not addressed.

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 schema already documents all 11 parameters, including defaults for fan_speed_pct, flow_rate_pct, z_clearance_mm, and prime_length_mm. The description's Args block is a near-verbatim restatement of those schema descriptions, adding essentially no new meaning such as valid ranges, units for each, or how z_height_mm interacts with z_clearance_mm.

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 ('execute firmware-level print resume') and immediately bounds it to 'OctoPrint+Marlin printers'. This distinguishes it from the many nearby resume/recovery siblings (resume_print, start_print_recovery, recover_power_loss_print).

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 ('after a power loss or failure'), explicit when-not (Moonraker/Klipper, which should use SAVE_VARIABLE), and explicit follow-up alternatives ('use start_print with a re-sliced file or let the printer resume from its own recovery buffer'). It also explains why the tool is needed for USB-streamed prints.

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