Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_pet_bowl

Generates a tapered pet bowl sized S, M, or L for FDM printing, with optional wall text, QR or photo bottoms, and food-safe material checks. Previews the result in an inline 3D stage.

Instructions

Generate a tapered pet bowl optimized for FDM printing. 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_pet_bowl"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoBowl size — ``"S"``, ``"M"``, or ``"L"``. Default: "M".
bottomNo``"plain"``, ``"pocket"``, ``"text:..."`` or ``"qr:URL"``. A pocket, QR code or lettering here under a photo or lettering on ``interior_bottom`` raises the floor inside the bowl until both fit; the outside is unchanged and the reply gives the new floor thickness. Default: "plain".
wall_mmNoWall thickness in mm (default 3.0, min 2.4). Default: 3.0.
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: "".
exteriorNoText wrapped on the outside wall as ``"text:..."``, or empty for a plain wall. A photo or logo is refused here; it goes on ``interior_bottom``. Default: "".
materialNoMaterial (default PETG — food-safe). Default: "PETG".
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 or ``"auto"`` is ``"circle"``, since the bowl is round. Default: "".
printer_idNoOptional active-printer identifier. When supplied, the food-safety check ALSO consults the printer's recorded nozzle. A brass nozzle hard-refuses the pet bowl regardless of how food-safe the filament is — lead trace in brass alloys is the single biggest practical risk for anything that touches a mouth. Omit to skip the nozzle check (material-only gate still applies). Default: "".
include_stepNoAlso emit a CAD-exact STEP file — REAL analytic B-rep (true cones for the tapered wall, rim flare and cavity), never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. Wall text, image decorations and QR bottoms refuse honestly — the mesh outputs are always unaffected. Default: false.
color_overridesNoJSON dict mapping role → color name/hex. Overrides body_color for "body" role unless body_color is also set. Default: "".
interior_bottomNoInterior base — ``"plain"``, ``"text:..."`` or a photo or logo file path. A file that is not there is refused. Default: "plain".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 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\"``.  A pocket, QR code or lettering here under a photo or lettering on ``interior_bottom`` raises the floor inside the bowl 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: \"\"."
    • changedInput schema / properties / color_overrides / description
      Previous value: -"Default: \"\"."New value: +"JSON dict mapping role → color name/hex. Overrides body_color for \"body\" role unless body_color is also set. Default: \"\"."
    • changedInput schema / properties / exterior / description
      Previous value: -"Default: \"\"."New value: +"Text wrapped on the outside wall as ``\"text:...\"``, or empty for a plain wall.  A photo or logo is refused here; it goes on ``interior_bottom``. Default: \"\"."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also emit a CAD-exact STEP file — REAL analytic B-rep (true cones for the tapered wall, rim flare and cavity), never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``.  Wall text, image decorations and QR bottoms refuse honestly — the mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / interior_bottom / description
      Previous value: -"Default: \"plain\"."New value: +"Interior base — ``\"plain\"``, ``\"text:...\"`` or a photo or logo file path.  A file that is not there is refused. Default: \"plain\"."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PETG\"."New value: +"Material (default PETG — food-safe). Default: \"PETG\"."
    • 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 or ``\"auto\"`` is ``\"circle\"``, since the bowl is round. Default: \"\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional active-printer identifier.  When supplied, the food-safety check ALSO consults the printer's recorded nozzle.  A brass nozzle hard-refuses the pet bowl regardless of how food-safe the filament is — lead trace in brass alloys is the single biggest practical risk for anything that touches a mouth.  Omit to skip the nozzle check (material-only gate still applies). Default: \"\"."
    • changedInput schema / properties / size / description
      Previous value: -"Default: \"M\"."New value: +"Bowl size — ``\"S\"``, ``\"M\"``, or ``\"L\"``. Default: \"M\"."
    • changedInput schema / properties / wall_mm / description
      Previous value: -"Default: 3.0."New value: +"Wall thickness in mm (default 3.0, min 2.4). Default: 3.0."
  2. Addedv1.5.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only declare readOnly=false/openWorld=false/destructive=false, and the description goes well beyond them: it discloses that an inline 3D stage opens on success, that oversized meshes are decimated, that a PNG preview is the fallback, and that hosted sessions attach a browser stage link. It stops short of saying what file artifacts are written or returned, which is the main remaining behavioral gap.

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 first sentence is well front-loaded, but the stage behavior is stated twice — once in the opening paragraph and again in the ALL-CAPS INLINE 3D STAGE block — and the MAKE DOORS paragraph is tangential system routing rather than tool-specific information. Roughly a third of the text could be removed without loss.

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?

For a 12-parameter generator with zero required params, a fully documented schema and annotations, the description supplies the differentiating behavioral context an agent needs: the preview/stage experience, auto-decimation, and the STEP side output. Only the concrete return artifacts (mesh paths, preview file) are left unstated, which is a minor gap absent an 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%, so the schema already explains size, bottom, printer_id, include_step and the rest in detail. The description adds no parameter-level meaning beyond 'tapered', relying entirely on the schema; this is the correct baseline but not more.

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 sentence states a specific verb and resource (generate a tapered pet bowl optimized for FDM) with concrete output characteristics. It is clearly distinct from siblings like generate_coaster or generate_pen_cup by the object noun, though it never explicitly contrasts itself with those generators, only with the make-loop tools (design_session, compile_scad).

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 routing context, but it routes the agent toward compile_scad rather than explaining when to pick generate_pet_bowl over the other object generators. There is no explicit 'use this instead of X when Y' statement and no exclusions, so usage is only implied by the object name.

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