Skip to main content
Glama

home_axes

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

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.

Input Schema

NameRequiredDescriptionDefault
axesNoDefault: "XYZ".
stepNo
plan_onlyNoDefault: false.
plate_clearNoDefault: false.
printer_nameNo
wait_secondsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

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?

With no annotations, the description carries the full behavioral burden and does so extensively: refusal conditions, plan/step semantics, what gets sent per backend, PLATE_CLEAR_REQUIRED and PRINTER_MODEL_REQUIRED refusal codes, outcome meanings, and safety expectations are all disclosed.

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?

It is front-loaded with a clear purpose, but the body is a very dense wall of text with long run-on sentences and nested clauses. Much of the detail is valuable, yet the structure makes it harder to scan than it needs to be for six parameters.

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?

Given the tool's complexity, safety implications, and the presence of an output schema, the description is complete. It explains refusal paths, stepwise execution, outcome branching, and prerequisite model/plate conditions without needing to restate return values.

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 50%, but the description documents every parameter with operational meaning beyond the schema: axes default and values, wait_seconds behavior, step being 1-based and what it leaves armed, plan_only sending nothing, plate_clear as a personal safety attestation, and printer_name as optional default selection.

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 description opens with a specific verb and resource: 'Home the print head — what the Home button on the printer's screen does.' It clearly defines the operation and its user-facing analog, making it distinguishable from related motion tools like park_head.

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 gives strong when/when-not guidance: refused while printing or paused, recommended step-by-step first use, plan_only for describing without sending, and plate_clear only when a person confirms an empty plate. It does not explicitly route to sibling alternatives such as park_head, so it stops short of a 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