Skip to main content
Glama

generate_pen_cup

Generate a customizable desktop pen or brush cup with optional text, photo, logo, or QR decoration; preview and orbit the result in an interactive 3D stage.

Instructions

Generate a desktop pen / brush cup 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_pen_cup"
  }
}

Input Schema

NameRequiredDescriptionDefault
shapeNo``"cylinder"`` (default) or ``"rectangle"``. Default: "cylinder".
bottomNo``"plain"`` or ``"qr:URL"``; anything else is refused. A QR code under a photo, logo or lettering on ``interior_bottom`` raises the floor inside the cup 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: "".
depth_mmNoOuter depth (rectangle only). Default: 75.0.
exteriorNoText wrapped on the outer wall as ``"text:..."``; empty for a plain wall. A photo or logo is refused here; it goes on ``interior_bottom``. Default: "".
materialNoMaterial (default PLA). Default: "PLA".
height_mmNoTotal height in mm (default 100). Default: 100.0.
body_colorNoBody color (default navy). Default: "navy".
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"`` follows ``shape``: ``"circle"`` for a cylinder, ``"rounded_rectangle"`` for a rectangle. Default: "auto".
diameter_mmNoOuter diameter (cylinder) / outer width (rectangle). Default: 75.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``. Image decorations refuse (heightmaps have no analytic form); wrapped wall text on a round cup refuses with the interior-bottom alternative named; QR bottoms refuse (two-solid assembly). The mesh outputs are always unaffected. Default: false.
color_overridesNoJSON dict mapping role → color name/hex. Default: "".
interior_bottomNoInside floor — ``"plain"``, ``"text:..."`` or the path of a photo or logo. A file that is not there is refused. Default: "plain".
corner_radius_mmNoOuter corner radius for rectangle (default 8). Default: 8.0.
wall_thickness_mmNoWall thickness (default 3, min 1.6). Default: 3.0.
bottom_thickness_mmNoFloor thickness (default 3, min 2.0). Default: 3.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv1.5.1
    • changedInput schema / properties / body_color / description
      Previous value: -"Default: \"navy\"."New value: +"Body color (default navy). Default: \"navy\"."
    • changedInput schema / properties / bottom / description
      Previous value: -"Default: \"plain\"."New value: +"``\"plain\"`` or ``\"qr:URL\"``; anything else is refused.  A QR code under a photo, logo or lettering on ``interior_bottom`` raises the floor inside the cup until both fit; the outside is unchanged and the reply gives the new floor thickness. Default: \"plain\"."
    • changedInput schema / properties / bottom_thickness_mm / description
      Previous value: -"Default: 3.0."New value: +"Floor thickness (default 3, min 2.0). Default: 3.0."
    • 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. Default: \"\"."
    • changedInput schema / properties / corner_radius_mm / description
      Previous value: -"Default: 8.0."New value: +"Outer corner radius for rectangle (default 8). Default: 8.0."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 75.0."New value: +"Outer depth (rectangle only). Default: 75.0."
    • changedInput schema / properties / diameter_mm / description
      Previous value: -"Default: 75.0."New value: +"Outer diameter (cylinder) / outer width (rectangle). Default: 75.0."
    • changedInput schema / properties / exterior / description
      Previous value: -"Default: \"\"."New value: +"Text wrapped on the outer wall as ``\"text:...\"``; empty for a plain wall.  A photo or logo is refused here; it goes on ``interior_bottom``. Default: \"\"."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 100.0."New value: +"Total height in mm (default 100). Default: 100.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``.  Image decorations refuse (heightmaps have no analytic form); wrapped wall text on a round cup refuses with the interior-bottom alternative named; QR bottoms refuse (two-solid assembly).  The mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / interior_bottom / description
      Previous value: -"Default: \"plain\"."New value: +"Inside floor — ``\"plain\"``, ``\"text:...\"`` or the path of a photo or logo.  A file that is not there is refused. Default: \"plain\"."
    • 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: \"auto\"."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\"`` follows ``shape``: ``\"circle\"`` for a cylinder, ``\"rounded_rectangle\"`` for a rectangle. Default: \"auto\"."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"cylinder\"."New value: +"``\"cylinder\"`` (default) or ``\"rectangle\"``. Default: \"cylinder\"."
    • changedInput schema / properties / wall_thickness_mm / description
      Previous value: -"Default: 3.0."New value: +"Wall thickness (default 3, min 1.6). Default: 3.0."
  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 only cover non-readonly, non-destructive, non-open-world, so the description adds meaningful behavior: success opens an inline orbit/zoom 3D stage, oversized meshes are decimated for that stage, and the PNG preview is the floor of the experience. It omits run time/cost and does not say where the mesh file lands, which is a gap for a generation tool.

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?

Two long additional paragraphs, one headed MAKE DOORS that is largely about other tools, plus repeated explanation of the inline stage ('opens Kiln's interactive 3D stage' appears twice). All-caps headers and repeated restatement bury the one sentence that matters.

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 16-parameter generation tool with no output schema, it covers the visual result and the Business gate, but leaves out expected output artifacts (mesh/file path, failure modes beyond refusals) and any sense of cost or duration. Adequate but incomplete for this complexity.

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 parameters are already fully documented. The prose only echoes a couple of specifics (QR on bottom, photo/logo refused on exterior) that the schema already states. 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?

The opening clause gives a specific verb and resource: generate a desktop pen/brush cup with optional decoration, plus the Kiln Business gate on QR. It's clearly distinct from siblings like generate_pet_bowl or generate_coaster. The following two paragraphs drift into stage/doors narrative and dilute the focus.

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?

There is real routing guidance: design_session is not installed here, so compile_scad is the make → preview → iterate loop, and QR bottoms need Kiln Business. But it never states plainly when to pick this tool over generic options like generate_model or design_session, and the guidance is buried in a paragraph headed MAKE DOORS.

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