Skip to main content
Glama

auto_arrange_parts_on_plate

Read-only

Calculates non-overlapping XY positions for multiple parts on a print plate, placing grouped multicolor parts at the same XY, so separate objects can be arranged for one print job.

Instructions

Calculate non-overlapping XY positions for multiple parts on a print plate.

        Use this **before** :func:`compose_multicolor_3mf` when you have multiple
        separate objects (e.g., two coasters) to print in one job.  Parts that
        share the same ``group`` index are treated as a multi-color unit and
        placed at the *same* XY position (they overlap intentionally).

        Returns a list of positioned part specs ready to pass directly to
        ``compose_multicolor_3mf`` — pass the SAME ``printer_id`` to that
        call: the composer re-centres a group it judges off ITS plate
        (256mm by default), so composing a layout packed for a different
        bed without the printer undoes this placement.

        Arrangement strategy (free tier): simple left-to-right row layout.  For
        maximum plate density (2D bin-packing), use kiln-pro.

        Example -- two coasters, each with a body + QR layer::

            positioned = auto_arrange_parts_on_plate(part_specs=[
                {"stl_path": "/tmp/c1_body.stl", "extruder": 1, "group": 0, "material": "PLA Grey"},
                {"stl_path": "/tmp/c1_qr.stl",   "extruder": 2, "group": 0, "material": "PLA Black"},
                {"stl_path": "/tmp/c2_body.stl",  "extruder": 1, "group": 1, "material": "PLA Grey"},
                {"stl_path": "/tmp/c2_qr.stl",    "extruder": 2, "group": 1, "material": "PLA Black"},
            ], plate_width=256, plate_depth=256, gap_mm=5)
            # -> each part now has "x", "y" set; pass to compose_multicolor_3mf

        Args:
            part_specs: List of dicts, each with:

                * ``stl_path`` (str) -- absolute path to the STL
                * ``extruder`` (int) -- 1-indexed AMS slot
                * ``group`` (int, optional) -- parts sharing a group get the same
                  XY position (multi-color unit).  Default: each part is its own group.
                * ``name`` (str, optional) -- label in slicer
                * ``color`` (str, optional) -- hex preview color
                * ``material`` (str, optional) -- filament label (also triggers
                  compatibility checks when passed to compose_multicolor_3mf)

            plate_width: Print plate X dimension in mm (default 256);
                replaced by the printer's own plate when ``printer_id``
                is given.
            plate_depth: Print plate Y dimension in mm (default 256);
                replaced by the printer's own plate when ``printer_id``
                is given.
            gap_mm: Minimum spacing between groups in mm.
            printer_id: Optional printer: a supported model id, or the
                name of a printer set up in Kiln.  When provided, its
                recorded plate size replaces the explicit dimensions.

        Returns:
            Dict with ``success``, ``parts`` list (each part has ``x``, ``y`` set),
            ``group_count``, ``fits_bed`` (``False`` when the rows run past
            the bed: the message then gives the layout's size, the bed's, and
            what to do, instead of the next step), ``bed_fit``, and
            ``message``.
        

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "part_specs": "<part_specs>"
    },
    "name": "auto_arrange_parts_on_plate"
  }
}

Input Schema

NameRequiredDescriptionDefault
gap_mmNoMinimum spacing between groups in mm. Default: 5.0.
part_specsYesList of dicts, each with: * ``stl_path`` (str) -- absolute path to the STL * ``extruder`` (int) -- 1-indexed AMS slot * ``group`` (int, optional) -- parts sharing a group get the same XY position (multi-color unit). Default: each part is its own group. * ``name`` (str, optional) -- label in slicer * ``color`` (str, optional) -- hex preview color * ``material`` (str, optional) -- filament label (also triggers compatibility checks when passed to compose_multicolor_3mf)
printer_idNoOptional printer: a supported model id, or the name of a printer set up in Kiln. When provided, its recorded plate size replaces the explicit dimensions. Default: "".
plate_depthNoPrint plate Y dimension in mm (default 256); replaced by the printer's own plate when ``printer_id`` is given. Default: 256.0.
plate_widthNoPrint plate X dimension in mm (default 256); replaced by the printer's own plate when ``printer_id`` is given. Default: 256.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • changedInput schema / properties / gap_mm / description
      Previous value: -"Default: 5.0."New value: +"Minimum spacing between groups in mm. Default: 5.0."
    • addedInput schema / properties / part_specs / description
      Added value: +"List of dicts, each with: * ``stl_path`` (str) -- absolute path to the STL * ``extruder`` (int) -- 1-indexed AMS slot * ``group`` (int, optional) -- parts sharing a group get the same XY position (multi-color unit).  Default: each part is its own group. * ``name`` (str, optional) -- label in slicer * ``color`` (str, optional) -- hex preview color * ``material`` (str, optional) -- filament label (also triggers compatibility checks when passed to compose_multicolor_3mf)"
    • changedInput schema / properties / plate_depth / description
      Previous value: -"Default: 256.0."New value: +"Print plate Y dimension in mm (default 256); replaced by the printer's own plate when ``printer_id`` is given. Default: 256.0."
    • changedInput schema / properties / plate_width / description
      Previous value: -"Default: 256.0."New value: +"Print plate X dimension in mm (default 256); replaced by the printer's own plate when ``printer_id`` is given. Default: 256.0."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional printer: a supported model id, or the name of a printer set up in Kiln.  When provided, its recorded plate size replaces the explicit dimensions. Default: \"\"."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / gap_mm / default
      Removed value: -5
    • addedInput schema / properties / gap_mm / description
      Added value: +"Default: 5.0."
    • removedInput schema / properties / plate_depth / default
      Removed value: -256
    • addedInput schema / properties / plate_depth / description
      Added value: +"Default: 256.0."
    • removedInput schema / properties / plate_width / default
      Removed value: -256
    • addedInput schema / properties / plate_width / description
      Added value: +"Default: 256.0."
    • removedInput schema / properties / printer_id / default
      Removed value: -""
    • addedInput schema / properties / printer_id / description
      Added value: +"Default: \"\"."
  3. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond that: the free-tier arrangement strategy is left-to-right rows, groups intentionally overlap at the same XY, and fits_bed=False returns a diagnostic message instead of the next step. It also warns that the composer re-centres against ITS plate (256mm default), which is a real cross-tool failure mode not captured anywhere else.

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?

Well front-loaded: purpose first, then when-to-use, then strategy, then a concrete worked example. The Args block largely restates the schema descriptions, which is redundant bulk, but the example and the printer_id warning both earn their space.

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?

There is no output schema, so the description carries the return-value burden and does so fully: success, parts with x/y, group_count, fits_bed, bed_fit, and message. Combined with the sequencing contract into compose_multicolor_3mf, an agent has everything needed to call and consume this correctly.

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% and the part_specs text is nearly verbatim duplicated from the schema, so much of the Args block adds little. What does add meaning is the cross-parameter interaction: printer_id replaces the explicit plate_width/plate_depth, and the same printer_id must be passed to the composer or the placement is undone.

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 first sentence states a specific verb and resource: computing non-overlapping XY positions for multiple parts on a print plate. It also clarifies the group-overlap semantics, which distinguishes it from a naive placement tool. It does not, however, distinguish itself from the very similarly named sibling 'arrange_parts_on_plate', which an agent could easily confuse it with.

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 explicit sequencing guidance: use this BEFORE compose_multicolor_3mf when printing multiple separate objects, and it names kiln-pro as the alternative for maximum density bin-packing. The remaining gap is that the near-identical sibling 'arrange_parts_on_plate' is never mentioned, so the agent gets no help choosing between the two.

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