Skip to main content
Glama

purge_filament

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

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.

Input Schema

NameRequiredDescriptionDefault
slotNo
keep_hotNoDefault: false.
materialNo
length_mmNoDefault: 30.0.
temperatureNo
printer_nameNo
wait_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does: it defines extrusion_verified as False/None and never True, explains what error_hint means per backend, documents the purge-station parking behavior, and states that every operation ends with the heater off unless keep_hot is set. That is exactly the kind of behavior an agent cannot infer from the schema.

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 and return semantics are front-loaded, but the purge-position paragraph is a single convoluted sentence that buries its point (“parked” vs “in_place”) in subordinate clauses, and the hosted-service aside adds length without changing how the agent calls the tool.

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?

With seven parameters, no output schema, and no annotations, the description covers safety gating, return-value meaning, purge-station reporting, cooldown hand-off, and where the print must not be running. Nothing an agent needs to call it or interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 29%, yet the Args block documents all seven parameters: ranges for length_mm, temperature selection logic for material and slot, the AMS tray default, what wait_seconds bounds are measured against, and the keep_hot/cooldown interaction. This fully compensates for the sparse schema.

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 concrete verb and resource: "Heat the nozzle and extrude a short length — the clog test." That single line separates it from load_filament (feeding filament) and wipe_nozzle (pad cleaning), both of which are named nearby in the fleet.

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?

Explicitly states preconditions and refusal cases (not while printing, paused is fine, 170 °C floor, safety ceiling, spool window, 150 mm cap) and routes pad cleaning to wipe_nozzle. It never states the positive case against load_filament, but the scope is otherwise clear.

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