Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

recover_power_loss_print

Destructive

Recover a 3D print interrupted by power loss by assessing the failure, confirming the bed area, and resuming from the failed layer with controlled actions.

Instructions

One-call power-loss recovery for the printer that lost power (Pro).

This tool may ask this computer to act on your printer (upload, start, pause, resume, set a speed preset). It first answers with the actions it wants and why, and runs nothing; call it again with run_actions set to the actions_digest it answered with to carry out exactly those actions through Kiln's own tools here, with every check those tools make.

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

Input Schema

NameRequiredDescriptionDefault
probe_xyNo``[x, y]`` of a confirmed-bare patch of bed. Omit to get the assessment instead of acting.
failure_idNoFrom ``detect_print_failure`` — required to actually resume a Klipper print (which print, which layer). Default: "".
gcode_pathNoThe sliced file that was printing, with ``failed_layer``: the other way to say which print and which layer to resume, and the only way through Kiln's servers, where a ``failure_id`` (a record on the computer attached to the printer) cannot be read. Default: "".
output_dirNoWhere to write the resume .gcode (default: temp). Default: "".
run_actionsNoLeave empty on the first call: the tool answers with the actions it wants and an actions_digest, and runs nothing. Call again with that digest here to carry out exactly those actions. Default: "".
failed_layerNoThe layer the print had reached when power was lost. Used with ``gcode_path``. Default: 0.
printer_nameNoThe printer that lost power. Empty = the sole registered printer. Default: "".
material_typeNoThe material, for the overlap the resume rewinds by (default PLA). Used with ``gcode_path``. Default: "PLA".
bare_confirmedNoMust be True (with ``probe_xy``) to act — your attestation the patch is physically empty. Default: false.
moonraker_configNoOptional pre-fetched ``configfile.config`` for the hosted path (server can't reach the LAN Moonraker).
prime_extrusion_mmNoExtruder prime length on resume. Default: 0.0.
probe_clearance_mmNoMin margin the probe must clear the print by. Default: 5.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.5.1
    • changedInput schema / properties / bare_confirmed / description
      Previous value: -"Default: false."New value: +"Must be True (with ``probe_xy``) to act — your attestation the patch is physically empty. Default: false."
    • changedInput schema / properties / failed_layer / description
      Previous value: -"Default: 0."New value: +"The layer the print had reached when power was lost.  Used with ``gcode_path``. Default: 0."
    • changedInput schema / properties / failure_id / description
      Previous value: -"Default: \"\"."New value: +"From ``detect_print_failure`` — required to actually resume a Klipper print (which print, which layer). Default: \"\"."
    • changedInput schema / properties / gcode_path / description
      Previous value: -"Default: \"\"."New value: +"The sliced file that was printing, with ``failed_layer``: the other way to say which print and which layer to resume, and the only way through Kiln's servers, where a ``failure_id`` (a record on the computer attached to the printer) cannot be read. Default: \"\"."
    • changedInput schema / properties / material_type / description
      Previous value: -"Default: \"PLA\"."New value: +"The material, for the overlap the resume rewinds by (default PLA).  Used with ``gcode_path``. Default: \"PLA\"."
    • addedInput schema / properties / moonraker_config / description
      Added value: +"Optional pre-fetched ``configfile.config`` for the hosted path (server can't reach the LAN Moonraker)."
    • changedInput schema / properties / output_dir / description
      Previous value: -"Default: \"\"."New value: +"Where to write the resume .gcode (default: temp). Default: \"\"."
    • changedInput schema / properties / prime_extrusion_mm / description
      Previous value: -"Default: 0.0."New value: +"Extruder prime length on resume. Default: 0.0."
    • changedInput schema / properties / printer_name / description
      Previous value: -"Default: \"\"."New value: +"The printer that lost power.  Empty = the sole registered printer. Default: \"\"."
    • changedInput schema / properties / probe_clearance_mm / description
      Previous value: -"Default: 5.0."New value: +"Min margin the probe must clear the print by. Default: 5.0."
    • addedInput schema / properties / probe_xy / description
      Added value: +"``[x, y]`` of a confirmed-bare patch of bed.  Omit to get the assessment instead of acting."
    • changedInput schema / properties / run_actions / description
      Previous value: -"Default: \"\"."New value: +"Leave empty on the first call: the tool answers with the actions it wants and an actions_digest, and runs nothing. Call again with that digest here to carry out exactly those actions. Default: \"\"."
  2. Addedv1.5.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds material context beyond that: the first call is a no-op planning phase, the second executes exactly the digested actions, and the possible action set (upload, start, pause, resume, set a speed preset) plus the fact that actions route through Kiln's own tools with their checks. That is real added behavior disclosure, though it omits risks of the destructive path and what the assessment response contains.

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?

Two sentences, front-loaded with the purpose and then the call protocol; nothing is wasted. The second sentence is long and clause-heavy, which slightly reduces scannability, but the content earns its place.

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 twelve-parameter destructive tool with no output schema, the description covers the essential thing an agent could not get from structured fields: that this is a two-phase propose-then-execute tool and how to complete the execution. The remaining parameter interdependencies are fully covered by the 100%-covered schema, so nothing critical is missing.

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 all twelve parameters are already documented, including the run_actions digest protocol. The description reinforces the digest round-trip, which is the most error-prone part of calling this tool, but adds nothing about probe_xy/bare_confirmed attesting a bare bed patch or the failure_id vs gcode_path+failed_layer alternative paths. Baseline 3 is appropriate.

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 names a specific verb and resource — one-call power-loss recovery for a printer that lost power — which is far more precise than a bare name restatement. It does not, however, name or distinguish itself from close siblings such as check_power_loss_recovery, generate_recovery_gcode, plan_print_recovery, or resume_interrupted_print, so an agent must 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear procedural when-to-use: call first with run_actions empty to get an assessment plus actions_digest, then re-call with that digest to execute. That is genuinely useful operational guidance. It stops short of saying when to prefer this tool over the sibling recovery tools (check_power_loss_recovery, generate_recovery_gcode, resume_print) or what prerequisites apply, so usage context is implied rather than fully specified.

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