Skip to main content
Glama

home_axes

Destructive

Homes X, Y, or Z axes with a model-specific safe sequence and optional plan-only or step-by-step execution, refusing while a print is running or paused.

Instructions

Home the print head — what the Home button on the printer's screen does.

Refused while a print is running, and while one is paused (the head is
over the part and homing travels).

Where the connected model's own start-sequence homing 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 — raise first, home X, Z found the way
the maker finds it, park off the plate — it runs that, one described
motion at a time.  A bare ``G28`` from an unknown height is exactly the
move that family's own sequences avoid, so a Bambu model whose sequence
is not served here is refused rather than guessed.  Other backends send
the firmware's own ``G28`` and say so (``sequence_source:
"firmware_home_routine"``) -- but only after the catalogue's motion
record for the declared ``printer_model`` has answered how that routine
finds Z: on a machine whose Z home presses a probe or the nozzle onto
the plate (most of them) the tool asks for ``plate_clear`` first, on
the few whose Z home cannot touch the plate it runs unasked, and with
no ``printer_model`` declared, or one the catalogue does not know, it
refuses and says which key to set (code ``PRINTER_MODEL_REQUIRED``).
Homing X and Y alone never needs the record.  The plan's first step
says what the person will see -- what descends and where, in the
vendor's words -- and whether the routine travels sideways before Z is
known; on a Klipper or USB Marlin machine the unit's own config or
reports settle the cells the maker left blank, and the plan says so.

Branch on ``outcome``: ``confirmed`` (the printer was seen at home),
``accepted`` (sent, not refused, not read back — the honest answer on
every backend Kiln cannot read a homed flag from), ``failed``.
``homed_axes`` names the axes the sequence's own homing commands
addressed; ``resting_position`` says where the head was left.

**Run it in steps the first time on any machine with a person beside
it.**  ``plan_only=True`` returns the sequence as steps -- what the
person will see and how each motion knows where to stop -- and sends
nothing.  ``step=N`` sends only step N, reports what it left armed
(heater, soft endstops), and describes step N+1 for the next call.  A
single script cannot be paused between motions, however well it was
announced; step mode can.

Args:
    axes: Any of ``X``, ``Y``, ``Z``.  Default all three.
    wait_seconds: How long to watch for a fault code afterwards on
        backends that raise one (default 10).
    step: Send only this step of the sequence (1-based).
    plan_only: Describe the steps; send nothing.
    plate_clear: A PERSON's statement that the plate is empty.  Required
        on every call that homes Z on a model whose Z home presses the
        nozzle onto the plate (the A1 mini), whatever the plate record
        says; 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.
    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": "home_axes"
  }
}

Input Schema

NameRequiredDescriptionDefault
axesNoAny of ``X``, ``Y``, ``Z``. Default all three. Default: "XYZ".
stepNoSend only this step of the sequence (1-based).
plan_onlyNoDescribe the steps; send nothing. Default: false.
plate_clearNoA PERSON's statement that the plate is empty. Required on every call that homes Z on a model whose Z home presses the nozzle onto the plate (the A1 mini), whatever the plate record says; 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.
printer_nameNoWhich printer. Omit for the default one.
wait_secondsNoHow long to watch for a fault code afterwards on backends that raise one (default 10).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.1
    • changedInput schema / properties / axes / description
      Previous value: -"Default: \"XYZ\"."New value: +"Any of ``X``, ``Y``, ``Z``.  Default all three. Default: \"XYZ\"."
    • 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.  Required on every call that homes Z on a model whose Z home presses the nozzle onto the plate (the A1 mini), whatever the plate record says; 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 / step / description
      Added value: +"Send only this step of the sequence (1-based)."
    • addedInput schema / properties / wait_seconds / description
      Added value: +"How long to watch for a fault code afterwards on backends that raise one (default 10)."
  2. Addedv1.5.0

TDQS

A4.1/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 that by disclosing the refusal conditions, the motion order of the hosted sequence (raise, home X, find Z, park off plate), the mechanical reason a bare G28 is avoided, the fact that Z homing may press a nozzle onto the plate, and the exact refusal codes (PRINTER_MODEL_REQUIRED, PLATE_CLEAR_REQUIRED) with the camera snapshot escape hatch. It also explains which sequence_source each backend produces and why a Bambu model without a served sequence is refused rather than guessed.

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 is a model of front-loading, but the middle paragraph is a run-on that packs firmware routing, catalogue lookups, refusal codes and plan-step narration into one dense block, forcing re-reads. The step-mode and branch-on-outcome guidance at the end is well structured, but overall the text is roughly twice the length needed to convey the same instructions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a physically destructive, safety-sensitive motion tool this covers what matters: refusal states, prerequisite keys, the human-in-the-loop plate_clear rule, and the step/plan modes for cautious first runs. An output schema already carries the return values, so restating outcome meanings and homed_axes/resting_position is additive rather than necessary. Minor gaps remain, such as any auth or lock requirement before commanding a printer over the network.

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

Parameters4/5

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

Schema coverage is 100%, so a 3 is the baseline; the description earns above that by adding meaning the schema lacks — that step=N also reports what was left armed (heater, soft endstops) and describes step N+1, and that plate_clear must never be set on a person's behalf. Some parameter text (plate_clear, printer_name) is a verbatim restatement of the schema, which caps it below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line names a concrete verb and resource ("Home the print head") and anchors it to a familiar physical control (the Home button on the printer's screen), so the action is unmistakable. It does not, however, distinguish itself from nearby siblings such as park_head or trigger_bed_level, which is the only thing keeping it off a 5.

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?

The description gives explicit when-not conditions (refused while a print is running or paused) and clear in-tool alternatives: plan_only for a dry run, step=N for paced execution, with the stated rationale that a single script cannot be paused between motions. It also states the prerequisite for the firmware path (a declared printer_model the catalogue knows). It does not route the agent to sibling tools, so usage context is clear but not complete across the toolkit.

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