Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

plan_kit_plates

Read-only

Pack a kit's parts onto print plates to determine plate count, part groupings, and fill levels from meshes or a tracked design ID. Requires Kiln Pro.

Instructions

Pack a kit's parts onto print plates: how many plates, which parts share each one, and how full each plate is.

Needs Kiln 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": "plan_kit_plates"
  }
}

Input Schema

NameRequiredDescriptionDefault
scaleNoUniform scale applied before packing — pass advise_kit_scale's ``recommended_scale``. Default: 1.0.
gap_mmNoPart-to-part clearance (default 3 — the skirt/brim allowance; raise it for wide brims). Default: 3.0.
bed_x_mmNoPlate width (0 = smallest fleet bed when ``printers`` is given, else 256). Default: 0.0.
bed_y_mmNoPlate depth (0 = same default). Default: 0.0.
bed_z_mmNoBed height (0 = same default). Default: 0.0.
materialNoMaterial for every part without an override. Default: "PLA".
printersNoFleet mode — ``[{"name", "bed_x_mm", "bed_y_mm", "bed_z_mm", "materials": ["PLA", ...]}, ...]``.
design_idNoKit shortcut — a design split with tracking resolves its CURRENT pieces (re-splits included) and their material from the kit record, so "plate up my kit" needs no path bookkeeping. Names come back as piece labels ("Piece 3.1"). Default: "".
part_namesNoDisplay names aligned with part_paths.
part_pathsNoOne mesh file per part (the import_model_parts manifest). Omit and pass ``design_id`` instead for a tracked kit.
orientationNo``"flat"`` (default) — pose each part min-height; ``"as_imported"`` — keep the file's pose (use when parts already went through make_printable). Default: "flat".
part_materialsNoPer-part material list aligned with part_paths (splits the kit into single-material plates).
layer_height_mmNoLayer height for time forecasts. Default: 0.2.
print_speed_mm_sNoPrint speed for time forecasts. Default: 60.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.5.1
    • changedInput schema / properties / bed_x_mm / description
      Previous value: -"Default: 0.0."New value: +"Plate width (0 = smallest fleet bed when ``printers`` is given, else 256). Default: 0.0."
    • changedInput schema / properties / bed_y_mm / description
      Previous value: -"Default: 0.0."New value: +"Plate depth (0 = same default). Default: 0.0."
    • changedInput schema / properties / bed_z_mm / description
      Previous value: -"Default: 0.0."New value: +"Bed height (0 = same default). Default: 0.0."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"Kit shortcut — a design split with tracking resolves its CURRENT pieces (re-splits included) and their material from the kit record, so \"plate up my kit\" needs no path bookkeeping.  Names come back as piece labels (\"Piece 3.1\"). Default: \"\"."
    • changedInput schema / properties / gap_mm / description
      Previous value: -"Default: 3.0."New value: +"Part-to-part clearance (default 3 — the skirt/brim allowance; raise it for wide brims). Default: 3.0."
    • changedInput schema / properties / layer_height_mm / description
      Previous value: -"Default: 0.2."New value: +"Layer height for time forecasts. Default: 0.2."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Material for every part without an override. Default: \"PLA\"."
    • changedInput schema / properties / orientation / description
      Previous value: -"Default: \"flat\"."New value: +"``\"flat\"`` (default) — pose each part min-height; ``\"as_imported\"`` — keep the file's pose (use when parts already went through make_printable). Default: \"flat\"."
    • addedInput schema / properties / part_materials / description
      Added value: +"Per-part material list aligned with part_paths (splits the kit into single-material plates)."
    • addedInput schema / properties / part_names / description
      Added value: +"Display names aligned with part_paths."
    • addedInput schema / properties / part_paths / description
      Added value: +"One mesh file per part (the import_model_parts manifest).  Omit and pass ``design_id`` instead for a tracked kit."
    • changedInput schema / properties / print_speed_mm_s / description
      Previous value: -"Default: 60.0."New value: +"Print speed for time forecasts. Default: 60.0."
    • addedInput schema / properties / printers / description
      Added value: +"Fleet mode — ``[{\"name\", \"bed_x_mm\", \"bed_y_mm\", \"bed_z_mm\", \"materials\": [\"PLA\", ...]}, ...]``."
    • changedInput schema / properties / scale / description
      Previous value: -"Default: 1.0."New value: +"Uniform scale applied before packing — pass advise_kit_scale's ``recommended_scale``. Default: 1.0."
  2. Addedv1.5.0

TDQS

A3.8/5.0
Behavior4/5

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

The annotations already establish that this is a read-only, non-destructive, closed-world operation. The description adds useful context beyond the annotations by stating the licensing prerequisite ('Needs Kiln Pro') and summarizing what the plan returns: plate count, part sharing, and plate fullness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with no wasted wording. The core capability is front-loaded, and the prerequisite is kept brief and separate.

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

Completeness4/5

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

For a 14-parameter, fully optional planning tool with complete schema descriptions, the description covers the purpose, output shape, and licensing requirement well enough. It does not explain the design_id versus part_paths workflow, but the schema descriptions already carry that detail.

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 input schema already explains all 14 parameters in detail. The tool description adds no parameter-level meaning beyond that schema, which is acceptable under the high-coverage baseline.

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 specific verb and resource: packing a kit's parts onto print plates. It also describes the resulting plan — plate count, part grouping, and plate fullness — which makes the tool's purpose clear, though it does not explicitly distinguish itself from sibling plate-arrangement tools such as arrange_parts_on_plate.

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 purpose implies when to use it — when a kit needs to be planned across print plates — and states a prerequisite, 'Needs Kiln Pro.' However, it gives no explicit guidance on when to choose this over related tools like arrange_parts_on_plate or auto_arrange_parts_on_plate, and no exclusions are provided.

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