Skip to main content
Glama

park_head

Move the print head somewhere safe, away from the plate, and leave it there.

Instructions

Move the print head somewhere safe, away from the plate, and leave it there.

The retreat, as distinct from ``home_axes`` (the measurement).  A park
NEVER homes Z and never heats: it raises the head the vendor's way,
homes X (an endstop -- nothing is touched), and travels to the model's
own off-plate spot -- on a Bambu, the position the machine itself
flushes at, 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.  On
Marlin, Klipper and RepRapFirmware the firmware's own home position IS
the park, chosen by whoever configured the machine -- and the catalogue's
motion record for the declared ``printer_model`` decides how much of it
is sent: on a machine whose Z home presses a probe or the nozzle onto
the plate (most of them), park homes X and Y only and leaves Z alone;
on the few whose Z home cannot touch the plate, the full home.  With no
``printer_model`` declared, or one the catalogue does not know, park
refuses and says which key to set (code PRINTER_MODEL_REQUIRED).  A
Bambu model whose spot is not served here refuses by name rather than
guessing a coordinate, and says to use the screen's jog controls, Z up
first -- never its Home button over a part.

Use this first on any machine you are nervous about: it is the safer
of the two verbs by construction, because nothing descends.  Same
``plan_only`` / ``step`` options as ``home_axes`` -- run it in steps
the first time with a person beside the machine.

Args:
    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.  Lets a
        park proceed over a plate the record says holds a part, and lets
        the full home (Z included) stand in for the park on a machine
        whose Z home touches the plate.  Written to the plate record,
        as on ``home_axes``: the plate reads ``clear`` until the next
        print starts.  Never set it on a person's behalf.
    printer_name: Which printer.  Omit for the default one.

Input Schema

NameRequiredDescriptionDefault
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.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 burden and does so in detail: park never homes Z and never heats, homes X via an endstop, and the exact sequence varies by firmware (Bambu hosted spot vs Marlin/Klipper/RepRapFirmware catalogue-driven motion record). It discloses refusal modes, the offline copy of the hosted plan, and the plate_clear record write — all things an agent could not 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.

Conciseness4/5

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

It is front-loaded correctly, with purpose, sibling distinction and safety rationale first, then a structured Args block. It is on the long side, and the Bambu sentence about Kiln's hosted service, sign-in and offline caching is denser than an agent needs to invoke the tool, so a small trim would help.

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 no-required-arg mutation that has an output schema, the description covers everything material: what moves, what does not move, per-firmware branching, refusal codes, safety guardrails for plate_clear, and the step/plan_only workflow. Return values are covered by the output schema, so no gap remains.

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 40%, so the description must compensate, and it does. wait_seconds is scoped to fault-code watching on backends that raise one, step is defined as 1-based partial dispatch, plan_only is "describe the steps; send nothing," and plate_clear is given both its effect and a hard safety rule ("Never set it on a person's behalf"). printer_name's default-omission behavior is also spelled out.

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 sentence gives a concrete verb, object and scope: "Move the print head somewhere safe, away from the plate, and leave it there." It then immediately distinguishes itself from the nearest sibling, home_axes, calling this "the retreat, as distinct from home_axes (the measurement)" — an agent can pick the right verb without opening either 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?

It states when to prefer it ("Use this first on any machine you are nervous about: it is the safer of the two verbs by construction, because nothing descends") and names the excluded alternative (home_axes). It also states a real precondition with the correct error code (PRINTER_MODEL_REQUIRED) and a refusal mode for unserved Bambu spots, so the agent knows the boundary conditions before calling.

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