Skip to main content
Glama

wipe_nozzle

Destructive

Clean the nozzle tip on the printer's own wipe pad by heating to the material's temperature window, retracting, and running the model's wipe pass; reports final head position.

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 for a whole wipe, 10 per step in step mode).
    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.

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

Input Schema

NameRequiredDescriptionDefault
slotNoAMS tray whose temperature window applies (Bambu). Omit to use the tray currently feeding the nozzle.
stepNoSend 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.
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.
plan_onlyNoDescribe the steps; send nothing. Default: false.
plate_clearNoA 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. Default: false.
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 wipe to watch for a fault code (default 45 for a whole wipe, 10 per step in step mode).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 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 / material / description
      Added value: +"e.g. ``\"PLA\"`` — picks a temperature when none is given."
    • changedInput schema / properties / plan_only / description
      Previous value: -"Default: false."New value: +"Describe the steps; send nothing. Default: false."
    • changedInput schema / properties / plate_clear / description
      Previous value: -"Default: false."New value: +"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. Default: false."
    • 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 / step / description
      Added value: +"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."
    • 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 wipe to watch for a fault code (default 45 for a whole wipe, 10 per step in step mode)."
  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 say readOnly=false and destructive=true; the description goes far beyond that, disclosing the heat-then-park-then-retract-then-wipe sequence, the sign-in/hosted-service gate with offline caching of the plan, the heater-off and cool-down hand-off behavior, and the honest caveat that extrusion_verified stays None because Bambu acknowledges no G-code. It also documents the plate_clear safety requirement including the PLATE_CLEAR_REQUIRED refusal and snapshot_path hint, which no annotation conveys.

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 and most sentences carry real information (safety gates, heater state, verification limits), but the middle paragraph is convoluted — the hosted-service clause is tangled with dashes and a parenthetical config note — and the Args block largely duplicates the schema, which is wasted length.

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 nine-parameter, no-output-schema physical-action tool, the description covers what an agent needs: preconditions and refusals, what the response reports ('where the head ended up'), post-call machine state (heater, part fan, printer_status), and the limit of the success signal. Nothing material is left to inference.

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% and the Args block in the description is essentially verbatim with the schema property descriptions, so it adds no meaning beyond structured data. The surrounding prose does give indirect context (e.g. step mode is the only way an unproven wipe runs), but that lives in the body, not the parameter docs, so baseline 3 is right.

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 first line is a concrete verb+resource: 'Clean the nozzle tip on the printer's own wipe pad.' It immediately distinguishes this from the adjacent filament operations by naming the physical target and the mechanism (the machine's own pad pass), and it names the boundary case (models whose pad pass isn't served) with the fallback actions.

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?

Usage conditions are unusually explicit: refused while printing, paused, below 170 °C, above the safety ceiling, outside the loaded spool's window, and for unsupported models — with the alternative given ('use the printer's own screen, or start a print'). It also explains when step mode and plan_only are appropriate (benching an unproven wipe). It stops short of explicitly contrasting with purge_filament beyond noting the shared gate, so a 4 rather than 5.

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