Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_jewelry_tray

Generate a jewelry tray by size, variant, and dimensions, with optional dividers, text, photo, or QR decoration. Preview the result in an interactive 3D stage to orbit, zoom, and iterate.

Instructions

Generate a jewelry tray with optional decoration; adding a QR code needs Kiln Business. Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link). MAKE DOORS: design_session, Kiln's front door for making an object, is not installed here (signed in to Kiln it runs on Kiln's servers). On this install compile_scad IS the make → preview → iterate loop: make it, show the preview, iterate.

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

Input Schema

NameRequiredDescriptionDefault
sizeNoSize preset — ``"small"``, ``"medium"``, ``"large"``, ``"xl"``. Any other name is refused. Default: "".
bottomNo``"plain"``, ``"pocket"``, ``"text:..."`` or ``"qr:URL"``. Default: "plain".
variantNoTray variant — ``"square"``, ``"rectangle"``, ``"divided"``; with ``size``, it picks which preset table is used. Geometry comes from the dimensions and divider counts. Any other value is refused. Default: "square".
wall_mmNoWall thickness (default 2.4mm, min 1.6mm). Default: 2.4.
brief_idNoOptional saved-goal id from ``design_session``. When supplied, the produced mesh gets a ``design_brief:<id>`` intent sidecar so the audit's "matches what you asked for" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all light up against the saved goal. Omit to skip — REST callers without a goal still get an auto-inferred brief at dispatch time. Default: "".
depth_mmNoTray depth (default 80mm). Default: 80.0.
materialNoMaterial (default PLA). Default: "PLA".
width_mmNoTray width (default 120mm). Default: 120.0.
height_mmNoTray height (default 20mm, min 12mm). Default: 20.0.
body_colorNoBody color (default white for QR contrast). Default: "white".
decorationNoInterior base content — the path of a photo or logo, ``"text:..."`` or empty. A photo needs a tray without dividers (the dividers would stand across it) and is refused on a divided one; a file that is not there is refused. Default: "".
dividers_xNoVertical dividers along width (0-4). Default: 0.
dividers_yNoHorizontal dividers along depth (0-3). Default: 0.
photo_maskNoPhoto crop shape for a photograph (a logo on a clean field is carved unmasked whatever is passed; a name outside this list is refused) — ``"circle"``, ``"rectangle"`` or ``"rounded_rectangle"``. Empty or ``"auto"`` is ``"rounded_rectangle"``, since every variant is rectangular. Default: "".
include_stepNoAlso emit a CAD-exact STEP file. The STEP is REAL analytic B-rep built from the same typed parameters as the mesh — true planes and cylinders a machine shop's CAD opens clean, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. Photo-interior and QR trays refuse the STEP honestly (heightmap relief has no analytic form; QR is a two-solid assembly) — the mesh outputs are always unaffected. Default: false.
color_overridesNoJSON dict mapping role → color name/hex. Overrides body_color for "body" role unless body_color is also set. Default: "".
corner_radius_mmNoCorner radius (default 8mm). Default: 8.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changedv1.5.1
    • changedInput schema / properties / body_color / description
      Previous value: -"Default: \"white\"."New value: +"Body color (default white for QR contrast). Default: \"white\"."
    • changedInput schema / properties / bottom / description
      Previous value: -"Default: \"plain\"."New value: +"``\"plain\"``, ``\"pocket\"``, ``\"text:...\"`` or ``\"qr:URL\"``. Default: \"plain\"."
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"Optional saved-goal id from ``design_session``. When supplied, the produced mesh gets a ``design_brief:<id>`` intent sidecar so the audit's \"matches what you asked for\" gate, the brief failure_history wiring, and the ``compare_design_versions`` intent diff all light up against the saved goal.  Omit to skip — REST callers without a goal still get an auto-inferred brief at dispatch time. Default: \"\"."
    • changedInput schema / properties / color_overrides / description
      Previous value: -"Default: \"\"."New value: +"JSON dict mapping role → color name/hex. Overrides body_color for \"body\" role unless body_color is also set. Default: \"\"."
    • changedInput schema / properties / corner_radius_mm / description
      Previous value: -"Default: 8.0."New value: +"Corner radius (default 8mm). Default: 8.0."
    • changedInput schema / properties / decoration / description
      Previous value: -"Default: \"\"."New value: +"Interior base content — the path of a photo or logo, ``\"text:...\"`` or empty.  A photo needs a tray without dividers (the dividers would stand across it) and is refused on a divided one; a file that is not there is refused. Default: \"\"."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 80.0."New value: +"Tray depth (default 80mm). Default: 80.0."
    • changedInput schema / properties / dividers_x / description
      Previous value: -"Default: 0."New value: +"Vertical dividers along width (0-4). Default: 0."
    • changedInput schema / properties / dividers_y / description
      Previous value: -"Default: 0."New value: +"Horizontal dividers along depth (0-3). Default: 0."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 20.0."New value: +"Tray height (default 20mm, min 12mm). Default: 20.0."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also emit a CAD-exact STEP file.  The STEP is REAL analytic B-rep built from the same typed parameters as the mesh — true planes and cylinders a machine shop's CAD opens clean, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``.  Photo-interior and QR trays refuse the STEP honestly (heightmap relief has no analytic form; QR is a two-solid assembly) — the mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Material (default PLA). Default: \"PLA\"."
    • changedInput schema / properties / photo_mask / description
      Previous value: -"Default: \"\"."New value: +"Photo crop shape for a photograph (a logo on a clean field is carved unmasked whatever is passed; a name outside this list is refused) — ``\"circle\"``, ``\"rectangle\"`` or ``\"rounded_rectangle\"``. Empty or ``\"auto\"`` is ``\"rounded_rectangle\"``, since every variant is rectangular. Default: \"\"."
    • changedInput schema / properties / size / description
      Previous value: -"Default: \"\"."New value: +"Size preset — ``\"small\"``, ``\"medium\"``, ``\"large\"``, ``\"xl\"``. Any other name is refused. Default: \"\"."
    • changedInput schema / properties / variant / description
      Previous value: -"Default: \"square\"."New value: +"Tray variant — ``\"square\"``, ``\"rectangle\"``, ``\"divided\"``; with ``size``, it picks which preset table is used.  Geometry comes from the dimensions and divider counts.  Any other value is refused. Default: \"square\"."
    • changedInput schema / properties / wall_mm / description
      Previous value: -"Default: 2.4."New value: +"Wall thickness (default 2.4mm, min 1.6mm). Default: 2.4."
    • changedInput schema / properties / width_mm / description
      Previous value: -"Default: 120.0."New value: +"Tray width (default 120mm). Default: 120.0."
  2. Addedv1.5.0

