Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

plan_object_skip

Read-only

Determines which object to skip when a multi-object 3D print fails, using plate object data and failed-object identifiers to plan the next print.

Instructions

Work out which object to skip on a failing multi-object print (Pro).

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": {
      "plate_objects": "<plate_objects>"
    },
    "name": "plan_object_skip"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_typeNothe backend (``"bambu"``, ``"moonraker"``, ``"octoprint"``, ...) so the plan knows if it's even possible. Default: "".
plate_objectsYesthe ``objects`` list from ``list_plate_objects`` (each with ``label_id``, ``name``, ``bbox``, ``area_mm2``).
failed_objectsNowhich object(s) failed — by ``label_id`` (``"757"``) or by name (``"cap"``); Kiln matches either. Omit it to get the "which one failed?" prompt instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / failed_objects / description
      Added value: +"which object(s) failed — by ``label_id`` (``\"757\"``) or by name (``\"cap\"``); Kiln matches either.  Omit it to get the \"which one failed?\" prompt instead."
    • addedInput schema / properties / plate_objects / description
      Added value: +"the ``objects`` list from ``list_plate_objects`` (each with ``label_id``, ``name``, ``bbox``, ``area_mm2``)."
    • changedInput schema / properties / printer_type / description
      Previous value: -"Default: \"\"."New value: +"the backend (``\"bambu\"``, ``\"moonraker\"``, ``\"octoprint\"``, ...) so the plan knows if it's even possible. Default: \"\"."
    • changedInput schema / required
      Previous value: -[
-  "plate_objects",
-  "failed_objects"
-]New value: +[
+  "plate_objects"
+]
  2. Addedv1.5.0

TDQS

B3.4/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 that this is a planning/decision step rather than an action and flags '(Pro)' tier gating, but says nothing about what the resulting plan contains, whether it can refuse (printer_type may make it impossible), or how the 'which one failed?' prompt path behaves.

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; the task and the scenario appear immediately. The '(Pro)' parenthetical is terse to the point of being slightly cryptic, which keeps it from a 5.

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?

With only 3 fully documented parameters and readOnly annotations, the input side is well covered. However, there is no output schema, so the description is the only place an agent could learn what the returned 'plan' looks like or that omitting failed_objects yields a clarifying prompt rather than a plan — a real gap for a decision-producing tool.

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 coverage is 100% and the parameter descriptions are unusually rich, explaining label_id-vs-name matching and the prompt returned when failed_objects is omitted. The tool description adds no parameter meaning of its own, so the baseline 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 names a concrete decision task ('work out which object to skip') scoped to 'a failing multi-object print', which clearly separates it from execution siblings like skip_print_objects or fleet_skip_objects. It does not explicitly name those alternatives, but the planning-vs-doing distinction is readable from the verb.

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?

The phrase 'on a failing multi-object print' implies the triggering situation, but there is no explicit when-to-use, no statement that the actual skip is performed elsewhere, and no prerequisite such as needing list_plate_objects output first. Usage is inferable rather than stated.

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