Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_coaster

Create a custom round or square coaster with optional text, image, or QR branding, then open an interactive 3D stage to orbit, zoom, and review the result.

Instructions

Generate a coaster with optional branding; 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_coaster"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoTop surface content — ``"text:..."`` for debossed text, a PNG/JPG path for an embossed image, or empty for plain. Default: "".
shapeNoCoaster shape — ``"round"`` (default) or ``"square"``. Default: "round".
bottomNoBottom config — ``"plain"``, ``"pocket"``, or ``"qr:URL"``. Default: "plain".
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".
body_colorNoBody color (default white for QR contrast). 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 coaster's shape: a disc for ``"round"``, rounded corners for ``"square"``. Default: "".
diameter_mmNoDiameter in mm (default 90). Default: 90.0.
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 and planes a machine shop's CAD opens clean, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. Photo and QR coasters refuse the STEP honestly (heightmap relief has no analytic form; a QR coaster is a two-solid assembly) — the mesh outputs are always unaffected. Default: false.
thickness_mmNoThickness in mm (default 7, min 7). Default: 7.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 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: +"Bottom config — ``\"plain\"``, ``\"pocket\"``, 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 / diameter_mm / description
      Previous value: -"Default: 90.0."New value: +"Diameter in mm (default 90). Default: 90.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 and planes a machine shop's CAD opens clean, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``.  Photo and QR coasters refuse the STEP honestly (heightmap relief has no analytic form; a QR coaster 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 coaster's shape: a disc for ``\"round\"``, rounded corners for ``\"square\"``. Default: \"\"."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"round\"."New value: +"Coaster shape — ``\"round\"`` (default) or ``\"square\"``. Default: \"round\"."
    • changedInput schema / properties / thickness_mm / description
      Previous value: -"Default: 7.0."New value: +"Thickness in mm (default 7, min 7). Default: 7.0."
    • changedInput schema / properties / top / description
      Previous value: -"Default: \"\"."New value: +"Top surface content — ``\"text:...\"`` for debossed text, a PNG/JPG path for an embossed image, or empty for plain. Default: \"\"."
  2. Addedv1.5.0

TDQS

A3.6/5.0
Behavior4/5

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

With annotations already declaring a non-read-only, non-destructive, closed-world operation, the description adds substantive behavioral detail: it opens an interactive inline 3D stage on success, oversized meshes are decimated, PNG preview is the floor, and STEP output is refused for photo/QR coasters. This goes well beyond what annotations convey without contradicting them.

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 description starts with the core purpose but then meanders into workflow commentary ('MAKE DOORS') and stage details under all-caps headers. Some sentences about design_session and compile_scad are contextually useful but not directly about invoking generate_coaster, reducing front-loading and adding clutter.

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?

Given ten optional parameters and no output schema, the description does a fair job covering side effects (inline stage, browser link, automatic decimation) and conditional behavior (STEP refusal for photo/QR coasters, QR requiring Kiln Business). It omits a clear description of the primary mesh return value, but overall an agent has enough to call it correctly.

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 input schema already fully documents all ten parameters including their defaults and allowed values. The description adds little parameter-specific meaning beyond generic references to branding and QR, making the baseline 3 appropriate.

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 description states a specific verb and resource ('Generate a coaster with optional branding') and mentions constraints like QR requiring Kiln Business. However, it does not differentiate this from the many other generate_* siblings (e.g., generate_keychain, generate_nameplate), so an agent would rely on the tool name alone for that distinction.

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 gives some contextual guidance: it notes that design_session is not installed and that compile_scad is the make→preview→iterate loop, and it states that QR codes need Kiln Business. But it never explicitly says when to choose this tool over other product generators or what situations are inappropriate beyond the QR tier restriction.

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