Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_fridge_magnet

Create a printable fridge magnet with a plain, debossed-text, or photo front, a rear magnet pocket, and an inline 3D stage to orbit, zoom, and iterate before printing.

Instructions

Generate a printable fridge magnet with front decoration. 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_fridge_magnet"
  }
}

Input Schema

NameRequiredDescriptionDefault
backNo``"plain"`` or ``"qr:URL"``. A photo or logo is refused here; it goes on ``front``. Default: "plain".
sizeNoSize preset — ``"small"``, ``"medium"``, ``"large"``. Any other name is refused. Default: "".
frontNoWhat goes on the front: empty for a plain face, ``"text:HELLO"`` for debossed text, or the path to a photo or logo to carve. The magnet recess is cut into the same body from behind, so a photo is carved shallower when the body is thin, and refused when it is too thin to carve one that reads (the small size is); a file that is not there is refused. Default: "".
shapeNo``"rectangle"`` (default) or ``"circle"``. Default: "rectangle".
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). Default: "PLA".
width_mmNoWidth in mm (default 50, diameter for circle). Default: 50.0.
height_mmNoHeight in mm (default 50, ignored for circle). Default: 50.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) — ``"circle"``, ``"rectangle"``, ``"rounded_rectangle"``. Empty or ``"auto"`` follows ``shape``: ``"circle"`` for a circle magnet, ``"rounded_rectangle"`` for a rectangle. Default: "".
include_stepNoAlso write a CAD-exact STEP file built from the same parameters as the mesh; on success the answer gains a ``step`` block with ``step_path``. A photo front or a QR back cannot be exported as STEP and the answer says so; the mesh outputs are unaffected. Default: false.
thickness_mmNoTotal thickness (default 4mm, min 3mm). Default: 4.0.
color_overridesNoJSON dict mapping role → color name/hex. Overrides body_color for "body" role unless body_color is also set. Default: "".
magnet_depth_mmNoMagnet pocket depth (default 2mm). Default: 2.0.
magnet_diameter_mmNoMagnet pocket diameter (default 10mm). Default: 10.0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv1.5.1
    • changedInput schema / properties / back / description
      Previous value: -"Default: \"plain\"."New value: +"``\"plain\"`` or ``\"qr:URL\"``.  A photo or logo is refused here; it goes on ``front``. 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 / front / description
      Previous value: -"Default: \"\"."New value: +"What goes on the front: empty for a plain face, ``\"text:HELLO\"`` for debossed text, or the path to a photo or logo to carve.  The magnet recess is cut into the same body from behind, so a photo is carved shallower when the body is thin, and refused when it is too thin to carve one that reads (the small size is); a file that is not there is refused. Default: \"\"."
    • changedInput schema / properties / height_mm / description
      Previous value: -"Default: 50.0."New value: +"Height in mm (default 50, ignored for circle). Default: 50.0."
    • changedInput schema / properties / include_step / description
      Previous value: -"Default: false."New value: +"Also write a CAD-exact STEP file built from the same parameters as the mesh; on success the answer gains a ``step`` block with ``step_path``.  A photo front or a QR back cannot be exported as STEP and the answer says so; the mesh outputs are unaffected. Default: false."
    • changedInput schema / properties / magnet_depth_mm / description
      Previous value: -"Default: 2.0."New value: +"Magnet pocket depth (default 2mm). Default: 2.0."
    • changedInput schema / properties / magnet_diameter_mm / description
      Previous value: -"Default: 10.0."New value: +"Magnet pocket diameter (default 10mm). Default: 10.0."
    • 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) — ``\"circle\"``, ``\"rectangle\"``, ``\"rounded_rectangle\"``. Empty or ``\"auto\"`` follows ``shape``: ``\"circle\"`` for a circle magnet, ``\"rounded_rectangle\"`` for a rectangle. Default: \"\"."
    • changedInput schema / properties / shape / description
      Previous value: -"Default: \"rectangle\"."New value: +"``\"rectangle\"`` (default) or ``\"circle\"``. Default: \"rectangle\"."
    • changedInput schema / properties / size / description
      Previous value: -"Default: \"\"."New value: +"Size preset — ``\"small\"``, ``\"medium\"``, ``\"large\"``. Any other name is refused. Default: \"\"."
    • changedInput schema / properties / thickness_mm / description
      Previous value: -"Default: 4.0."New value: +"Total thickness (default 4mm, min 3mm). Default: 4.0."
    • changedInput schema / properties / width_mm / description
      Previous value: -"Default: 50.0."New value: +"Width in mm (default 50, diameter for circle). Default: 50.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 already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the description's job is to add context, and it does: it discloses that an interactive 3D stage panel opens on success, that a hosted browser link is attached in some hosts, and that oversized meshes are decimated automatically. It does not mention generation latency or failure modes, which keeps it short of a 5.

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 is explained twice: once in the opening parenthetical and again at length in the closing 'INLINE 3D STAGE' paragraph, which is pure repetition. The 'MAKE DOORS' section is meta-commentary about install topology that pushes the actual tool purpose into a crowded first sentence.

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?

With 15 optional parameters, no output schema, and annotations covering only the safety profile, the description does cover the headline output (mesh + PNG preview + optional STEP). It leaves out what the returned artifact looks like beyond the stage, whether generation is slow or asynchronous, and how failures are reported, so it is adequate but not complete.

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 documents all 15 parameters, including the back/front encodings, size presets and photo_mask behavior. The description adds essentially no parameter-level detail beyond 'front decoration', so the baseline of 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 first sentence gives a specific verb and resource: 'Generate a printable fridge magnet with front decoration,' which is precise enough to act on. It does not differentiate itself from the many other object generators in the sibling list (generate_keychain, generate_coaster, generate_ornament, generate_wall_plaque), so an agent must rely on the name alone to pick among them.

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 make → preview → iterate loop, which is useful pipeline context. However, it never says when to choose this tool over the sibling magnet/novelty generators or what inputs are prerequisites, so usage guidance is implied rather than explicit.

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