Skip to main content
Glama

paint_decoration_faces

Paints only the faces created by a decoration carve from its face-provenance sidecar, so carved strokes are colored while untouched enclosed areas remain base.

Instructions

Paint exactly the faces a decoration carve created (Pro-free).

        A deboss/emboss records which output triangles it created —
        recess floors and side-walls — in a face-provenance sidecar
        beside the decorated mesh.  This tool paints THOSE faces and
        nothing else, so a debossed logo with a closed outline (any
        mark with enclosed regions) colors only its carved strokes:
        the untouched surface island inside the outline stays the
        body color, where crease-angle segmentation would have
        "filled the logo in".

        Use after any decoration door (``decorate_surface``,
        ``apply_decoration``, ``apply_decoration_preset``,
        ``smart_decorate``, ``batch_decorate``…) — they all record
        the sidecar.  For meshes with no sidecar (older files,
        hand-made carves), fall back to ``segment_mesh_regions`` +
        ``paint_mesh_regions``.

        Writes a painted 3MF (one watertight object, per-triangle
        colors) via the same composer ``paint_mesh_regions`` uses,
        so the output slices identically.  A successful paint is
        also written back into the carve's face record (color,
        target, output file) so the design's provenance says
        "carved, then painted" — ``paint_recorded`` in the result
        reports whether that write-back landed.

        Says whether its colours are on the printer, as
        ``colour_availability`` (absent when Kiln cannot see what is
        loaded).  Relay its ``say`` as written and add nothing about
        filament: never suggest buying filament unless the person asks
        for one or says yes to the offer in ``say``.  On a yes, call
        ``find_closest_filaments`` with these colours and the print's
        material.

        :param model_path: The decorated mesh (STL/OBJ/3MF) whose
            ``<mesh>.decoration_faces.json`` sidecar to consume.
        :param color: Hex color for the carved faces (default red).
        :param base_color: Optional hex color for every other face.
            Empty = uncolored (renders neutral; slicer maps it to
            the base filament).
        :param target: ``"all"`` carved faces (default), or
            ``"floors"`` / ``"walls"`` when the record carries the
            split — floors are the recess bottoms (the visible mark),
            walls the carved sides.
        :param step_colors: Per-decoration colors for a chained
            carve, e.g. ``{"0": "#F72323", "1": "#FFFFFF"}`` — keys
            are step indices from the record's ``decorations`` list
            (every result of this tool lists them).  When given it
            is the COMPLETE paint spec: only the named steps are
            painted, the rest stay base — so "name red, title left
            plain" is one call.  Incompatible with a floors/walls
            ``target``; ``color`` is ignored.
        :param output_path: Where to write the painted 3MF.  Default:
            beside the model as ``<name>_painted.3mf``.
        :param material: Optional material the part will be printed in
            (e.g. ``"PETG"``).  A spool on record in a clearly
            different material is then not named as one to load.
        :param printer_id: Optional supported printer model id for
            bed placement of the composed 3MF.
        :returns: Dict with ``output_path``, ``painted_triangles``,
            ``total_triangles``, and the composer's color summary.
            Refuses loudly — no painting — when the sidecar is
            missing, malformed, or STALE (mesh content changed since
            the decoration was recorded).
        

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": {
      "model_path": "<model_path>"
    },
    "name": "paint_decoration_faces"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoHex color for the carved faces (default red). Default: "#F72323".
