Skip to main content
Glama

purge_filament

Destructive

Heat the nozzle and extrude a short test length to verify filament flow and clear clogs, reporting whether extrusion was actually confirmed or refused by the printer.

Instructions

Heat the nozzle and extrude a short length — the clog test.

Reports what the printer could honestly say, not that a command was
sent: ``extrusion_verified`` is ``False`` with ``error_hint`` when the
firmware refused the move (cold-extrusion guard, Klipper
``can_extrude=false``) or raised an extrusion fault during or right
after the purge (Bambu HMS codes, decoded to plain language);
``None`` when the move was accepted and the machine reports no flow
signal — every backend without a flow sensor — in which case look at
the nozzle for a clean stream.  It is never ``True`` on a purge alone.

Refused while printing (paused is fine), below 170 °C, above the
printer's safety ceiling, outside the loaded spool's own temperature
window, and beyond 150 mm.

The answer always says where the purge went.  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
heater is touched, the machine's own tail snap and shake follow the
extrude, and ``purge_station.status`` is ``"parked"``.  Otherwise it is
``"in_place"`` with the reason (a paused print, or no served position
for the model) and the head's coordinates where the printer reports
any; no coordinate is ever inferred, and no model borrows a sibling's.
A pad wipe is a separate door: ``wipe_nozzle``.

Args:
    length_mm: Extrusion length, 1–150 mm (default 30).
    material: e.g. ``"PLA"`` — picks a temperature when none is given.
    temperature: Hotend target in °C.  Omit to use the middle of the
        spool's (AMS) or material's window.
    slot: AMS tray whose temperature window applies (Bambu).  Omit to
        use the tray currently feeding the nozzle.
    wait_seconds: How long after the purge to watch for a fault code
        on Bambu (default 10).  Bounded the same way as
        ``load_filament``'s.
    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": "purge_filament"
  }
}

Input Schema

NameRequiredDescriptionDefault
slotNoAMS tray whose temperature window applies (Bambu). Omit to use the tray currently feeding the nozzle.
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.
length_mmNoExtrusion length, 1–150 mm (default 30). Default: 30.0.
temperatureNoHotend target in °C. Omit to use the middle of the spool's (AMS) or material's window.
printer_nameNoWhich printer. Omit for the default one.
wait_secondsNoHow long after the purge to watch for a fault code on Bambu (default 10). Bounded the same way as ``load_filament``'s.

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."
    • changedInput schema / properties / length_mm / description
      Previous value: -"Default: 30.0."New value: +"Extrusion length, 1–150 mm (default 30). Default: 30.0."
    • addedInput schema / properties / material / description
      Added value: +"e.g. ``\"PLA\"`` — picks a temperature when none is given."
    • addedInput schema / properties / printer_name / description
      Added value: +"Which printer.  Omit for the default one."
    • addedInput schema / properties / slot / description
      Added value: +"AMS tray whose temperature window applies (Bambu).  Omit to use the tray currently feeding the nozzle."
    • addedInput schema / properties / temperature / description
      Added value: +"Hotend target in °C.  Omit to use the middle of the spool's (AMS) or material's window."
    • addedInput schema / properties / wait_seconds / description
      Added value: +"How long after the purge to watch for a fault code on Bambu (default 10).  Bounded the same way as ``load_filament``'s."
  2. Addedv1.5.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description goes far beyond by explaining extrusion_verified semantics (False/None/never True), fault-code decoding, purge-station parking vs in_place with reasons, and that the heater is left off unless keep_hot. This is exactly the behavioral context annotations cannot carry.

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 purpose is front-loaded, but the body is dense and prose-heavy, with long parenthetical clauses and some repetition between the narrative and the Args block. It is appropriately sized for a complex physical action but could be tightened.

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?

For a 7-param mutation tool with no output schema, the description covers return semantics, refusal conditions, purge-station behavior, and heater hand-off thoroughly. An agent has everything needed to call it and interpret the result.

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 section largely restates the schema descriptions (temperature window, slot, wait_seconds bound). It adds marginal meaning, such as the default-middle-of-window temperature choice, but does not substantially exceed the structured fields.

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 opening line states a specific verb and resource ('Heat the nozzle and extrude a short length') and frames it as 'the clog test', which immediately distinguishes it from siblings like wipe_nozzle and load_filament.

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?

It explicitly routes the agent away from this tool for pad wipes ('A pad wipe is a separate door: wipe_nozzle') and enumerates refusal conditions (printing, <170 °C, over ceiling, outside spool window, >150 mm). It does not contrast against load_filament beyond a passing reference to its wait_seconds bound, so it stops short of full when/when-not coverage.

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