Skip to main content
Glama

park_head

Destructive

Moves the 3D printer's print head to a safe off-plate position without homing Z or heating, leaving it there before maintenance or inspection.

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.

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

Input Schema

NameRequiredDescriptionDefault
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. 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. 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. Changed5 schema fields changedv1.5.1
    • 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.  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. 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.5/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: it never homes Z and never heats, raises the head the vendor's way, homes X, and travels to an off-plate spot. It also documents model-specific behavior, refusal conditions such as PRINTER_MODEL_REQUIRED, Bambu spot handling, and the safety implication that nothing descends.

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 definition is front-loaded with a clear one-sentence summary, but it is very long and includes extended vendor and hosted-service details that go beyond what an agent needs to invoke the tool. The Args section is well structured, but the prose paragraph is dense and could be trimmed without losing essential guidance.

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, the description is complete enough: it covers the mechanical behavior, model-dependent behavior, refusal cases, safety conditions, and parameter usage. An output schema exists, so return values need not be described, and the annotations already declare the safety profile.

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 already 100%, and the description's Args section largely repeats the schema descriptions for step, plan_only, plate_clear, printer_name, and wait_seconds. It adds some useful context by linking plan_only and step to home_axes, but overall the schema carries the parameter semantics.

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: 'Move the print head somewhere safe, away from the plate, and leave it there.' It explicitly distinguishes park_head from its sibling home_axes by describing the retreat versus the measurement, so an agent can select it confidently.

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 gives explicit usage guidance: use this first on a machine you are nervous about, because it is the safer verb by construction and nothing descends. It also says to run it in steps the first time with a person beside the machine, and it names the alternative home_axes while explaining why park differs.

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