Skip to main content
Glama

auto_color_by_height

Split a 3D model into equal horizontal color bands by Z-height, cutting and capping faces at each boundary to produce closed per-zone STLs and a multicolor 3MF ready for AMS/MMU printing.

Instructions

Split a 3D model into horizontal color zones by Z-height.

        Divides the model's height into N equal bands.  Faces that
        cross a band edge are cut exactly at it, so the line where two
        colors meet is the straight horizontal line the bands name —
        never a sawtooth of whole faces, on any tessellation.  The
        cut faces are capped at the band planes, so each zone of a
        closed model is itself a closed solid ready to slice.
        Produces separate STL files per zone and (if available) a
        multicolor 3MF ready for AMS/MMU printers.

        Zero cloud dependencies — pure geometry.

        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 input_path: Path to a binary STL file.
        :param num_colors: Number of color zones (default 4).
        :param color_palette: List of hex colors (e.g.
            ``["#FF0000", "#00FF00"]``).  Defaults to white/red/black/grey.
        :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.  Names
            the bed the composed 3MF is placed on, so a model sitting
            off the plate is centred on the machine's real bed rather
            than an assumed 256mm one.
        :returns: Dict with zone STL paths, hex colors, face counts
            (boundary faces are cut and capped, so counts can exceed
            the input's), per-zone ``watertight`` verdicts, AMS slot
            mapping, weight estimates, and optional 3MF path.

INLINE 3D STAGE: on success this tool opens Kiln's interactive 3D stage — an inline viewer panel the user can orbit, zoom, and turn over — in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't). Oversized meshes are decimated automatically for the stage; the PNG preview is the floor, not the whole experience.

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": {
      "input_path": "<input_path>"
    },
    "name": "auto_color_by_height"
  }
}

Input Schema

NameRequiredDescriptionDefault
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: "".
input_pathYesPath to a binary STL file.
num_colorsNoNumber of color zones (default 4). Default: 4.
printer_idNoOptional supported printer model id. Names the bed the composed 3MF is placed on, so a model sitting off the plate is centred on the machine's real bed rather than an assumed 256mm one. Default: "".
color_paletteNoList of hex colors (e.g. ``["#FF0000", "#00FF00"]``). Defaults to white/red/black/grey.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • addedInput schema / properties / color_palette / description
      Added value: +"List of hex colors (e.g. ``[\"#FF0000\", \"#00FF00\"]``).  Defaults to white/red/black/grey."
    • addedInput schema / properties / input_path / description
      Added value: +"Path to a binary STL file."
    • 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: \"\"."
    • changedInput schema / properties / num_colors / description
      Previous value: -"Default: 4."New value: +"Number of color zones (default 4). Default: 4."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional supported printer model id.  Names the bed the composed 3MF is placed on, so a model sitting off the plate is centred on the machine's real bed rather than an assumed 256mm one. Default: \"\"."
  2. Changed5 schema fields changedv1.5.0
    • removedInput schema / properties / color_palette / default
      Removed value: -null
    • addedInput schema / properties / material
      Added value: +{
      +  "description": "Default: \"\".",
      +  "title": "Material",
      +  "type": "string"
      +}
    • removedInput schema / properties / num_colors / default
      Removed value: -4
    • addedInput schema / properties / num_colors / description
      Added value: +"Default: 4."
    • addedInput schema / properties / printer_id
      Added value: +{
      +  "description": "Default: \"\".",
      +  "title": "Printer Id",
      +  "type": "string"
      +}
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=false, openWorld=false; the description goes well beyond that by explaining the exact cut-and-cap geometry, that each zone of a closed model is itself a closed watertight solid, that it writes files to disk, that it runs with zero cloud dependencies, and that it opens an inline 3D stage with automatic decimation. It also discloses a downstream workflow constraint (relay the colour_availability 'say' verbatim; only call find_closest_filaments on a yes).

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 purpose and behavioral core are front-loaded and well ordered, but the definition is long and the :param block duplicates the schema nearly verbatim, which is dead weight. The filament-relay and stage paragraphs are useful but could be tightened.

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 mesh-mutation tool with no output schema, the description fully specifies the return contract (zone STL paths, hex colors, face counts that may exceed the input's, per-zone watertight verdicts, AMS slot mapping, weight estimates, optional 3MF path) and explains why counts differ. Nothing an agent needs to invoke or interpret the result 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%, so the schema already documents every parameter. The description's :param block largely reproduces those same descriptions, adding only light rationale (why printer_id matters — real bed vs. assumed 256mm; why material matters — suppressing mismatched spool suggestions). Baseline 3 is appropriate since the schema does the heavy lifting.

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 first line states a specific verb and resource — split a 3D model into horizontal color zones by Z-height — and the following sentence pins the mechanism (N equal bands, faces cut exactly at band edges). This is clearly distinguishable from the sibling auto_color_by_region, since the organizing axis (Z vs. region) is explicit.

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

Usage Guidelines3/5

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

The description makes the context of use clear (per-zone STLs plus a multicolor 3MF for AMS/MMU printers), so an agent can infer when this is the right tool. It never explicitly says when not to use it or names auto_color_by_region as the alternative for non-height-based coloring, so routing is implied rather than 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