Skip to main content
Glama

multi_material_print

Destructive

Prints multiple objects in different materials or colors on one build plate, assigning each object its own filament and slicing for a compatible AMS printer.

Instructions

Print multiple objects in different materials/colors on one build plate.

**Only a printer Kiln drives can make this print** — today a Bambu with
an AMS.  At any other printer (a Klipper MMU Kiln can read but not
route, or a single-feed machine) a multi-filament plate is REFUSED
before slicing with code ``MULTI_MATERIAL_NOT_DRIVEN``: the objects
would all come out in one filament.  The refusal carries what Kiln saw
on the printer (``multi_material``) and the composed file
(``multi_material_3mf``), so the user can slice it in a slicer that
drives their unit.  A single-filament plate is never refused.

Takes a JSON array of objects, each with a model file and material
assignment. Builds a multi-material 3MF file with per-object filament
assignments, slices it, auto-maps materials to AMS slots, and prints.

This is how you print "object A in red PLA, object B in black PETG"
in a single print job.

Example: Print a bracket in PETG and a cover in PLA::

    multi_material_print(
        objects_json='[
            {"file_path": "/path/to/bracket.stl", "material_id": "petg"},
            {"file_path": "/path/to/cover.stl", "material_id": "pla"}
        ]',
        printer_name="my_bambu",
        printer_id="bambu_a1",
    )

Each object in the JSON array supports:
    - ``file_path`` (required): Path to STL/OBJ/GLB mesh file.
    - ``material_id`` (required): Material identifier (e.g. ``"petg"``).
    - ``name`` (optional): Display name for the object.
    - ``color`` (optional): Hex color override (e.g. ``"#FF0000"``).
    - ``group`` (optional): Objects sharing a group index are placed
      coincident (for meshes that share one coordinate space, like a
      body and its inlay). By default every object is its own group
      and gets its own spot on the plate.

The tool automatically:
    1. Looks up each material's properties (temps, colors)
    2. Arranges the objects side by side on the plate (per ``group``)
       and builds a multi-object 3MF with per-object material assignments
    3. Sets the plate for its materials: the hottest one's temperatures,
       the slowest one's melt rate, the gentlest cooling
    4. Checks AMS slots for matching materials
    5. Slices and prints with correct AMS mapping

Requires PrusaSlicer or OrcaSlicer installed locally.

The emitted 3MF (``multi_material_3mf`` in the result) also opens in
Bambu Studio, which keeps the per-object materials but re-derives
print settings itself — the result's ``slicer_note`` explains this;
relay it to the user when handing over the file.

Args:
    objects_json: JSON array of objects, each
        ``{"file_path": …, "material_id": …}`` (STL/OBJ/GLB path;
        material key such as ``"petg"``), with optional ``name``,
        ``color`` (hex) and ``group`` (objects sharing a group index
        are placed coincident).
    printer_name: Registered printer name in fleet.
    printer_id: Printer model ID for profile selection.
    auto_ams: Auto-detect AMS slot mapping (default ``True``).
    extra_overrides: Optional JSON object of slicer overrides merged on
        top of the material settings (e.g.
        ``'{"fill_density": "30%"}'``).
    slicer_path: Explicit path to slicer binary.
    preview_token: Token from ``issue_preview_token`` proving the plate
        was shown to the person before printing.  Required beside their
        go-ahead: a print is shown to its owner before it starts.

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": {
      "objects_json": "<objects_json>"
    },
    "name": "multi_material_print"
  }
}

Input Schema

