Skip to main content
Glama

load_filament

Destructive

Feeds filament to a 3D printer nozzle—AMS tray on Bambu Lab, manual feed elsewhere—while checking temperature safety and reporting confirmed, accepted, or failed outcomes.

Instructions

Feed filament to the nozzle — an AMS tray on Bambu, a manual feed elsewhere.

On Bambu Lab the firmware's own change-filament routine runs (retract,
feed, purge) and the answer is read from the AMS: ``extrusion_verified``
is ``True`` once ``tray_now`` reports the tray feeding the nozzle,
``False`` with the fault code in plain language if the routine raised
one (the same HMS codes the touchscreen shows), ``None`` if neither
arrived in ``wait_seconds``.  On Klipper a ``LOAD_FILAMENT`` / ``M701``
macro from the printer's own config is used when it exists; otherwise,
and on OctoPrint / Duet / serial, the hotend is heated and
``length_mm`` is fed at 3 mm/s — push the filament into the extruder
first.

Temperature is checked against the printer's safety profile, the
spool's own ``nozzle_temp_min/max`` (AMS) or Kiln's material table,
and the 170 °C cold-extrusion floor; refused outside any of them.
Refused while a print is running (paused is fine).

Branch on ``outcome`` — one field, three values, the same shape
``set_temperature`` and ``start_print`` use:

- ``"confirmed"``: the printer showed the effect (the AMS reports the
  tray feeding the nozzle).
- ``"accepted"``: the command was sent and not refused, and the printer
  has not shown the effect yet.  A Bambu load takes a minute or two
  and a tool call cannot wait that long, so this is the normal answer
  when the watch runs out: the routine is still running.  Do NOT send
  the load again — read ``next_read`` (``ams_status`` for ``tray_now``,
  ``printer_status`` for ``print_error``) to finish the answer.
- ``"failed"``: the gate or the printer refused, or a fault was raised
  (``error_code`` / ``error_hint``).

On Bambu Lab that check binds what Kiln sends, not what the routine
does: the firmware heats to its own flush temperature for a filament
change (250 °C observed on an A1 asked for 215, the ``M109 S250`` its
own start sequence sets) and drops to the requested target only when
the routine finishes.  The answer reports the temperature the firmware
actually used (``firmware_hotend_target_c``) beside the one Kiln
validated; the gate is not widened to match it.

Where the declared model's own purge position is served one plan at a time through Kiln's hosted service for a printer paired to your Kiln sign-in, free, and kept on your machine so it works offline, the head is parked over the purge chute
before the routine runs, so its purge falls into the chute instead of
hanging off the nozzle at home; the answer says where the head was
either way.

Args:
    slot: The printer's own tray id, as ``ams_status`` lists it in
        ``tray_id`` (0–3 on unit A, 4–7 on unit B, 128–135 for AMS HT
        units; HT-A is 128).  Omit for the external / single spool.
    material: e.g. ``"PLA"`` — picks a temperature when none is given
        and no spool report supplies one.
    temperature: Hotend target in °C.  Omit to use the middle of the
        spool's or material's window.
    length_mm: Feed distance for the generic G-code path (default 60;
        bowden machines need more).  Ignored where the firmware's own
        routine decides.
    wait_seconds: How long to watch for the AMS to confirm.  Bounded to
        what a tool call can wait inside the client's request window
        (40 s unless ``KILN_FILAMENT_WAIT_BUDGET_S`` says otherwise); a
        longer ask is applied at the bound and the response says so.
    keep_hot: Leave the heater ON afterwards, for a caller about to do
        something else hot.  Off by default: every op ends with the
        heater off and says so; where the machine's own cool-down is
        served, the part fan goes on and Kiln turns it off on its own
        once the nozzle reads the hand-off temperature -- the answer
        does not wait for that, and ``printer_status`` shows it.
    printer_name: Which printer.  Omit for the default one.

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": "load_filament"
  }
}

Input Schema

