Skip to main content
Glama

generate_from_template

Build a print-ready STL from a parametric template using the user's exact dimensions, so functional parts like brackets, bins, or clips fit without writing OpenSCAD.

Instructions

Build a printable STL from a parametric part, to the user's dimensions.

This is how Kiln makes a FUNCTIONAL PART without writing any
OpenSCAD: pick a template, pass the dimensions the user gave you,
and get a print-ready STL.  It runs LOCALLY through OpenSCAD — free,
no AI provider, no API key, and every template in the library is
print-verified at its default, minimum, and maximum parameters.

Reach for this the moment a user describes a functional part they
need in specific sizes ("a bracket for a 200 mm shelf", "a bin that
fits my 80 mm drawer", "a clip for an 8 mm cable"). Find the
template with ``find_design_templates(use_case)``, read its
parameters with ``get_design_template_info(id)`` or
``list_design_templates()``, then call this.

Only PARAMETRIC PARTS work here.  The design PATTERNS returned by
``find_design_templates`` with ``generatable: false`` (snap fits,
living hinges, press fits) are guidance for OpenSCAD you write
yourself — this tool rejects them.

For AI-assisted parameter inference plus structural analysis, use
``smart_generate_from_template``.

When the kiln-pro package is installed (Pro+ tier), the result MAY
carry an ``intent`` block describing the geometric assertions the
template parameters implied, and a sidecar ``<mesh>.intent.json``
is written next to the produced STL.  Free / public installs see
the result unchanged.

When you pass a parameter that sizes a hole for real hardware (a
screw or bolt hole, a bore, a dowel or pin hole, a magnet pocket),
the result carries a ``fastener_advice`` block saying the part was
built to your number and nothing sized it for a named fastener.
Kiln raises that once per session across every tool that can raise
it, so a later build may omit the block even though it qualifies.
Read its ``agent_instruction`` before repeating any of it to the user.

Args:
    brief_id: The saved goal's id from ``design_session``, so this make
        is recorded against the goal and checked against it. Empty when
        there is no goal.
    template_id: Parametric part id, from ``find_design_templates``
        or ``list_design_templates`` (e.g. ``"shelf_bracket"``).
    parameters: Dict of parameter overrides carrying the user's own
        dimensions (e.g. ``{"arm_length": 200, "thickness": 8}``).
        Anything you leave out keeps the template's default.

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.

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.

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": {
      "template_id": "<template_id>"
    },
    "name": "generate_from_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
brief_idNoThe saved goal's id from ``design_session``, so this make is recorded against the goal and checked against it. Empty when there is no goal. Default: "".
parametersNoDict of parameter overrides carrying the user's own dimensions (e.g. ``{"arm_length": 200, "thickness": 8}``). Anything you leave out keeps the template's default.
template_idYesParametric part id, from ``find_design_templates`` or ``list_design_templates`` (e.g. ``"shelf_bracket"``).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.5.1
    • changedInput schema / properties / brief_id / description
      Previous value: -"Default: \"\"."New value: +"The saved goal's id from ``design_session``, so this make is recorded against the goal and checked against it. Empty when there is no goal. Default: \"\"."
    • addedInput schema / properties / parameters / description
      Added value: +"Dict of parameter overrides carrying the user's own dimensions (e.g. ``{\"arm_length\": 200, \"thickness\": 8}``). Anything you leave out keeps the template's default."
    • addedInput schema / properties / template_id / description
      Added value: +"Parametric part id, from ``find_design_templates`` or ``list_design_templates`` (e.g. ``\"shelf_bracket\"``)."
  2. Changed2 schema fields changedv1.5.0
    • addedInput schema / properties / brief_id
      Added value: +{
      +  "description": "Default: \"\".",
      +  "title": "Brief Id",
      +  "type": "string"
      +}
    • removedInput schema / properties / parameters / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, openWorld=false); the description adds substantial context beyond that: local OpenSCAD execution with no API key, the optional intent block and sidecar file under Pro+, the fastener_advice block and its once-per-session behavior, and the inline 3D stage with automatic decimation. These are real behavioral traits an agent needs.

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?

Purpose is front-loaded and the workflow guidance is well-placed, but the description is bloated with tangential sections (INLINE 3D STAGE, MAKE DOORS) that dilute focus, and the MAKE DOORS paragraph is confusing rather than clarifying. Several sentences could be trimmed without losing actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a generation tool with no output schema, the description covers inputs, prerequisites, side effects, tier-dependent behavior, and the resulting stage/preview. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so all three parameters are already documented. The Args section largely restates the schema (brief_id, template_id, parameters with the same examples and the 'leave out keeps default' note), adding only marginal meaning beyond structured data. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Build a printable STL from a parametric part, to the user's dimensions') and immediately distinguishes itself from siblings like smart_generate_from_template and compile_scad. An agent can tell exactly what this produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the workflow (find_design_templates → get_design_template_info → this), states the trigger condition with concrete user phrasings, names the alternative for AI-assisted inference, and states what it rejects (patterns with generatable: false). This is a full when/when-not/alternatives map.

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