Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_pet_tag

Creates a 3D-printable pet ID tag with front name, optional phone, selectable shape, and QR/text back, then opens an interactive 3D preview to orbit and zoom.

Instructions

Generate a 3D-printable pet ID tag. 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "front_text": "<front_text>"
    },
    "name": "generate_pet_tag"
  }
}

Input Schema

NameRequiredDescriptionDefault
backNoBack config — ``"plain"``, ``"qr:URL"``, or ``"text:..."``. Default: "plain".
shapeNoTag shape — ``"circle"``, ``"oval"``, or ``"square"``. Default: "circle".
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 PETG for durability). Default: "PETG".
body_colorNoBody color (default white). Default: "white".
front_textYesPet name (REQUIRED).
printer_idNoOptional id of the printer that will print the tag. When its nozzle is on record and is brass, the result carries a warning to swap it for this mouthed part; omitted, or with no nozzle on record, only the material check applies. Default: "".
diameter_mmNoTag diameter/width in mm (default 30). Default: 30.0.
front_line2NoOptional phone number below name. Default: "".
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, planes and elliptical walls a machine shop's CAD opens clean, never a tessellated conversion. On success the response gains a ``step`` block with ``step_path``. QR tags refuse the STEP honestly (a QR tag is a two-solid multicolor assembly) — the mesh outputs are always unaffected. Default: false.
ring_hole_mmNoDistance from edge to ring hole center (default 8). Default: 8.0.
thickness_mmNoThickness in mm (default 3, min 2.5). Default: 3.0.
color_overridesNoJSON dict mapping role → color name/hex. Overrides body_color for "body" role unless body_color is also set. Default: "".
ring_diameter_mmNoRing hole diameter in mm (default 5). Default: 5.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv1.5.1
    • changedInput schema / properties / back / description
      Previous value: -"Default: \"plain\"."New value: +"Back config — ``\"plain\"``, ``\"qr:URL\"``, or ``\"text:...\"``. Default: \"plain\"."
    • changedInput schema / properties / body_color / description
      Previous value: -"Default: \"white\"."New value: +"Body color (default white). Default: \"white\"."
    • 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 / diameter_mm / description
      Previous value: -"Default: 30.0."New value: +"Tag diameter/width in mm (default 30). Default: 30.0."
    • changedInput schema / properties / front_line2 / description
      Previous value: -"Default: \"\"."New value: +"Optional phone number below name. Default: \"\"."
    • addedInput schema / properties / front_text / description
      Added value: +"Pet name (REQUIRED)."
    • 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, planes and elliptical walls a machine shop's CAD opens clean, never a tessellated conversion.  On success the response gains a ``step`` block with ``step_path``. QR tags refuse the STEP honestly (a QR tag is a two-solid multicolor assembly) — the mesh outputs are always unaffected. Default: false."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"PETG\"."New value: +"Material (default PETG for durability). Default: \"PETG\"."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional id of the printer that will print the tag.  When its nozzle is on record and is brass, the result carries a warning to swap it for this mouthed part; omitted, or with no nozzle on record, only the material check applies. Default: \"\"."
    • changedInput schema / properties / ring_diameter_mm / description
      Previous value: -"Default: 5.0."New value: +"Ring hole diameter in mm (default 5). Default: 5.0."
    • changedInput schema / properties / ring_hole_mm / description
      Previous value: -"Default: 8.0."New value: +"Distance from edge to ring hole center (default 8). Default: 8.0."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"circle\"."New value: +"Tag shape — ``\"circle\"``, ``\"oval\"``, or ``\"square\"``. Default: \"circle\"."
    • changedInput schema / properties / thickness_mm / description
      Previous value: -"Default: 3.0."New value: +"Thickness in mm (default 3, min 2.5). Default: 3.0."
  2. Addedv1.5.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnly=false and destructive=false, so the safety profile is covered. The description adds real value beyond that — it discloses that an inline 3D stage opens on success, that oversized meshes are decimated, and that a PNG preview always exists as a floor. It does not say where artifacts are written, whether a design record is persisted, or what the failure modes are.

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 purpose is front-loaded in the first sentence, but the 'INLINE 3D STAGE' section mostly restates what that first sentence already said (stage opens, browser link fallback), and the all-caps section headers add noise. The subsequent details about decimation and PNG preview do earn their place; the redundancy does not.

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 14-parameter generation tool with no output schema, the description covers the interactive-stage experience and preview behavior well, but is thin on the actual returned artifacts (mesh file paths, color/sidecar outputs) that an agent would need to chain into slicing or printing. Adequate but leaves a meaningful gap.

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 all 14 parameters already carry their own documentation, including back config syntax, brief_id sidecar behavior, and the STEP/QR interaction. The description adds essentially no parameter-level meaning beyond the schema, so the baseline 3 is 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?

States a specific verb and resource: 'Generate a 3D-printable pet ID tag.' The name plus the first sentence make the object unambiguous. It does not, however, differentiate itself from the many other object generators in the sibling list (generate_nameplate, generate_keychain, generate_pet_bowl), so an agent must infer the boundary from the name alone.

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 explains that design_session is unavailable here and that compile_scad is the general make → preview → iterate loop, which gives some routing context. But it never says when to call generate_pet_tag versus another tag-like generator, nor what prerequisites (printer_id, material, saved brief) matter. Usage is implied rather than stated.

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