Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

plan_hardware_insertion

Plan where nuts, magnets, bearings, and inserts go in a 3D-printed part and when to pause printing to insert them; optionally write a G-code copy with those pauses.

Instructions

Plan nuts, magnets, bearings and inserts into a printed part: where, when, how.

Free door, tiered answer — Free: Safety checks — always free · Pro: The layer, the pause written for your printer, and a phone alert when it’s time · Business: + A board of every printer waiting for hands, and a record of who put what into which part · Enterprise: + Each insertion cited in the part’s First Article Inspection draft.

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": {
      "model_path": "<model_path>"
    },
    "name": "plan_hardware_insertion"
  }
}

Input Schema

NameRequiredDescriptionDefault
printerNoThe printer, e.g. "bambu_a1", "prusa_mk4s", "klipper". Blank reads it from the file when the slicer recorded it. Default: "".
hardwareNoWhat goes in, as short phrases: "2x M3 nut", "4x 6x3 magnet", "1x 608 bearing", "4x M3 heat-set insert", "2x 6-32 nut". Add "in S2" to pin a part to a seat the result lists. Leave it out to have Kiln propose the list for the person to confirm.
materialNoFilament, for the heat-set iron temperature. Default: "".
gcode_pathNoThe sliced file (.gcode or a sliced .3mf), sliced from this model with one copy on the plate. Default: "".
model_pathYesThe STL or 3MF the part was sliced from.
write_pausesNoTrue to also write a copy of the sliced file with the pauses inserted; the answer names the new file. Default: false.
confirm_unmeasuredNoAlso write a pause Kiln has read in a printer's firmware but not yet run on that printer (today: Marlin machines whose maker published the firmware and the control that continues the wait -- Ender 3, CR-10, Ender 3 V2/S1/S1 Pro/V3 SE, SV06). Ask the person first, and tell them to stay at the printer for the first pause. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • changedInput schema / properties / confirm_unmeasured / description
      Previous value: -"Default: false."New value: +"Also write a pause Kiln has read in a printer's firmware but not yet run on that printer (today: Marlin machines whose maker published the firmware and the control that continues the wait -- Ender 3, CR-10, Ender 3 V2/S1/S1 Pro/V3 SE, SV06). Ask the person first, and tell them to stay at the printer for the first pause. Default: false."
    • changedInput schema / properties / gcode_path / description
      Previous value: -"Default: \"\"."New value: +"The sliced file (.gcode or a sliced .3mf), sliced from this model with one copy on the plate. Default: \"\"."
    • addedInput schema / properties / hardware / description
      Added value: +"What goes in, as short phrases: \"2x M3 nut\", \"4x 6x3 magnet\", \"1x 608 bearing\", \"4x M3 heat-set insert\", \"2x 6-32 nut\". Add \"in S2\" to pin a part to a seat the result lists.  Leave it out to have Kiln propose the list for the person to confirm."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Filament, for the heat-set iron temperature. Default: \"\"."
    • addedInput schema / properties / model_path / description
      Added value: +"The STL or 3MF the part was sliced from."
    • changedInput schema / properties / printer / description
      Previous value: -"Default: \"\"."New value: +"The printer, e.g. \"bambu_a1\", \"prusa_mk4s\", \"klipper\". Blank reads it from the file when the slicer recorded it. Default: \"\"."
    • changedInput schema / properties / write_pauses / description
      Previous value: -"Default: false."New value: +"True to also write a copy of the sliced file with the pauses inserted; the answer names the new file. Default: false."
  2. Addedv1.5.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations declare this is a non-read-only, non-destructive operation, so the agent knows it can produce side effects. The description adds genuinely useful undisclosed context: results are tier-gated ('Free: Safety checks — always free' vs 'Pro: the pause written for your printer'), implying a free-tier caller may get only validation and no gcode/pause output. However it never states what is written where, whether the source file is left intact, or what the returned answer contains, and the tier block is ad copy rather than a clean behavioral statement.

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 first sentence is tight and front-loaded, but the second is a ~50-word tier/pricing block with middle dots and plan names that reads as marketing rather than tool documentation. It is not padded with filler exactly, but the signal-to-noise ratio drops sharply after sentence one. A one-line note like 'output detail depends on the caller's tier' would earn the same information in a fraction of the space.

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 7 parameters fully documented in schema and annotations covering the safety profile, and no output schema to explain, the description covers the essentials. What it omits is the shape of the answer — the layer chosen, the pause snippet, the named new file — which is the actual product of this tool and is only obliquely hinted at through tier copy. For a planning tool whose value is its output, that is a noticeable gap.

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 every one of the 7 parameters already carries its own explanation in the schema, including hardware phrase syntax, printer defaults, and write_pauses behavior. The description adds only a loose mapping ('nuts, magnets, bearings and inserts' to the hardware param) and no format or syntax detail beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

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 and resource set — planning nuts, magnets, bearings and inserts into a printed part, plus 'where, when, how'. That is far more concrete than a title restatement and an agent can distinguish it from siblings such as record_hardware_insertion or recommend_hardware_pocket. It stops short of 5 because it never names the sibling it is not, so the boundary must be inferred.

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?

Nothing in the description says when to call this versus alternatives, nor what prerequisites exist; the only implied usage comes from the required model_path in the schema. The long second sentence is pricing/tier positioning, not usage guidance — it tells the agent nothing about when this tool is the right choice. No when-not-to-use or alternative routing is offered.

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