TDQS

A3.5/5.0
Behavior4/5

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

With annotations already declaring this is a non-read-only but non-destructive, closed-world generation, the description still adds real behavioral context: it opens an interactive inline 3D stage, hosted sessions attach a browser stage link, oversized meshes are decimated automatically, and the PNG preview is a floor rather than the whole result. The Kiln Business gating for QR and brief_id's sidecar effects are likewise disclosed. It does not contradict the annotations.

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 front-loaded first sentence is good, but the inline 3D stage behavior is explained twice in near-identical paragraphs, and the all-caps 'MAKE DOORS' tangent about design_session and compile_scad sits in a parameterized generator's description where it mostly distracts. Substantial text is redundant with the schema's own parameter descriptions.

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

Completeness4/5

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

For a 17-parameter, all-optional generator with no output schema, the definition covers what matters: that a stage opens on success, decimation behavior, the STEP add-on's refusal cases, and the QR tier requirement. The main omission is what object is actually returned (mesh path/format) and where files land, though annotations and schema carry much of the rest.

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 coverage is 100%, so the schema already carries the enum-like constraints, defaults, and min values for all 17 parameters; that sets the baseline at 3. The description adds only marginal semantics over the schema — the QR tier gate and the divider/photo incompatibility — both of which are already stated in the parameter descriptions, so it earns no more than baseline.

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?

The opening sentence gives a concrete verb+resource ('Generate a jewelry tray with optional decoration') and adds the scope limit that QR codes need Kiln Business. The 'MAKE DOORS' paragraph points at design_session and compile_scad, so the agent can locate this tool relative to the make loop, but it never distinguishes this from the many similar object generators (generate_ashtray, generate_coaster, generate_pen_cup, generate_rolling_tray).

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 implied rather than stated: it says design_session is not installed here and that compile_scad 'IS the make → preview → iterate loop', which is context rather than a rule for choosing this tool. Real constraints are buried in the middle (QR needs Kiln Business, photo decoration is refused on divided trays, photo_mask is ignored for logos), but there is no explicit when-to-use/when-not-to-use guidance against the sibling tray generators.

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