NameRequiredDescriptionDefault
auto_amsNoAuto-detect AMS slot mapping (default ``True``). Default: true.
printer_idNoPrinter model ID for profile selection.
slicer_pathNoExplicit path to slicer binary.
objects_jsonYesJSON array of objects, each ``{"file_path": …, "material_id": …}`` (STL/OBJ/GLB path; material key such as ``"petg"``), with optional ``name``, ``color`` (hex) and ``group`` (objects sharing a group index are placed coincident).
printer_nameNoRegistered printer name in fleet.
preview_tokenNoToken from ``issue_preview_token`` proving the plate was shown to the person before printing. Required beside their go-ahead: a print is shown to its owner before it starts.
extra_overridesNoOptional JSON object of slicer overrides merged on top of the material settings (e.g. ``'{"fill_density": "30%"}'``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.5.1
    • changedInput schema / properties / auto_ams / description
      Previous value: -"Default: true."New value: +"Auto-detect AMS slot mapping (default ``True``). Default: true."
    • addedInput schema / properties / extra_overrides / description
      Added value: +"Optional JSON object of slicer overrides merged on top of the material settings (e.g. ``'{\"fill_density\": \"30%\"}'``)."
    • addedInput schema / properties / objects_json / description
      Added value: +"JSON array of objects, each ``{\"file_path\": …, \"material_id\": …}`` (STL/OBJ/GLB path; material key such as ``\"petg\"``), with optional ``name``, ``color`` (hex) and ``group`` (objects sharing a group index are placed coincident)."
    • addedInput schema / properties / preview_token / description
      Added value: +"Token from ``issue_preview_token`` proving the plate was shown to the person before printing.  Required beside their go-ahead: a print is shown to its owner before it starts."
    • addedInput schema / properties / printer_id / description
      Added value: +"Printer model ID for profile selection."
    • addedInput schema / properties / printer_name / description
      Added value: +"Registered printer name in fleet."
    • addedInput schema / properties / slicer_path / description
      Added value: +"Explicit path to slicer binary."
  2. Changed10 schema fields changedv1.5.0
    • removedInput schema / properties / auto_ams / default
      Removed value: -true
    • addedInput schema / properties / auto_ams / description
      Added value: +"Default: true."
    • changedInput schema / properties / extra_overrides / anyOf
      Previous value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "additionalProperties": true,
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • removedInput schema / properties / extra_overrides / default
      Removed value: -null
    • addedInput schema / properties / objects_json / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "items": {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    "type": "array"
      +  }
      +]
    • removedInput schema / properties / objects_json / type
      Removed value: -"string"
    • addedInput schema / properties / preview_token
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "title": "Preview Token"
      +}
    • removedInput schema / properties / printer_id / default
      Removed value: -null
    • removedInput schema / properties / printer_name / default
      Removed value: -null
    • removedInput schema / properties / slicer_path / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: it names the refusal code MULTI_MATERIAL_NOT_DRIVEN, states which keys the refusal returns (multi_material, multi_material_3mf), documents the five automatic steps (material lookup, plate arrangement, thermal/cooling selection, AMS slot matching, slicing), and warns that the emitted 3MF re-derives settings in Bambu Studio with a slicer_note to relay. The destructiveHint=true annotation is consistent with an operation that physically prints.

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 critical constraint and purpose are correctly front-loaded, but the definition is bloated by duplication: the objects_json fields are enumerated in prose and then again in the Args block, and every Args entry repeats the schema verbatim. Trimming the Args section would lose nothing.

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 7-parameter mutation with no output schema, the description covers what an agent needs: the failure mode and its error code, the returned file keys, the preview_token consent requirement, slicer dependency, and per-object field semantics. Nothing material is missing.

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 prose adds real meaning the schema does not: it explains that objects sharing a 'group' index are placed coincident and that by default every object is its own group with its own plate spot, plus a worked example of the full objects_json payload. The remaining Args entries largely restate the schema descriptions.

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?

Opens with a specific verb+resource+scope: 'Print multiple objects in different materials/colors on one build plate,' and immediately disambiguates from single-filament paths ('A single-filament plate is never refused'). An agent can tell this apart from siblings like print_plate_object, multi_copy_print, or slice_and_print without opening any schema.

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?

Gives concrete when-to-use conditions and hard prerequisites: only a Kiln-driven printer (Bambu with AMS) can run it, other machines are refused, and PrusaSlicer/OrcaSlicer must be installed. It does not name alternative tools for the fallback case (e.g. what to call instead when the printer lacks AMS), so it stops short of explicit routing.

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