Skip to main content
Glama

paint_decoration_faces

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

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).
        

Input Schema

NameRequiredDescriptionDefault
colorNoDefault: "#F72323".
targetNoDefault: "all".
materialNoDefault: "".
base_colorNoDefault: "".
model_pathYes
printer_idNoDefault: "".
output_pathNoDefault: "".
step_colorsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the 3MF write, the write-back into the carve's face record (paint_recorded), the loud refusal on missing/malformed/STALE sidecars, and the colour_availability/say relay contract. That is well beyond what a name implies.

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 in the first sentence and organized by concern, but it runs long and the filament/'say' relay paragraph is somewhat tangential to the painting task. Dense and mostly earning its place, yet trimmable.

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 an eight-parameter mutation tool with no output schema, the description covers inputs, the return dict keys, failure modes, and side effects, leaving nothing an agent needs to call it correctly.

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 coverage is 75% and mostly bare titles/defaults, but the description documents all eight parameters with meaning: what model_path's sidecar is, that target accepts 'all'/'floors'/'walls' (enum values absent from the schema), and that step_colors is a complete paint spec keyed by step index with a worked example. It adds substantially beyond the schema.

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 precise verb+resource and scope: paints exactly the faces a decoration carve created, nothing else. It also contrasts with the alternative behavior (crease-angle segmentation would 'fill the logo in'), so an agent can tell exactly what makes this tool distinct from segment_mesh_regions/paint_mesh_regions.

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 upstream tools it should follow (decorate_surface, apply_decoration, apply_decoration_preset, smart_decorate, batch_decorate) and the exact fallback condition (meshes with no sidecar → segment_mesh_regions + paint_mesh_regions). Both when-to-use and when-not-to-use are stated.

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