Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_keychain

Create a 3D-printable keychain from a chosen shape, custom front text or logo, and an optional QR or text back, then open an interactive 3D stage to orbit, zoom, and preview before printing.

Instructions

Generate a 3D-printable keychain. 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_keychain"
  }
}

Input Schema

NameRequiredDescriptionDefault
backNoBack config — ``"plain"``, ``"qr:URL"``, or ``"text:..."``. Default: "plain".
frontNoFront decoration — file path, ``"text:..."`` or empty. Default: "".
shapeNoShape — ``"rectangle"``, ``"square"``, ``"circle"``, ``"oval"``, ``"heart"``. Default: "rectangle".
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: "".
materialNoMaterial (default PLA). Default: "PLA".
width_mmNoWidth in mm (default 50). Default: 50.0.
height_mmNoHeight in mm (default 30; ignored for ``"square"``/``"circle"`` — locked to width_mm). Default: 30.0.
body_colorNoBody color (default white). Default: "white".
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 follows the keychain's shape: rounded corners for ``"rectangle"`` and ``"square"``, a disc for ``"circle"``, ``"oval"`` and ``"heart"``. 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 cylinders, planes and elliptical walls a machine shop's CAD opens clean, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. SVG-logo fronts ride into the STEP as exact vector contours — the same outlines the mesh carves. Photo and QR keychains refuse the STEP honestly (heightmap relief has no analytic form; QR is a two-solid assembly) — the mesh outputs are always unaffected. Default: false.
thickness_mmNoThickness in mm (default 3, min 2.5). Default: 3.0.
color_overridesNoJSON dict mapping role → color name/hex (e.g. ``'{"body": "baby blue"}``). Default: "".
corner_radius_mmNoCorner radius for rectangle/square (default 5; pass 0 for sharp corners). Default: 5.0.
ring_diameter_mmNoRing hole diameter in mm (default 5). Default: 5.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.5.1
    • changedInput schema / properties / back / description
      Previous value: -"Default: \"plain\"."New value: +"Back config — ``\"plain\"``, ``\"qr:URL\"``, or ``\"text:...\"``. Default: \"plain\"."
    • changedInput schema / properties / body_color / description
      Previous value: -"Default: \"white\"."New value: +"Body color (default white). Default: \"white\"."
    • 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 (e.g. ``'{\"body\": \"baby blue\"}``). Default: \"\"."
    • changedInput schema / properties / corner_radius_mm / description
      Previous value: -"Default: 5.0."New value: +"Corner radius for rectangle/square (default 5; pass 0 for sharp corners). Default: 5.0."
    • changedInput schema / properties / front / description
      Previous value: -"Default: \"\"."New value: +"Front decoration — file path, ``\"text:...\"`` or empty. Default: \"\"."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 30.0."New value: +"Height in mm (default 30; ignored for ``\"square\"``/``\"circle\"`` — locked to width_mm). Default: 30.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 cylinders, planes and elliptical walls a machine shop's CAD opens clean, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``. SVG-logo fronts ride into the STEP as exact vector contours — the same outlines the mesh carves.  Photo and QR keychains 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 follows the keychain's shape: rounded corners for ``\"rectangle\"`` and ``\"square\"``, a disc for ``\"circle\"``, ``\"oval\"`` and ``\"heart\"``. Default: \"\"."
    • changedInput schema / properties / ring_diameter_mm / description
      Previous value: -"Default: 5.0."New value: +"Ring hole diameter in mm (default 5). Default: 5.0."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"rectangle\"."New value: +"Shape — ``\"rectangle\"``, ``\"square\"``, ``\"circle\"``, ``\"oval\"``, ``\"heart\"``. Default: \"rectangle\"."
    • changedInput schema / properties / thickness_mm / description
      Previous value: -"Default: 3.0."New value: +"Thickness in mm (default 3, min 2.5). Default: 3.0."
    • changedInput schema / properties / width_mm / description
      Previous value: -"Default: 50.0."New value: +"Width in mm (default 50). Default: 50.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?

Annotations only declare readOnlyHint=false and destructiveHint=false. The description goes well beyond that: it discloses that success opens an orbit/zoom panel, that hosted connections attach a browser stage link, that oversized meshes are silently decimated, and that the PNG preview is a fallback rather than the whole output — operationally important behavior an agent could not infer from structured fields.

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?

Purpose is front-loaded in the first sentence, but the tool repeats itself: the opening sentence already says the inline stage opens for MCP Apps hosts with a hosted link fallback, and the third block restates the same fact at length. The decimation detail is buried in the repetition rather than placed where it is actionable.

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 14 optional parameters, no output schema, and a pronounced side effect (an interactive panel opening in the user's host), the description covers the stage behavior but says nothing about the returned mesh/preview structure, failure modes, or generation cost/latency. The include_step refusal is documented only inside the schema, not at the description level.

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% and the parameter descriptions are already detailed (including the STEP-refusal and photo_mask inference rules), so the prose description adds essentially no parameter meaning of its own. Baseline 3 applies since the schema carries this dimension entirely.

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?

Opens with a specific verb+resource ("Generate a 3D-printable keychain") and adds the distinguishing outcome that the result opens an interactive 3D stage. It does not, however, differentiate itself from the many sibling generators (generate_pet_tag, generate_ornament, generate_nameplate), so an agent must infer the boundary from the name alone.

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 MAKE DOORS paragraph gives real routing context: design_session is unavailable on this install and compile_scad is the make→preview→iterate loop. But this is guidance about the surrounding design workflow rather than about when to pick this tool over the other generate_* siblings, so usage selection is only implied.

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