Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

check_power_loss_recovery

Read-only

Assess and plan a safe resume for a 3D print interrupted by power loss, checking a confirmed bare probe spot when needed to generate a recovery contract.

Instructions

Assess how to recover an interrupted print after a power loss (Pro).

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_power_loss_recovery"
  }
}

Input Schema

NameRequiredDescriptionDefault
probe_xyNo``[x, y]`` of a confirmed-bare patch of bed, in machine coordinates. Omit for an assessment-only call.
failure_idNoOptional recorded print failure whose original G-code Kiln looks up, so the Klipper probe path can suggest a bare spot. Ignored when ``gcode_path`` is given; an unknown id simply skips the suggestion. Default: "".
gcode_pathNoOptional path to the interrupted print's G-code, used the same way and taking precedence over ``failure_id``. Default: "".
print_bboxNoOptional declared part bbox for a fast pre-check; the resume generator derives the real footprint from the G-code regardless, so this is rarely needed.
printer_nameNoRegistered printer to assess. Empty = your only registered printer; with several, pass a name. Default: "".
bare_confirmedNoMust be True (with ``probe_xy``) to get a contract — your attestation the patch is physically empty. Default: false.
moonraker_configNoOptional pre-fetched ``configfile.config`` dict (``GET /printer/objects/query?configfile``). Supply it when the server can't reach the printer's Moonraker directly (e.g. the hosted API) — the client fetches, the server plans.
probe_clearance_mmNoMin margin the probe must clear the print by. Default: 5.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • changedInput schema / properties / bare_confirmed / description
      Previous value: -"Default: false."New value: +"Must be True (with ``probe_xy``) to get a contract — your attestation the patch is physically empty. Default: false."
    • changedInput schema / properties / failure_id / description
      Previous value: -"Default: \"\"."New value: +"Optional recorded print failure whose original G-code Kiln looks up, so the Klipper probe path can suggest a bare spot. Ignored when ``gcode_path`` is given; an unknown id simply skips the suggestion. Default: \"\"."
    • changedInput schema / properties / gcode_path / description
      Previous value: -"Default: \"\"."New value: +"Optional path to the interrupted print's G-code, used the same way and taking precedence over ``failure_id``. Default: \"\"."
    • addedInput schema / properties / moonraker_config / description
      Added value: +"Optional pre-fetched ``configfile.config`` dict (``GET /printer/objects/query?configfile``).  Supply it when the server can't reach the printer's Moonraker directly (e.g. the hosted API) — the client fetches, the server plans."
    • addedInput schema / properties / print_bbox / description
      Added value: +"Optional declared part bbox for a fast pre-check; the resume generator derives the real footprint from the G-code regardless, so this is rarely needed."
    • changedInput schema / properties / printer_name / description
      Previous value: -"Default: \"\"."New value: +"Registered printer to assess.  Empty = your only registered printer; with several, pass a name. 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, in machine coordinates.  Omit for an assessment-only call."
  2. Addedv1.5.0

TDQS

C2.8/5.0
Behavior3/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 adds one genuinely useful behavioural fact beyond that: the '(Pro)' tier requirement. It does not disclose the two-mode behaviour (assessment-only vs. contract issuance) or the precondition that a confirmed-bare probe point is needed, leaving the agent to infer that from parameters.

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?

A single front-loaded sentence with no filler, and the key qualifier '(Pro)' is placed where it will be seen. The trade-off is that brevity here shades into under-specification rather than true economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex 8-parameter tool with a nested object and no output schema, so the description carries more burden than usual. It never says what the assessment returns — a verdict, a suggested bare spot, a recovery contract — nor what the prerequisite flow is. For a no-output-schema tool, that omission is a real gap for an agent deciding whether to call it.

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 every parameter is already documented with meaningful text, including probe_xy, bare_confirmed, moonraker_config, and failure_id precedence rules. The description adds no syntax, defaults, or interpretation beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose3/5

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

The description states a verb and resource ('Assess how to recover an interrupted print after a power loss'), which is more specific than a tautology. However, with siblings such as recover_power_loss_print, resume_interrupted_print, plan_print_recovery, assess_fleet_power_loss, and generate_recovery_gcode, it gives no signal about how this 'assessment' differs from those. An agent cannot reliably pick this tool over its near-neighbours from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives. The important branching the schema implies — assessment-only call versus a full contract requiring probe_xy plus bare_confirmed — is never surfaced as a usage rule. The only implied cue is the '(Pro)' tag, which signals a tier gate rather than usage context.

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