Skip to main content
Glama

multi_material_print

Print multiple 3D objects with different materials or colors on one build plate, assigning each model its own material and slicing automatically.

Instructions

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

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. Generates merged slicer overrides (uses the highest-temp material)
    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 with ``file_path`` and
        ``material_id`` keys (see example above).
    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: Additional slicer overrides JSON.
    slicer_path: Explicit path to slicer binary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auto_amsNo
printer_idNo
slicer_pathNo
objects_jsonYes
printer_nameNo
extra_overridesNo
Install Server

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly explains the automatic steps (material lookup, arrangement, slicer overrides, AMS slot checking, slicing/printing) and clearly notes the requirement for PrusaSlicer or OrcaSlicer locally. It even discloses the Bambu Studio compatibility nuance and the slicer_note field, which is exceptional transparency for a complex operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every section earns its place: the intro, example, object field specification, automated steps, prerequisites, and args list are all directly useful. The use of code blocks and bullets enhances readability without being redundant. It is well-structured for a tool with this complexity.

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 multi-step tool with no output schema, the description is remarkably complete. It covers prerequisites, parameter details, the exact JSON structure, the automated pipeline, output fields (multi_material_3mf, slicer_note), and even how to handle the artifacts (relay slicer_note to the user). The content fully equips an agent to invoke the tool correctly and understand the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates with a dedicated Args section and an in-depth explanation of the objects_json structure, including required and optional fields with examples. It goes beyond the schema's bare type definitions by explaining the meaning and usage of every parameter, including the group behavior for coincident placement.

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 clear statement of purpose: 'Print multiple objects in different materials/colors on one build plate.' It then elaborates with a concrete example ('object A in red PLA, object B in black PETG'), making the tool's function unmistakable. This distinguishes it from siblings like multi_copy_print or multi_color_copies by focusing on per-object material assignment.

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?

The description explicitly states a use case ('This is how you print...') and walks through the process step by step. It doesn't explicitly list alternatives or exclusions, but the context is clear enough for an agent to select this tool when multi-material per-object printing is needed. The detailed example and prerequisites add practical guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server