Kiln

Overview Schema Source Related Servers Discussions Admin

get_recovery_plan

Read-only

Get a step-by-step recovery plan for a specific 3D printer failure, tailored to the affected printer and its power-loss and filament-sensor capabilities.

Instructions

Get a recovery plan for a specific failure type.

        Args:
            failure_type: One of: spaghetti, layer_shift, adhesion_loss,
                nozzle_clog, stringing, thermal_runaway, power_loss,
                filament_runout, warping, unknown.
            printer_name: Name of the affected printer.
            has_power_loss_recovery: Whether the printer supports
                power-loss recovery.
            has_filament_sensor: Whether the printer has a filament
                runout sensor.

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": {
      "failure_type": "<failure_type>"
    },
    "name": "get_recovery_plan"
  }
}

Input Schema

Name	Required	Description
`failure_type`	Yes	One of: spaghetti, layer_shift, adhesion_loss, nozzle_clog, stringing, thermal_runaway, power_loss, filament_runout, warping, unknown.
`printer_name`	No	Name of the affected printer.
`has_filament_sensor`	No	Whether the printer has a filament runout sensor. Default: false.
`has_power_loss_recovery`	No	Whether the printer supports power-loss recovery. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.5.1Nov 5, 2026

addedInput schema / properties / failure_type / description

Added value: +"One of: spaghetti, layer_shift, adhesion_loss, nozzle_clog, stringing, thermal_runaway, power_loss, filament_runout, warping, unknown."

changedInput schema / properties / has_filament_sensor / description

Previous value: -"Default: false."New value: +"Whether the printer has a filament runout sensor. Default: false."

changedInput schema / properties / has_power_loss_recovery / description

Previous value: -"Default: false."New value: +"Whether the printer supports power-loss recovery. Default: false."

addedInput schema / properties / printer_name / description
```
Added value: +"Name of the affected printer."
```

Changed5 schema fields changedv1.5.0Oct 23, 2026
- removedInput schema / properties / has_filament_sensor / default
```
Removed value: -false
```
- addedInput schema / properties / has_filament_sensor / description
```
Added value: +"Default: false."
```
- removedInput schema / properties / has_power_loss_recovery / default
```
Removed value: -false
```
- addedInput schema / properties / has_power_loss_recovery / description
```
Added value: +"Default: false."
```
- removedInput schema / properties / printer_name / default
```
Removed value: -null
```
First observedv0.1.0Jul 4, 2026

TDQS

C2.9/5.0

Behavior2/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 by structured data. The description adds nothing beyond that — it does not say whether the plan is a static lookup table or computed from printer capabilities, nor what the plan contains, which is the main behavioral question for a 'get a plan' tool.

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 opening sentence is front-loaded and efficient, but the four-entry Args block restates the input schema word-for-word and consumes most of the description's length without adding information. Roughly half the text is redundant boilerplate.

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

Completeness3/5

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

This is a simple read-only lookup with no output schema, so the description should at least indicate what a 'recovery plan' is (steps, gcode, recommendations) to let the agent decide whether to call it. It is minimally adequate for a four-parameter tool but leaves the return value entirely opaque.

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 four parameters, including the enumerated failure types and the default-false booleans. The description's Args block repeats that text nearly verbatim and adds no new meaning, so the baseline of 3 applies.

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 states a clear verb and resource ('Get a recovery plan') plus a scope ('for a specific failure type'), so the agent knows exactly what is returned in kind. It does not, however, distinguish this from close siblings such as plan_failure_recovery, get_recovery_recommendations, or plan_print_recovery, which an agent could easily confuse it with.

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 statement of when to use this versus the many other recovery-related siblings, no prerequisites, and no exclusions. The only usage signal is the implied 'call it when you have a failure type', which is derivable from the required parameter alone.

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

Deploy Server