Skip to main content
Glama

list_multi_material_addons

Read-only

Lists multi-material add-on systems for 3D printers with tool change times, color capacity, and compatibility. Filter by printer model to find add-ons that enable multi-color printing.

Instructions

List available multi-material add-on systems for 3D printers.

        Returns a catalog of optional multi-material add-ons (Creality CFS,
        Mosaic Palette, Co Print KCM, 3D Chameleon, Elegoo CANVAS) with
        their tool change times, color capacity, and compatibility info.

        When a ``printer_id`` is provided, only add-ons compatible with
        that printer are returned.  Universal add-ons (Palette, Chameleon)
        appear for all printers.  Klipper-only add-ons (KCM) appear only
        for Klipper-based printers.

        Use the returned ``id`` values as the ``tool_changer_addon``
        parameter in ``estimate_before_design`` to model multi-material
        prints on printers that don't have a built-in tool changer.

        :param printer_id: Optional printer model to filter by compatibility
            (e.g. ``"k1"``, ``"ender3"``, ``"voron_2"``).
        

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_multi_material_addons"
  }
}

Input Schema

NameRequiredDescriptionDefault
printer_idNoOptional printer model to filter by compatibility (e.g. ``"k1"``, ``"ender3"``, ``"voron_2"``). Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional printer model to filter by compatibility (e.g. ``\"k1\"``, ``\"ender3\"``, ``\"voron_2\"``). Default: \"\"."
  2. Changed2 schema fields changedv1.5.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
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses real behavioral detail: the returned fields (tool change times, color capacity, compatibility) and the non-obvious filtering rule that universal add-ons appear for all printers while Klipper-only add-ons (KCM) appear only for Klipper-based printers. It does not mention ordering, pagination, or empty-result behavior, which keeps it short of a 5.

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?

Structure is front-loaded and logical: purpose, then return payload, then filtering behavior, then downstream usage. The only waste is the final ':param printer_id' paragraph, which restates the input-schema description almost verbatim and could be dropped without losing information.

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 one optional parameter and no output schema, the description carries the burden of describing returns, and it does so explicitly (catalog entries with tool change times, color capacity, compatibility). Combined with the annotations and full schema coverage, an agent has everything needed to call and interpret it; only minor details like result ordering or whether the catalog is static are absent.

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. The description nevertheless adds meaning beyond the schema's example list: it explains that omitting printer_id returns everything, that universal add-ons are unaffected by the filter, and that Klipper-only add-ons are gated by the printer's firmware family. The trailing ':param' block largely repeats the schema text, but the filtering semantics are genuinely new.

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 specific verb and resource ('List available multi-material add-on systems for 3D printers') and then enumerates the concrete catalog contents (Creality CFS, Mosaic Palette, Co Print KCM, 3D Chameleon, Elegoo CANVAS). No sibling tool in the list returns multi-material add-on catalogs, so the scope is unambiguous without opening the 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?

It clearly explains the two calling modes (no printer_id = full catalog, printer_id = compatibility-filtered) and states the downstream purpose: feed returned ids into estimate_before_design's tool_changer_addon parameter. It does not name any alternative tool to use instead, so there is no explicit when-not guidance, but the workflow context is concrete enough to select the tool confidently.

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