Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_rolling_tray

Generate a shallow rectangular 3D-printable rolling tray with a concave cove inner wall so loose contents sweep into a corner instead of catching a sharp edge; decorate the work surface and underside.

Instructions

Generate a rolling tray — a shallow rectangular work tray with a concave cove inner wall, so loose contents sweep clean into a corner instead of catching a 90-degree edge. Decorate the interior work surface and the exterior underside, both. 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_rolling_tray"
  }
}

Input Schema

NameRequiredDescriptionDefault
topNoWork-surface content. Default: "".
sizeNo``"small"``/``"medium"``/``"large"``/``"xl"``. Any other name is refused. Default: "".
bottomNo``"plain"``, ``"pocket"``, ``"text:..."``, or ``"qr:URL"``. Any other value is refused. Default: "plain".
wall_mmNoWall/floor thickness (default 2.4). 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 and the ``compare_design_versions`` intent diff light up. Default: "".
depth_mmNoDepth — short edge (default 135). Default: 135.0.
materialNoMaterial (default PLA). Default: "PLA".
width_mmNoWidth — long edge (default 190). Default: 190.0.
height_mmNoHeight in mm (default 18). Default: 18.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) — ``"rectangle"``, ``"rounded_rectangle"``, ``"circle"``. Empty or ``"auto"`` is ``"rounded_rectangle"``, since the tray is rectangular. Default: "".
printer_idNoTarget printer for the bed-fit check (e.g. ``"bambu_a1"``); empty auto-detects the active printer. Default: "".
include_stepNoAlso emit a CAD-exact STEP file of the tray body; on success the response gains a ``step`` block with ``step_path``. A QR underside or a photo on the work surface refuses the STEP with the reason; the mesh outputs are always unaffected. Defaults to False. Default: false.
cove_radius_mmNoInterior fillet radius; 0 = auto. Default: 0.0.
color_overridesNoJSON dict mapping role → color. Default: "".
corner_radius_mmNoOuter corner radius (default 14). Default: 14.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: \"white\"."New value: +"Body color (default white). Default: \"white\"."
    • changedInput schema / properties / bottom / description
      Previous value: -"Default: \"plain\"."New value: +"``\"plain\"``, ``\"pocket\"``, ``\"text:...\"``, or ``\"qr:URL\"``.  Any other value is refused. 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 and the ``compare_design_versions`` intent diff light up. Default: \"\"."
    • changedInput schema / properties / color_overrides / description
      Previous value: -"Default: \"\"."New value: +"JSON dict mapping role → color. Default: \"\"."
    • changedInput schema / properties / corner_radius_mm / description
      Previous value: -"Default: 14.0."New value: +"Outer corner radius (default 14). Default: 14.0."
    • changedInput schema / properties / cove_radius_mm / description
      Previous value: -"Default: 0.0."New value: +"Interior fillet radius; 0 = auto. Default: 0.0."
    • changedInput schema / properties / depth_mm / description
      Previous value: -"Default: 135.0."New value: +"Depth — short edge (default 135). Default: 135.0."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 18.0."New value: +"Height in mm (default 18). Default: 18.0."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also emit a CAD-exact STEP file of the tray body; on success the response gains a ``step`` block with ``step_path``.  A QR underside or a photo on the work surface refuses the STEP with the reason; the mesh outputs are always unaffected.  Defaults to False. 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) — ``\"rectangle\"``, ``\"rounded_rectangle\"``, ``\"circle\"``.  Empty or ``\"auto\"`` is ``\"rounded_rectangle\"``, since the tray is rectangular. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Target printer for the bed-fit check (e.g. ``\"bambu_a1\"``); empty auto-detects the active printer. Default: \"\"."
    • changedInput schema / properties / size / description
      Previous value: -"Default: \"\"."New value: +"``\"small\"``/``\"medium\"``/``\"large\"``/``\"xl\"``. Any other name is refused. Default: \"\"."
    • changedInput schema / properties / top / description
      Previous value: -"Default: \"\"."New value: +"Work-surface content. Default: \"\"."
    • changedInput schema / properties / wall_mm / description
      Previous value: -"Default: 2.4."New value: +"Wall/floor thickness (default 2.4). Default: 2.4."
    • changedInput schema / properties / width_mm / description
      Previous value: -"Default: 190.0."New value: +"Width — long edge (default 190). Default: 190.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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is already covered. The description adds genuinely non-derivable behavior: the tool opens an interactive inline 3D stage in MCP Apps hosts, hosted sessions attach a browser stage link instead, oversized meshes are decimated for the stage, and the PNG preview is explicitly 'the floor, not the whole experience.' It does not say where generated mesh files land or whether anything is persisted, which is the remaining gap.

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 text is bloated and self-repeating: the opening sentence already says the tool 'Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts...),' and a later all-caps INLINE 3D STAGE paragraph restates the same fact at greater length. The design_session/compile_scad aside about what is installed on this host is a tangent that does not help an agent decide to call this tool. Front-loading is decent but roughly half the text could be cut without loss.

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?

There is no output schema, so the description must carry the return-value burden; it does say a preview is produced and that an interactive stage opens, and the STEP side-effect is documented (though that detail also lives in the schema). It never states what the primary returned artifacts are — mesh file paths, format, or how to hand the result to slicing/printing — which an agent needs for a 16-parameter generation tool with no output schema.

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% across all 16 parameters, so the schema carries parameter documentation and a baseline of 3 applies. The description does add one useful mapping by stating you decorate 'the interior work surface and the exterior underside, both,' which ties the `top` and `bottom` fields to physical faces, and the cove explanation gives context for `cove_radius_mm`. It supplies no guidance on interactions between parameters, such as how `size` relates to the explicit `width_mm`/`depth_mm`/`height_mm` values.

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 names a specific verb and resource ('Generate a rolling tray') and goes on to define the artifact physically: 'a shallow rectangular work tray with a concave *cove* inner wall, so loose contents sweep clean into a corner instead of catching a 90-degree edge.' That is far more than a restatement of the name. It does not, however, distinguish itself from the large family of other single-product generators (generate_ashtray, generate_soap_dish, generate_pen_cup), so it stops short of full sibling differentiation.

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 only implied: an agent infers it should call this when the user wants a rolling tray. The paragraphs about design_session not being installed and compile_scad being 'the make → preview → iterate loop' describe the surrounding workflow rather than specifying when this tool is or is not appropriate, and no exclusions or alternatives for the product-generator family are given.

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