Skip to main content
Glama

generate_ashtray

Create a custom ashtray with optional text, photo, logo, or QR branding, then inspect the result in an interactive 3D stage and iterate on the design.

Instructions

Generate an ashtray 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_ashtray"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoInterior base content — ``"text:..."`` for debossed text, the path of a photo or logo to carve into the floor, or empty for plain. A file that is not there is refused. Default: "".
sizeNoSize preset — ``"small"``, ``"medium"``, ``"large"``, ``"xl"``. Any other name is refused. Default: "".
shapeNoAshtray shape — ``"round"`` (default) or ``"square"``. Default: "round".
bottomNoBottom config — ``"plain"``, ``"pocket"``, ``"text:..."`` or ``"qr:URL"``. A pocket, QR code or lettering here under a photo or lettering on ``top`` raises the floor inside the ashtray until both fit; the outside is unchanged and the reply gives the new floor thickness. 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 — warns if not heat-safe). Default: "PLA".
height_mmNoHeight in mm (default 35, min 25). Default: 35.0.
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 ashtray's shape: a disc for ``"round"``, rounded corners for ``"square"``. Default: "".
diameter_mmNoDiameter in mm (default 100). Default: 100.0.
include_stepNoAlso emit a CAD-exact STEP file — REAL analytic B-rep from the same typed parameters, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. Photo interiors and QR bottoms refuse honestly — the mesh outputs are always unaffected. Default: false.
cigarette_restsNoRest grooves on the rim (default: 3 on round, 4 on square — one per corner; range 0-6 round, 0-4 square).
color_overridesNoJSON dict mapping role → color name/hex (e.g. ``'{"body": "baby blue"}``). Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 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\"``, ``\"text:...\"`` or ``\"qr:URL\"``.  A pocket, QR code or lettering here under a photo or lettering on ``top`` raises the floor inside the ashtray until both fit; the outside is unchanged and the reply gives the new floor thickness. 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: \"\"."
    • addedInput schema / properties / cigarette_rests / description
      Added value: +"Rest grooves on the rim (default: 3 on round, 4 on square — one per corner; range 0-6 round, 0-4 square)."
    • 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 / diameter_mm / description
      Previous value: -"Default: 100.0."New value: +"Diameter in mm (default 100). Default: 100.0."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 35.0."New value: +"Height in mm (default 35, min 25). Default: 35.0."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also emit a CAD-exact STEP file — REAL analytic B-rep from the same typed parameters, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``.  Photo interiors and QR bottoms refuse honestly — the mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PLA\"."New value: +"Material (default PLA — warns if not heat-safe). 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 ashtray's shape: a disc for ``\"round\"``, rounded corners for ``\"square\"``. Default: \"\"."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"round\"."New value: +"Ashtray shape — ``\"round\"`` (default) or ``\"square\"``. Default: \"round\"."
    • 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 / top / description
      Previous value: -"Default: \"\"."New value: +"Interior base content — ``\"text:...\"`` for debossed text, the path of a photo or logo to carve into the floor, or empty for plain.  A file that is not there is refused. Default: \"\"."
  2. Addedv1.5.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare the mutation/safety profile (readOnlyHint false, destructiveHint false), and the description adds real behaviour the structured fields don't cover: the tool opens an interactive 3D stage, oversized meshes are auto-decimated, and a PNG preview is always produced. Tier gating for QR and the browser-link fallback in non-panel hosts are useful operational context.

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 inline 3D stage behaviour is stated twice — once parenthetically in the opening paragraph and again under an 'INLINE 3D STAGE:' heading — and the all-caps MAKE DOORS paragraph is boilerplate about sibling tool availability rather than about this tool. The description roughly doubles the size it needs.

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?

For a 13-parameter generator with no output schema, the description does convey what success looks like (preview plus stage) and the QR tier constraint. It omits generation latency, whether the result is persisted or returned as a file, and how the stage behaves when it is not available at all.

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% and every parameter carries a detailed description, including the non-obvious interaction where bottom content raises the floor. The tool description itself contributes nothing about parameters beyond mentioning branding, 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?

"Generate an ashtray with optional branding" is a concrete verb+resource and the Kiln Business gate on QR codes further narrows scope. However, it never distinguishes itself from the dozens of neighbouring generate_* product tools (generate_coaster, generate_soap_dish, generate_pet_bowl), which an agent choosing between product generators would need.

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?

It supplies one real prerequisite ('adding a QR code needs Kiln Business') and names alternatives (design_session, compile_scad), but along a different axis than the sibling generators. The MAKE DOORS paragraph actively muddies routing by asserting compile_scad 'IS the make' loop, without saying when an agent should reach for generate_ashtray instead.

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