Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

skip_print_objects

Destructive

Stop printing failed objects on a multi-object plate mid-print so the remaining parts finish. Pass the object IDs to abandon and save the rest of the run.

Instructions

Abandon one or more failed objects on a multi-object plate, mid-print.

When one part on a full plate fails — spaghetti, a knocked-loose object, a
detached corner — this tells the printer to stop printing just those
objects and finish the rest of the plate.  One bad part no longer scraps
the whole run.  A Kiln Pro feature.

The identifier is backend-specific — pass it as a string, Kiln routes it:

* **Bambu** — the ``label_id`` from ``list_plate_objects`` (e.g. ``"757"``).
* **Klipper / Moonraker / Creality** — the object NAME the slicer labelled
  (e.g. ``"Part1"``); the file must have been sliced with object labelling.
* **OctoPrint** — the zero-based ``M486`` object index (needs firmware
  M486 support).

Discover Bambu ids first::

    list_plate_objects("my_plate.gcode.3mf")   # -> objects[].label_id

Printer support (honest): Bambu and any Klipper/Moonraker printer can skip
(Voron, RatRig, Qidi, and Klipper-based Creality and Elegoo Neptune /
OrangeStorm); Marlin printers via OctoPrint or direct USB can if the
firmware speaks M486.  Prusa via Prusa Link can't be skipped remotely — an
API limitation, not the printer (it can cancel objects from its own
screen).  The Elegoo SDCP protocol (e.g. Centauri Carbon) has no skip
command.  A Klipper printer on a non-Klipper connection just needs
reconnecting as Moonraker.

AGENT DISPLAY CONTRACT: skipping is IRREVERSIBLE for the objects named —
confirm the exact objects with the user before calling, and only while a
multi-object plate is actively printing.  Skips are cumulative: an object
already skipped stays skipped.

Args:
    object_ids: Object identifiers to abandon, as strings: on Bambu the
        ``label_id`` from ``list_plate_objects`` (e.g. ``"757"``); on
        Klipper/Moonraker/Creality the object name the slicer labelled
        (e.g. ``"Part1"``); on OctoPrint the zero-based M486 object index.
    plate_number: Which plate the ids came from (1-based, default 1).
        Recorded for context; the ids are what the printer acts on.
    printer_name: Which printer is printing the plate.  Omit for the
        default printer.

Returns:
    Dict with the skipped objects and a confirmation message, or an error
    dict if no print is active or the printer can't skip objects.

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": {
      "object_ids": "<object_ids>"
    },
    "name": "skip_print_objects"
  }
}

Input Schema

NameRequiredDescriptionDefault
object_idsYesObject identifiers to abandon, as strings: on Bambu the ``label_id`` from ``list_plate_objects`` (e.g. ``"757"``); on Klipper/Moonraker/Creality the object name the slicer labelled (e.g. ``"Part1"``); on OctoPrint the zero-based M486 object index.
plate_numberNoWhich plate the ids came from (1-based, default 1). Recorded for context; the ids are what the printer acts on. Default: 1.
printer_nameNoWhich printer is printing the plate. Omit for the default printer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • addedInput schema / properties / object_ids / description
      Added value: +"Object identifiers to abandon, as strings: on Bambu the ``label_id`` from ``list_plate_objects`` (e.g. ``\"757\"``); on Klipper/Moonraker/Creality the object name the slicer labelled (e.g. ``\"Part1\"``); on OctoPrint the zero-based M486 object index."
    • changedInput schema / properties / plate_number / description
      Previous value: -"Default: 1."New value: +"Which plate the ids came from (1-based, default 1). Recorded for context; the ids are what the printer acts on. Default: 1."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer is printing the plate.  Omit for the default printer."
  2. Changed3 schema fields changedv1.5.0
    • removedInput schema / properties / plate_number / default
      Removed value: -1
    • addedInput schema / properties / plate_number / description
      Added value: +"Default: 1."
    • addedInput schema / properties / printer_name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Printer Name"
+}
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description goes well beyond that: it declares skipping IRREVERSIBLE for the named objects, notes that skips are cumulative, and enumerates per-backend support and failure modes (Prusa Link cannot skip remotely, SDCP has no skip command, non-Klipper connections need reconnecting as Moonraker). It also discloses the error case (error dict if no print is active or the printer can't skip).

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 the irreversibility contract are front-loaded, which is good, but the definition runs long and the Args/Returns block duplicates schema text that is already at 100% coverage. The printer-support paragraph is valuable but sprawling, and the padded 'Printer support (honest):' aside could be tightened without losing information.

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 destructive, backend-heterogeneous operation with no output schema, the description covers everything an agent needs: identifier semantics per backend, printer compatibility, irreversibility, cumulative behavior, and the return/error shape. Nothing essential to calling it correctly 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% and the Args block largely restates the schema descriptions verbatim, so the baseline is 3. It earns one extra point for adding routing context the schema lacks: the identifier is 'backend-specific' and Kiln dispatches it, plus the concrete discovery path via list_plate_objects, which tells the agent where the required object_ids value actually comes from.

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 opening sentence names a specific verb, resource and timing: 'Abandon one or more failed objects on a multi-object plate, mid-print,' and the follow-up explains the payoff ('one bad part no longer scraps the whole run'). The single-printer, mid-print framing implicitly separates it from planning tools, but the description never names close cousins like plan_object_skip or fleet_skip_objects, so sibling differentiation is left to inference.

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?

It states exactly when to use it (a part fails with spaghetti, a knocked-loose object, a detached corner) and imposes an explicit precondition: 'only while a multi-object plate is actively printing.' It also gives a prerequisite workflow ('Discover Bambu ids first:: list_plate_objects(...)') and requires user confirmation before calling, which is unusually actionable guidance.

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