Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

preview_decorated_mesh

Render an interactive 3D preview of a mid-print decorated part, with orbit and zoom controls plus a PNG snapshot, so you can inspect the decoration before printing.

Instructions

Render a 3D preview of a mid-print decorated part (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

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": "preview_decorated_mesh"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoFilament colour for the render (hex). Defaults to white. Default: "#FFFFFF".
widthNoRender width in pixels. Default 800. Default: 800.
heightNoRender height in pixels. Default 600. Default: 600.
depth_mmNoDeboss depth in mm, (0, 5] (default 0.8). Default: 0.8.
decorationNoOverride the provenance-derived decoration spec. v1 supports "kiln"; other specs surface DECORATION_NOT_SUPPORTED with the allow-list. Default: "kiln".
output_dirNoDirectory for the rendered PNGs + decorated STL. Empty = a fresh kiln_preview_stl_* tempdir. A named folder must be new or empty (``OUTPUT_EXISTS`` otherwise): the files have fixed names, so an earlier preview there is never written over. Default: "".
session_idNoSession key from decorate_during_print. Resolved against the engine's persistent root + legacy tempdir fallbacks. Provenance sidecar supplies decoration spec + depth if not overridden. Default: "".
image_scaleNoDecoration size as a fraction of the part's shorter top-face axis. Default 0.6. Default: 0.6.
engine_output_dirNoDirect path to session dir. Higher priority than session_id. Default: "".
source_gcode_pathNoExplicit path to the pre-carve source gcode used to derive the part's XY bounds. When omitted and a session is given, the engine's carved gcode is used (its XY envelope equals the source's — the carver never adds new XY). Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • changedInput schema / properties / color / description
      Previous value: -"Default: \"#FFFFFF\"."New value: +"Filament colour for the render (hex). Defaults to white. Default: \"#FFFFFF\"."
    • changedInput schema / properties / decoration / description
      Previous value: -"Default: \"kiln\"."New value: +"Override the provenance-derived decoration spec.  v1 supports \"kiln\"; other specs surface DECORATION_NOT_SUPPORTED with the allow-list. Default: \"kiln\"."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 0.8."New value: +"Deboss depth in mm, (0, 5] (default 0.8). Default: 0.8."
    • changedInput schema / properties / engine_output_dir / description
      Previous value: -"Default: \"\"."New value: +"Direct path to session dir. Higher priority than session_id. Default: \"\"."
    • changedInput schema / properties / height / description
      Previous value: -"Default: 600."New value: +"Render height in pixels.  Default 600. Default: 600."
    • changedInput schema / properties / image_scale / description
      Previous value: -"Default: 0.6."New value: +"Decoration size as a fraction of the part's shorter top-face axis.  Default 0.6. Default: 0.6."
    • changedInput schema / properties / output_dir / description
      Previous value: -"Default: \"\"."New value: +"Directory for the rendered PNGs + decorated STL.  Empty = a fresh kiln_preview_stl_* tempdir.  A named folder must be new or empty (``OUTPUT_EXISTS`` otherwise): the files have fixed names, so an earlier preview there is never written over. Default: \"\"."
    • changedInput schema / properties / session_id / description
      Previous value: -"Default: \"\"."New value: +"Session key from decorate_during_print. Resolved against the engine's persistent root + legacy tempdir fallbacks.  Provenance sidecar supplies decoration spec + depth if not overridden. Default: \"\"."
    • changedInput schema / properties / source_gcode_path / description
      Previous value: -"Default: \"\"."New value: +"Explicit path to the pre-carve source gcode used to derive the part's XY bounds. When omitted and a session is given, the engine's carved gcode is used (its XY envelope equals the source's — the carver never adds new XY). Default: \"\"."
    • changedInput schema / properties / width / description
      Previous value: -"Default: 800."New value: +"Render width in pixels.  Default 800. Default: 800."
  2. Addedv1.5.0

TDQS

A3.7/5.0
Behavior4/5

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

Goes well beyond the thin annotations (readOnlyHint=false, destructiveHint=false) by disclosing the inline 3D stage, the browser stage fallback in hosted sessions, and automatic decimation of oversized meshes. It does not, however, state that the call writes PNGs plus a decorated STL to disk or what happens on an existing output_dir, leaving the write side effect to the schema.

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 lead sentence is well front-loaded, but the 'INLINE 3D STAGE' paragraph largely restates the orbital-viewer/stage-link content already given in paragraph one, and the 'PNG preview is the floor' flourish adds little. Repetition costs it points despite otherwise efficient phrasing.

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?

The description tells the agent that a decorated mesh requires a decoration session or engine_output_dir and explains the stage experience; narrow gaps in behavior and failure modes are covered by the fully documented schema. With no output schema, the added sentence about what the user sees on success covers the return-value burden adequately.

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 all ten parameters including defaults, the OUTPUT_EXISTS rule, and the DECORATION_NOT_SUPPORTED allow-list. The description adds only procedural context (provenance sidecar supplying decoration spec and depth), so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: 'Render a 3D preview of a mid-print decorated part (Pro)', which scopes it to the decorate_during_print workflow. It is distinguishable from generic render siblings like render_design_mesh or preview_generated_model by that scope, though it never names an alternative explicitly.

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?

Usage is only implied: the mention of 'session_id from decorate_during_print' and 'provenance sidecar' hints the tool follows a decoration session, but there is no when-to-use/when-not guidance and no routing to sibling preview or visualization tools. An agent must infer the call ordering and preconditions.

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