Skip to main content
Glama

wipe_nozzle

Clean the nozzle tip on the printer's own wipe pad.

Instructions

Clean the nozzle tip on the printer's own wipe pad.

Heats to the loaded material's window (or the temperature given), parks
over the purge chute while heating, snaps the tail with the vendor's
own retract, then runs the wipe-pad pass the machine's start sequence
runs and reports where the head ended up.  Only where the declared
model's pad pass 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
(``printer_model`` in config.yaml names the model).  Any other model is
refused with the reason rather than moved to a guessed coordinate: use
the printer's own screen, or start a print — its start sequence wipes
on the pad.  No model ever borrows a sibling's position.

Same gate as ``purge_filament``: refused while printing, below 170 °C,
above the safety ceiling, outside the loaded spool's own window.  Also
refused while paused — the head is parked over the part and Kiln does
not travel mid-print.  The pad is touched the machine's own way, on the
way down in temperature.  ``extrusion_verified`` stays ``None``: Bambu
acknowledges no G-code, so "no fault raised" is the strongest thing the
printer can say — look at the tip.

Args:
    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 wipe to watch for a fault code
        (default 45).
    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.
    plate_clear: A PERSON's statement that the plate is empty, given on
        THIS call.  Read on every call by a wipe whose plan presses the
        plate (its Z datum is taken on the plate, or the head has to
        cross the plate to reach the pad), whatever the plate record
        says -- the record cannot see a print started from the printer's
        own screen; without it the tool refuses with
        ``PLATE_CLEAR_REQUIRED`` and, where the printer has a camera,
        ``snapshot_path`` -- look, then call again with it set.  Never
        set it on a person's behalf.
    step: Send only this step of the wipe's plan (1-based); the answer
        describes the next one, and the finish (heater off, the
        cool-down) runs after the last step.  Step mode is how a wipe
        no one has yet run on a real machine is benched -- one motion,
        one report, one go -- and the only way such a wipe runs.
    plan_only: Describe the steps; send nothing.
    printer_name: Which printer.  Omit for the default one.

Input Schema

NameRequiredDescriptionDefault
slotNo
stepNo
keep_hotNoDefault: false.
materialNo
plan_onlyNoDefault: false.
plate_clearNoDefault: false.
temperatureNo
printer_nameNo
wait_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full behavior burden and does so: it discloses the safety gate, end-of-op state (heater off, cool-down fan handled by Kiln), that extrusion_verified stays None because Bambu acknowledges no G-code, the plan_only/step benching mode, and the plate_clear refusal with snapshot_path. Nothing about side effects or required assertions is left implicit.

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

Conciseness4/5

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

Front-loads the purpose, then conditions, then a clean Args block, and most sentences earn their place given the complexity. However, the sentence about the hosted service ('served one plan at a time through Kiln's hosted service ... free, and kept on your machine') is a dense run-on that is hard to parse, and the pad/gate material is restated across paragraphs.

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 9-parameter mutation with no annotations and no output schema, the description covers everything an agent needs: refusal codes, what the response reports ('where the head ended up'), what it deliberately does not report (extrusion_verified), and the state the machine is left in. No missing preconditions or return expectations.

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 33% and the schema descriptions are trivial ('Default: false.'), so the description must compensate — and it does, documenting all 9 args with semantics the schema lacks: material picks a temperature, temperature/slot interact with AMS windows, wait_seconds defaults to 45, keep_hot changes ending state, plate_clear is a person's assertion never to be set on their behalf, and step/plan_only define plan execution modes.

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 sentence gives a specific verb and resource ('Clean the nozzle tip on the printer's own wipe pad') and the body spells out the exact motion sequence (heat to window, park over purge chute, tail snap, wipe-pad pass). It explicitly distinguishes itself from purge_filament and from the manual alternatives (printer screen / start a print), so an agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

States precisely when the tool works ('only where the declared model's pad pass is served ... printer paired to your Kiln sign-in') and when it does not, with the fallback named. It enumerates refusal conditions (printing, below 170 °C, above ceiling, outside spool window, paused) and the PLATE_CLEAR_REQUIRED case, which is exactly the when/when-not detail an agent needs.

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