Skip to main content
Glama

merge_multicolor_gcode

Merge separately sliced g-code files into one multi-tool file, batching layers to reduce tool changes for multi-color 3D prints on XY-disjoint parts.

Instructions

Merge separately-sliced gcode files into one multi-tool gcode.

Uses a batched strategy that minimises tool changes for multi-color
prints.  Parts with overlapping Z ranges are printed in tool order
within the overlap zone, then remaining layers continue above.

This is the key step between slicing individual parts and wrapping
as a Bambu 3MF.  The merged gcode contains T0/T1/... tool change
commands that ``wrap_gcode_as_3mf`` converts to M620/M621 AMS
load sequences.

**Precondition:** Parts must be **XY-disjoint** (non-overlapping
footprints on the build plate).  The batched merge prints each
tool's layers independently in the overlap zone — overlapping XY
regions will cause collisions.

Args:
    parts: JSON array of part objects.  Each must have:

        - ``gcode_path``: Path to the sliced ``.gcode`` file.
        - ``tool_index``: Tool number (0, 1, ...) for AMS mapping.
        - ``name``: Human-readable name (e.g. ``"body_grey"``).

        Example::

            [
              {"gcode_path": "/path/body.gcode", "tool_index": 0, "name": "body"},
              {"gcode_path": "/path/qr.gcode", "tool_index": 1, "name": "qr_pads"}
            ]

    output_path: Output file path.  Defaults to a temp directory.

Returns a dict with ``output_path``, merge phases, layer count,
and estimated print time.

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": {
      "parts": "<parts>"
    },
    "name": "merge_multicolor_gcode"
  }
}

Input Schema

NameRequiredDescriptionDefault
partsYesJSON array of part objects. Each must have: - ``gcode_path``: Path to the sliced ``.gcode`` file. - ``tool_index``: Tool number (0, 1, ...) for AMS mapping. - ``name``: Human-readable name (e.g. ``"body_grey"``). Example:: [ {"gcode_path": "/path/body.gcode", "tool_index": 0, "name": "body"}, {"gcode_path": "/path/qr.gcode", "tool_index": 1, "name": "qr_pads"} ]
output_pathNoOutput file path. Defaults to a temp directory. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • changedInput schema / properties / output_path / description
      Previous value: -"Default: \"\"."New value: +"Output file path.  Defaults to a temp directory. Default: \"\"."
    • addedInput schema / properties / parts / description
      Added value: +"JSON array of part objects.  Each must have: - ``gcode_path``: Path to the sliced ``.gcode`` file. - ``tool_index``: Tool number (0, 1, ...) for AMS mapping. - ``name``: Human-readable name (e.g. ``\"body_grey\"``). Example:: [ {\"gcode_path\": \"/path/body.gcode\", \"tool_index\": 0, \"name\": \"body\"}, {\"gcode_path\": \"/path/qr.gcode\", \"tool_index\": 1, \"name\": \"qr_pads\"} ]"
  2. Changed4 schema fields changedv1.5.0
    • removedInput schema / properties / output_path / default
      Removed value: -""
    • addedInput schema / properties / output_path / description
      Added value: +"Default: \"\"."
    • addedInput schema / properties / parts / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "items": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "type": "array"
      +  }
      +]
    • removedInput schema / properties / parts / type
      Removed value: -"string"
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare only the safety profile (non-read-only, non-destructive, closed-world), so the description carries the real explanation: a batched strategy that minimizes tool changes, tool-order printing in overlapping Z zones with remaining layers above, and the XY-disjoint precondition that prevents collisions. It also discloses that output contains T0/T1 changes that wrap_gcode_as_3mf later converts to M620/M621 AMS sequences, which is exactly the kind of consequence an agent needs.

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?

The opening sentence and pipeline positioning are front-loaded, and the bolded precondition is easy to scan. The Args block and the JSON example duplicate the input schema nearly verbatim, which is wasted length for an agent that already receives the schema, but the prose itself is dense and non-repetitive.

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?

With no output schema, the description supplies the return shape (output_path, merge phases, layer count, estimated print time). Combined with the pipeline position and the collision precondition, an agent has everything needed to call this correctly and interpret the result.

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%, so the baseline is 3, but the description adds real meaning: gcode_path is the sliced .gcode, tool_index maps to AMS tool numbering, and name is human-readable only. The output_path default to a temp directory is also restated. The worked example duplicates the schema description rather than extending it, so it stops short of 5.

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?

States a specific verb and resource: merging separately-sliced gcode files into one multi-tool gcode. It also positions itself in the pipeline (the step between slicing individual parts and wrapping as a 3MF), which distinguishes it from slice_model, wrap_gcode_as_3mf, and merge_mesh_files.

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 names the downstream tool (wrap_gcode_as_3mf) and gives a hard precondition: parts must be XY-disjoint or collisions occur. That is effectively a when-not-to-use rule. It does not compare against the sibling compose_multicolor_3mf, which an agent could plausibly confuse with this end-to-end path, and no note on part count or tool limits is given.

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