Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

smart_decorate

Decorate STL models with text, images, or QR codes, automatically adjust depth for printability, and preview the result in an interactive 3D stage.

Instructions

Intelligent decoration with auto-fix for printability (Pro). Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link).

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

Input Schema

NameRequiredDescriptionDefault
faceNoWhich face to decorate. ``"auto"`` (default) picks the largest flat face; also ``"top"``, ``"bottom"``, ``"front"``, ``"back"``, ``"left"``, ``"right"``, a sketch-built part's own wall name (``"side:l2"``), or ``"wall"`` to wrap text or a line-art mark around the round wall of a cup, jar or vase. Default: "auto".
modeNo``"deboss"`` (cut in, default) or ``"emboss"`` (raised). ``face="wall"`` is deboss only. Default: "deboss".
scaleNoShare of the face the decoration covers, 0.0-1.0 (default 0.7). A QR too small to scan at this scale is enlarged. Default: 0.7.
contentYesWhat to put on the surface: an image or SVG path, ``"text:..."`` for text, or ``"qr:..."`` for a QR code.
depth_mmNoEmboss/deboss depth in mm. 0 (default) picks a depth for *material*; a depth too shallow for it is raised and said. Default: 0.0.
materialNoMaterial the depth is judged for (default ``"PLA"``). Default: "PLA".
model_pathYesPath to the STL model to decorate.
image_styleNo``face="wall"`` only: ``"stencil"`` or ``"logo"`` to carve an image as a line-art mark; ``"auto"`` (default) tells a mark from a photo by looking. Default: "auto".
offset_x_mmNoMove the decoration across the face, in mm (default 0). Default: 0.0.
offset_y_mmNoMove the decoration along the face, in mm (default 0). Default: 0.0.
content_typeNo``"auto"`` (default, read from *content*), or ``"text"``, ``"qr"``, ``"svg"``, ``"image"``. Default: "auto".
absolute_size_mmNo``face="wall"`` only: the size in mm instead of a share of the wall (letter height for text, width for a mark). 0 (default) uses *scale*. Default: 0.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.5.1
    • changedInput schema / properties / absolute_size_mm / description
      Previous value: -"Default: 0.0."New value: +"``face=\"wall\"`` only: the size in mm instead of a share of the wall (letter height for text, width for a mark). 0 (default) uses *scale*. Default: 0.0."
    • addedInput schema / properties / content / description
      Added value: +"What to put on the surface: an image or SVG path, ``\"text:...\"`` for text, or ``\"qr:...\"`` for a QR code."
    • changedInput schema / properties / content_type / description
      Previous value: -"Default: \"auto\"."New value: +"``\"auto\"`` (default, read from *content*), or ``\"text\"``, ``\"qr\"``, ``\"svg\"``, ``\"image\"``. Default: \"auto\"."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 0.0."New value: +"Emboss/deboss depth in mm.  0 (default) picks a depth for *material*; a depth too shallow for it is raised and said. Default: 0.0."
    • changedInput schema / properties / face / description
      Previous value: -"Default: \"auto\"."New value: +"Which face to decorate.  ``\"auto\"`` (default) picks the largest flat face; also ``\"top\"``, ``\"bottom\"``, ``\"front\"``, ``\"back\"``, ``\"left\"``, ``\"right\"``, a sketch-built part's own wall name (``\"side:l2\"``), or ``\"wall\"`` to wrap text or a line-art mark around the round wall of a cup, jar or vase. Default: \"auto\"."
    • changedInput schema / properties / image_style / description
      Previous value: -"Default: \"auto\"."New value: +"``face=\"wall\"`` only: ``\"stencil\"`` or ``\"logo\"`` to carve an image as a line-art mark; ``\"auto\"`` (default) tells a mark from a photo by looking. Default: \"auto\"."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Material the depth is judged for (default ``\"PLA\"``). Default: \"PLA\"."
    • changedInput schema / properties / mode / description
      Previous value: -"Default: \"deboss\"."New value: +"``\"deboss\"`` (cut in, default) or ``\"emboss\"`` (raised). ``face=\"wall\"`` is deboss only. Default: \"deboss\"."
    • addedInput schema / properties / model_path / description
      Added value: +"Path to the STL model to decorate."
    • changedInput schema / properties / offset_x_mm / description
      Previous value: -"Default: 0.0."New value: +"Move the decoration across the face, in mm (default 0). Default: 0.0."
    • changedInput schema / properties / offset_y_mm / description
      Previous value: -"Default: 0.0."New value: +"Move the decoration along the face, in mm (default 0). Default: 0.0."
    • changedInput schema / properties / scale / description
      Previous value: -"Default: 0.7."New value: +"Share of the face the decoration covers, 0.0-1.0 (default 0.7).  A QR too small to scan at this scale is enlarged. Default: 0.7."
  2. Addedv1.5.0

TDQS

C2.7/5.0
Behavior3/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) the description does add real behavior: auto-fix for printability, automatic decimation of oversized meshes for the stage, and a forced browser stage link for non-panel hosts. However it omits the behavior that matters for a mutation tool — whether the source STL is modified in place or a new file is produced, and where that result lives. The stage detail is repeated twice rather than expanding coverage.

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

Conciseness2/5

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

The purpose is front-loaded in one sentence, but the two following paragraphs are an all-caps-headed section that restates the same fact ('opens Kiln's interactive 3D stage') twice with parenthetical hosts detail. Roughly two-thirds of the text is spent on viewer UX instead of the tool's operation, which buries the useful signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, no output schema, and a write operation, the description should at minimum state what artifact comes back (decorated model path plus preview) and whether the original is overwritten. It partly covers the output via 'the PNG preview is the floor', but the decorated mesh handoff and Pro/tier prerequisites remain unexplained.

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% with 12 well-documented parameters (face, mode, scale, depth/material, wall handling, etc.), so the schema carries the semantics. The description adds nothing about any parameter — not even the required model_path/content pair — which is acceptable at full coverage but earns only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line 'Intelligent decoration with auto-fix for printability' gestures at the function, but 'intelligent decoration' largely restates the tool name and never states concretely that it carves/raises text, QR codes, images or SVGs onto an STL — that detail only appears in the schema. It also fails to differentiate itself from the many decoration siblings (apply_decoration, decorate_surface, batch_decorate, generate_qr_decoration, preview_decorated_mesh). Most of the body is spent on the 3D stage rather than the core operation.

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

Usage Guidelines2/5

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

There is no guidance on when to choose this over sibling decoration tools, when not to use it, or what the '(Pro)' tag implies operationally (tier gate, quota). The only implicit constraint is that a hosted-vs-MCP-Apps host changes what stage you get, which is about presentation, not selection.

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