Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

optimize_template_params

Sweeps template parameters across their ranges, generates and structurally analyzes every variant via OpenSCAD, and returns the configuration with the highest structural score.

Instructions

Find the structurally strongest version of a parametric template.

        Sweeps each template parameter across its [min, max] range at
        evenly spaced sample points, generates every combination via
        OpenSCAD, runs structural analysis on each variant, and returns
        the configuration with the highest structural score.

        Use this when you want to **automatically** find optimal dimensions
        for a functional part -- e.g. "what wall thickness and bracket
        height give the strongest shelf bracket?"

        :param template_id: Template ID from the design template library.
        :param samples_per_param: Sample points per parameter (default 3).
        :param max_variants: Maximum total variants to test (default 27).
        :param constraints: JSON string of constraints, e.g.
               ``{"max_width_mm": 100, "max_height_mm": 50}``.
        :param output_dir: Directory for generated STLs (temp dir if empty).
        :returns: Dict with best_params, best_score, best_grade, best_stl_path,
                  variants_tested, all_scores, and summary.

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": "optimize_template_params"
  }
}

Input Schema

NameRequiredDescriptionDefault
output_dirNoDirectory for generated STLs (temp dir if empty). Default: "".
constraintsNoJSON string of constraints, e.g. ``{"max_width_mm": 100, "max_height_mm": 50}``. Default: "".
template_idYesTemplate ID from the design template library.
max_variantsNoMaximum total variants to test (default 27). Default: 27.
samples_per_paramNoSample points per parameter (default 3). Default: 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • changedInput schema / properties / constraints / description
      Previous value: -"Default: \"\"."New value: +"JSON string of constraints, e.g. ``{\"max_width_mm\": 100, \"max_height_mm\": 50}``. Default: \"\"."
    • changedInput schema / properties / max_variants / description
      Previous value: -"Default: 27."New value: +"Maximum total variants to test (default 27). Default: 27."
    • changedInput schema / properties / output_dir / description
      Previous value: -"Default: \"\"."New value: +"Directory for generated STLs (temp dir if empty). Default: \"\"."
    • changedInput schema / properties / samples_per_param / description
      Previous value: -"Default: 3."New value: +"Sample points per parameter (default 3). Default: 3."
    • addedInput schema / properties / template_id / description
      Added value: +"Template ID from the design template library."
  2. Changed8 schema fields changedv1.5.0
    • removedInput schema / properties / constraints / default
      Removed value: -""
    • addedInput schema / properties / constraints / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / max_variants / default
      Removed value: -27
    • addedInput schema / properties / max_variants / description
      Added value: +"Default: 27."
    • removedInput schema / properties / output_dir / default
      Removed value: -""
    • addedInput schema / properties / output_dir / description
      Added value: +"Default: \"\"."
    • removedInput schema / properties / samples_per_param / default
      Removed value: -3
    • addedInput schema / properties / samples_per_param / description
      Added value: +"Default: 3."
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations only say the tool is non-read-only, non-destructive and closed-world. The description adds real behavior the annotations cannot: it writes STL files to output_dir, it runs OpenSCAD generation plus structural analysis per variant, and the cost scales with samples_per_param and max_variants (defaults 3 and 27 imply a meaningful batch). It also discloses the inline 3D stage side effect and mesh decimation. It does not state expected runtime, failure modes, or what happens when constraints filter out all variants, which keeps it at 4.

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 core paragraph is well front-loaded and efficient, but the docstring-style ':param'/':returns' block largely duplicates the input schema verbatim, which is wasted length. The trailing INLINE 3D STAGE and MAKE DOORS sections are boilerplate that reads as appended context rather than part of this tool's definition, diluting focus.

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?

With no output schema present, the description usefully enumerates the return keys (best_params, best_score, best_grade, best_stl_path, variants_tested, all_scores, summary). Combined with the algorithm description and the file-output disclosure, an agent has enough to call it correctly and interpret results. Missing only edge-case behavior such as what is returned when no variant satisfies the constraints.

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 every parameter is already documented in the schema, including the defaults and the constraints JSON example. The description repeats essentially the same text in ':param' form (template_id, samples_per_param default 3, max_variants default 27, constraints JSON, output_dir temp dir) without adding format rules, units, or valid ranges. Baseline 3 applies since the schema does the heavy lifting.

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 states a specific verb and resource ('Find the structurally strongest version of a parametric template') and then spells out the mechanism: sweep each parameter, generate combinations via OpenSCAD, run structural analysis, return the best score. That is far more than a restated name. It stops short of a 5 because it never contrasts itself with adjacent siblings such as solve_template_constraints or validate_scad_parameters, so an agent still has to infer the boundary.

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?

It gives a clear positive trigger ('Use this when you want to automatically find optimal dimensions') plus a concrete example about wall thickness and bracket height, which is genuinely useful. However, there is no when-not guidance and no mention of the near-neighbor tools (solve_template_constraints, tweak_and_compile_scad, validate_scad_parameters) that an agent would need to rule out first. The appended 'MAKE DOORS' note about compile_scad is toolset context, not a routing rule for this tool.

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