targetNo``"all"`` carved faces (default), or ``"floors"`` / ``"walls"`` when the record carries the split — floors are the recess bottoms (the visible mark), walls the carved sides. Default: "all".
materialNoOptional material the part will be printed in (e.g. ``"PETG"``). A spool on record in a clearly different material is then not named as one to load. Default: "".
base_colorNoOptional hex color for every other face. Empty = uncolored (renders neutral; slicer maps it to the base filament). Default: "".
model_pathYesThe decorated mesh (STL/OBJ/3MF) whose ``<mesh>.decoration_faces.json`` sidecar to consume.
printer_idNoOptional supported printer model id for bed placement of the composed 3MF. Default: "".
output_pathNoWhere to write the painted 3MF. Default: beside the model as ``<name>_painted.3mf``. Default: "".
step_colorsNoPer-decoration colors for a chained carve, e.g. ``{"0": "#F72323", "1": "#FFFFFF"}`` — keys are step indices from the record's ``decorations`` list (every result of this tool lists them). When given it is the COMPLETE paint spec: only the named steps are painted, the rest stay base — so "name red, title left plain" is one call. Incompatible with a floors/walls ``target``; ``color`` is ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • changedInput schema / properties / base_color / description
      Previous value: -"Default: \"\"."New value: +"Optional hex color for every other face. Empty = uncolored (renders neutral; slicer maps it to the base filament). Default: \"\"."
    • changedInput schema / properties / color / description
      Previous value: -"Default: \"#F72323\"."New value: +"Hex color for the carved faces (default red). Default: \"#F72323\"."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Optional material the part will be printed in (e.g. ``\"PETG\"``).  A spool on record in a clearly different material is then not named as one to load. Default: \"\"."
    • addedInput schema / properties / model_path / description
      Added value: +"The decorated mesh (STL/OBJ/3MF) whose ``<mesh>.decoration_faces.json`` sidecar to consume."
    • changedInput schema / properties / output_path / description
      Previous value: -"Default: \"\"."New value: +"Where to write the painted 3MF.  Default: beside the model as ``<name>_painted.3mf``. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional supported printer model id for bed placement of the composed 3MF. Default: \"\"."
    • addedInput schema / properties / step_colors / description
      Added value: +"Per-decoration colors for a chained carve, e.g. ``{\"0\": \"#F72323\", \"1\": \"#FFFFFF\"}`` — keys are step indices from the record's ``decorations`` list (every result of this tool lists them).  When given it is the COMPLETE paint spec: only the named steps are painted, the rest stay base — so \"name red, title left plain\" is one call.  Incompatible with a floors/walls ``target``; ``color`` is ignored."
    • changedInput schema / properties / target / description
      Previous value: -"Default: \"all\"."New value: +"``\"all\"`` carved faces (default), or ``\"floors\"`` / ``\"walls\"`` when the record carries the split — floors are the recess bottoms (the visible mark), walls the carved sides. Default: \"all\"."
  2. Addedv1.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing the write side-effects: it writes a painted 3MF, writes color/target/output back into the carve's face record (reported via paint_recorded), and returns colour_availability. It also documents the failure mode — "Refuses loudly — no painting — when the sidecar is missing, malformed, or STALE" — which the annotations cannot express.

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?

Front-loaded with the core behavior and the carve/logo rationale before prerequisites and parameters, so the reader gets the gist in the first two paragraphs. It is on the long side and duplicates the parameter descriptions that are already in the schema, but the filament/colour_availability paragraph is the only part that feels tangential to invoking the tool.

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?

Covers everything needed for an 8-parameter mutation with no output schema: inputs, the returns dict shape (output_path, painted_triangles, total_triangles), refusal conditions, and provenance write-back. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100% and the prose for color, base_color, target, step_colors, output_path, material, and printer_id essentially restates the schema text verbatim. The one piece of added relational meaning — step_colors is a COMPLETE paint spec, is incompatible with a floors/walls target, and makes color ignored — already appears in the schema entry. Baseline 3 is the correct ceiling here.

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 ("Paint exactly the faces a decoration carve created") plus a precise scope constraint ("THOSE faces and nothing else"), and names the alternative (segment_mesh_regions + paint_mesh_regions) for the no-sidecar case. An agent can distinguish this from siblings like paint_mesh_regions or segment_mesh_regions without opening a schema.

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

Usage Guidelines5/5

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

Explicitly names the prerequisite flow ("Use after any decoration door (decorate_surface, apply_decoration, apply_decoration_preset, smart_decorate, batch_decorate…)") and gives the when-not case ("For meshes with no sidecar (older files, hand-made carves), fall back to segment_mesh_regions + paint_mesh_regions"). This is a textbook either/or routing statement.

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