Skip to main content
Glama

arrange_parts_on_plate

Read-only

Packs multiple STL files onto a virtual build plate, arranges parts largest-first with configurable spacing, and reports which fit, which overflow, and plate utilization.

Instructions

Pack multiple STL files onto a virtual build plate.

        Uses greedy bottom-left bin-packing (largest parts first) to
        efficiently arrange parts with configurable spacing. Reports
        which parts fit, which overflow, and plate utilization.

        Supports printing multiple copies of parts via the copies parameter.

        :param file_paths: JSON array of file paths, e.g. ``["/tmp/a.stl", "/tmp/b.stl"]``.
        :param plate_width_mm: Build plate width in mm (default 256).
        :param plate_depth_mm: Build plate depth in mm (default 256).
        :param spacing_mm: Minimum gap between parts in mm (default 5).
        :param copies: Optional JSON dict of filename->count, e.g. ``{"part.stl": 3}``.
        :param printer_id: Optional supported printer model id, or the
            name of a printer set up in Kiln.  When provided, printer
            intelligence supplies the plate size.
            Keep passing it downstream — a later
            ``compose_multicolor_3mf`` without it judges the layout
            against a 256mm default plate.
        :returns: Dict with arranged_parts, overflow_parts, plate_utilization, summary.
        

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": {
      "file_paths": "<file_paths>"
    },
    "name": "arrange_parts_on_plate"
  }
}

Input Schema

NameRequiredDescriptionDefault
copiesNoOptional JSON dict of filename->count, e.g. ``{"part.stl": 3}``. Default: "".
file_pathsYesJSON array of file paths, e.g. ``["/tmp/a.stl", "/tmp/b.stl"]``.
printer_idNoOptional supported printer model id, or the name of a printer set up in Kiln. When provided, printer intelligence supplies the plate size. Keep passing it downstream — a later ``compose_multicolor_3mf`` without it judges the layout against a 256mm default plate. Default: "".
spacing_mmNoMinimum gap between parts in mm (default 5). Default: 5.0.
plate_depth_mmNoBuild plate depth in mm (default 256). Default: 256.0.
plate_width_mmNoBuild plate width in mm (default 256). Default: 256.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.1
    • changedInput schema / properties / copies / description
      Previous value: -"Default: \"\"."New value: +"Optional JSON dict of filename->count, e.g. ``{\"part.stl\": 3}``. Default: \"\"."
    • addedInput schema / properties / file_paths / description
      Added value: +"JSON array of file paths, e.g. ``[\"/tmp/a.stl\", \"/tmp/b.stl\"]``."
    • changedInput schema / properties / plate_depth_mm / description
      Previous value: -"Default: 256.0."New value: +"Build plate depth in mm (default 256). Default: 256.0."
    • changedInput schema / properties / plate_width_mm / description
      Previous value: -"Default: 256.0."New value: +"Build plate width in mm (default 256). Default: 256.0."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional supported printer model id, or the name of a printer set up in Kiln.  When provided, printer intelligence supplies the plate size. Keep passing it downstream — a later ``compose_multicolor_3mf`` without it judges the layout against a 256mm default plate. Default: \"\"."
    • changedInput schema / properties / spacing_mm / description
      Previous value: -"Default: 5.0."New value: +"Minimum gap between parts in mm (default 5). Default: 5.0."
  2. Changed10 schema fields changedv1.5.0
    • removedInput schema / properties / copies / default
      Removed value: -""
    • addedInput schema / properties / copies / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / plate_depth_mm / default
      Removed value: -256
    • addedInput schema / properties / plate_depth_mm / description
      Added value: +"Default: 256.0."
    • removedInput schema / properties / plate_width_mm / default
      Removed value: -256
    • addedInput schema / properties / plate_width_mm / description
      Added value: +"Default: 256.0."
    • removedInput schema / properties / printer_id / default
      Removed value: -""
    • addedInput schema / properties / printer_id / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / spacing_mm / default
      Removed value: -5
    • addedInput schema / properties / spacing_mm / description
      Added value: +"Default: 5.0."
  3. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

The description adds real behavior beyond annotations: the concrete packing algorithm, that overflow is reported rather than an error, and the contents of the return dict. Annotations already cover the safety profile (readOnly, non-destructive, not open-world). What is missing is whether anything is written to disk or whether the source STLs are modified — for a tool that produces an arrangement, that side-effect question is the remaining ambiguity.

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?

Purpose is front-loaded and the prose paragraphs are tight and informative. However, the :param: block duplicates the schema field-by-field, which is pure redundancy in a definition where the schema is already complete — that is where the excess length comes from.

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?

With six parameters, no output schema, and a computation-heavy operation, the definition covers the essentials: required input format, defaults, return keys, and the downstream printer_id contract. The only meaningful omission is disambiguation from the sibling auto_arrange_parts_on_plate.

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 coverage is 100% and the six parameters are fully documented in the input schema. The description's :param: block restates those same descriptions nearly verbatim, adding no formats, ranges, or constraints beyond the schema, so the baseline of 3 applies.

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?

"Pack multiple STL files onto a virtual build plate" gives a specific verb and resource, and the description adds the packing strategy (greedy bottom-left, largest first) and what it reports (fit/overflow/utilization). It stops short of differentiating from the near-identical sibling auto_arrange_parts_on_plate, so an agent cannot tell which of the two to pick from this text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: it notes that multiple copies are handled via the copies parameter and adds genuinely useful cross-call guidance that printer_id must be forwarded so a later compose_multicolor_3mf doesn't fall back to a 256mm plate. There is no statement of when to use this rather than auto_arrange_parts_on_plate, or any precondition such as parts needing valid geometry.

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