NameRequiredDescriptionDefault
slotNoThe printer's own tray id, as ``ams_status`` lists it in ``tray_id`` (0–3 on unit A, 4–7 on unit B, 128–135 for AMS HT units; HT-A is 128). Omit for the external / single spool.
keep_hotNoLeave the heater ON afterwards, for a caller about to do something else hot. Off by default: every op ends with the heater off and says so; where the machine's own cool-down is served, the part fan goes on and Kiln turns it off on its own once the nozzle reads the hand-off temperature -- the answer does not wait for that, and ``printer_status`` shows it. Default: false.
materialNoe.g. ``"PLA"`` — picks a temperature when none is given and no spool report supplies one.
length_mmNoFeed distance for the generic G-code path (default 60; bowden machines need more). Ignored where the firmware's own routine decides.
temperatureNoHotend target in °C. Omit to use the middle of the spool's or material's window.
printer_nameNoWhich printer. Omit for the default one.
wait_secondsNoHow long to watch for the AMS to confirm. Bounded to what a tool call can wait inside the client's request window (40 s unless ``KILN_FILAMENT_WAIT_BUDGET_S`` says otherwise); a longer ask is applied at the bound and the response says so.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • changedInput schema / properties / keep_hot / description
      Previous value: -"Default: false."New value: +"Leave the heater ON afterwards, for a caller about to do something else hot.  Off by default: every op ends with the heater off and says so; where the machine's own cool-down is served, the part fan goes on and Kiln turns it off on its own once the nozzle reads the hand-off temperature -- the answer does not wait for that, and ``printer_status`` shows it. Default: false."
    • addedInput schema / properties / length_mm / description
      Added value: +"Feed distance for the generic G-code path (default 60; bowden machines need more).  Ignored where the firmware's own routine decides."
    • addedInput schema / properties / material / description
      Added value: +"e.g. ``\"PLA\"`` — picks a temperature when none is given and no spool report supplies one."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default one."
    • addedInput schema / properties / slot / description
      Added value: +"The printer's own tray id, as ``ams_status`` lists it in ``tray_id`` (0–3 on unit A, 4–7 on unit B, 128–135 for AMS HT units; HT-A is 128).  Omit for the external / single spool."
    • addedInput schema / properties / temperature / description
      Added value: +"Hotend target in °C.  Omit to use the middle of the spool's or material's window."
    • addedInput schema / properties / wait_seconds / description
      Added value: +"How long to watch for the AMS to confirm.  Bounded to what a tool call can wait inside the client's request window (40 s unless ``KILN_FILAMENT_WAIT_BUDGET_S`` says otherwise); a longer ask is applied at the bound and the response says so."
  2. Addedv1.5.0

TDQS

A4.3/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses the temperature safety gates (safety profile, spool window, 170 °C cold-extrusion floor), the fact that the firmware heats to its own flush temperature (250 °C observed vs 215 requested) and that the gate is not widened to match, the wait budget bound with the KILN_FILAMENT_WAIT_BUDGET_S override, and that every op ends with the heater off unless keep_hot. This is exactly the mutation context that destructiveHint=true alone cannot convey.

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 and the outcome-branching list are well front-loaded and earn their place, but the paragraph about the hosted purge-position service ("served one plan at a time through Kiln's hosted service for a printer paired to your Kiln sign-in, free, and kept on your machine so it works offline") is a convoluted run-on whose operational takeaway is only "the head is parked over the purge chute." The Args section also duplicates the schema word for word.

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?

There is no output schema, yet the description documents the return contract in full: the three outcome values, extrusion_verified semantics (True/False/None tied to wait_seconds), next_read fields, error_code/error_hint, and firmware_hotend_target_c. For a seven-parameter, multi-firmware mutation tool, nothing an agent needs to call it correctly and interpret the result is missing.

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 Args block is verbatim identical to the schema descriptions, so the prose adds no meaning beyond the structured fields. The tray-id ranges and default-60 length are already documented in the schema; baseline 3 applies.

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?

Opens with a specific verb and resource ("Feed filament to the nozzle") and immediately disambiguates the two mechanisms (AMS tray on Bambu, manual feed elsewhere). An agent can separate this from unload_filament and purge_filament without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use context: prerequisites ("push the filament into the extruder first" on the generic path), a hard exclusion ("Refused while a print is running (paused is fine)"), and an explicit do-not-retry instruction on "accepted" with the follow-up read to perform instead. It never names a sibling tool (unload_filament, purge_filament) as the alternative, so routing between filament operations is still inferred.

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