Skip to main content
Glama

skip_print_objects

Skip failed objects mid-print on multi-object plates, saving the rest of the print. Stop printing defective parts without canceling the entire job.

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: Backend-specific object identifiers to abandon (see above).
    plate_number: Which plate the ids came from (1-based, default 1).
        Recorded for context; the ids are what the printer acts on.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
object_idsYes
plate_numberNo
Behavior5/5

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

Since no annotations are provided, the description fully discloses behavior: 'skipping is IRREVERSIBLE', 'skips are cumulative', 'only while a multi-object plate is actively printing', backend-specific ID handling, and printer support matrix. It also describes the return value shape. No contradictions with annotations.

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?

The description is long but well-organized: general purpose, benefits, identifier details, printer support, agent contract, then args and returns. It is front-loaded with the core purpose. However, some details could be more compact without losing clarity.

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?

Given the complexity of multi-backend support and irreversible actions, the description is very complete. It covers all necessary context: prerequisites, printer compatibility, identifier formats, behavior during print, and return value. Without output schema, it still describes return dict structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description compensates by detailing what object_ids are with backend-specific examples (Bambu, Klipper, OctoPrint) and explaining plate_number as 'which plate the ids came from (1-based, default 1) recorded for context'. This adds significant meaning beyond the schema.

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?

The description starts with 'Abandon one or more failed objects on a multi-object plate, mid-print.' which clearly states the verb (abandon/skip) and resource (objects on a plate). It distinguishes itself from sibling tools like cancel_print (full cancel) and pause_print by specifying partial object skipping. The title also aligns.

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?

The description explicitly explains when to use: 'when one part on a full plate fails' and provides when-not-to-use: 'Prusa via Prusa Link can't be skipped remotely', 'Elegoo SDCP protocol... has no skip command'. It also references sibling list_plate_objects for discovering IDs and includes an agent display contract with usage conditions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server