Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

tweak_and_compile_scad

Tweaks a named OpenSCAD parameter, checks material limits, and recompiles to STL in one step, refusing designs with floating pieces.

Instructions

Update a parameter in OpenSCAD code and recompile to STL.

        The complete parametric tweaking workflow: changes a dimension
        variable, validates against material limits, and compiles a new
        STL — all in one step. Perfect for "make it 5mm wider" requests.

        A tweak that leaves a piece floating with nothing under it is
        refused like a compile is (``code: "FLOATING_PIECES"``, the fix
        in ``error``).  ``color`` shows the part in the colour the user
        asked for, as on ``compile_scad``.

        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.
            scad_code: OpenSCAD source code.
            parameter_name: Variable name to update (e.g. "wall_thickness").
            new_value: New numeric value.
            material: Optional material for limit validation (e.g. "pla").
            color: The colour the user asked for, shown on the preview and
                the stage (a name or ``#rrggbb``).  Not a print setting.

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": {
      "scad_code": "<scad_code>",
      "parameter_name": "<parameter_name>",
      "new_value": "<new_value>"
    },
    "name": "tweak_and_compile_scad"
  }
}

Input Schema

NameRequiredDescriptionDefault
colorNoThe colour the user asked for, shown on the preview and the stage (a name or ``#rrggbb``). Not a print setting. Default: "".
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: "".
materialNoOptional material for limit validation (e.g. "pla").
new_valueYesNew numeric value.
scad_codeYesOpenSCAD source code.
parameter_nameYesVariable name to update (e.g. "wall_thickness").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 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: \"\"."
    • changedInput schema / properties / color / description
      Previous value: -"Default: \"\"."New value: +"The colour the user asked for, shown on the preview and the stage (a name or ``#rrggbb``).  Not a print setting. Default: \"\"."
    • addedInput schema / properties / material / description
      Added value: +"Optional material for limit validation (e.g. \"pla\")."
    • addedInput schema / properties / new_value / description
      Added value: +"New numeric value."
    • addedInput schema / properties / parameter_name / description
      Added value: +"Variable name to update (e.g. \"wall_thickness\")."
    • addedInput schema / properties / scad_code / description
      Added value: +"OpenSCAD source code."
  2. Changed3 schema fields changedv1.5.0
    • addedInput schema / properties / brief_id
      Added value: +{
+  "description": "Default: \"\".",
+  "title": "Brief Id",
+  "type": "string"
+}
    • addedInput schema / properties / color
      Added value: +{
+  "description": "Default: \"\".",
+  "title": "Color",
+  "type": "string"
+}
    • removedInput schema / properties / material / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false), it discloses real behavior: material-limit validation, the FLOATING_PIECES refusal with a fix in 'error', and that on success it opens an interactive 3D stage with automatic decimation and a PNG preview fallback. It also clarifies that 'color' is presentation only, not a print setting — exactly the kind of side-effect and output-shape context the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The workflow summary and the FLOATING_PIECES caveat are front-loaded and earn their space. The indented Args block restates the input schema word-for-word at 100% coverage, which is redundant, and the MAKE DOORS paragraph is somewhat meta, but neither obscures the core instruction.

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 mutating compile tool with no output schema, the definition covers what is needed: inputs, validation and refusal behavior, the error code to branch on, the stage/preview output surface, and how it fits when design_session is unavailable. Nothing essential for calling it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds genuine meaning on top by explaining that brief_id records the make against a saved goal and is checked against it, that material drives limit validation rather than slicing, and that color is not a print setting. It stops short of documenting the accepted color format or failure modes for an unknown parameter_name, which the schema also leaves open.

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?

The description opens with a specific verb-plus-resource ('Update a parameter in OpenSCAD code and recompile to STL') and then expands it into the three concrete steps: change a dimension variable, validate against material limits, compile a new STL. It names 'compile_scad' as the related sibling and 'design_session' as the goal source, so an agent can place it in the workflow 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 Guidelines4/5

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

It gives a concrete usage trigger ('Perfect for "make it 5mm wider" requests') and a clear prerequisite story for brief_id ('Empty when there is no goal'), plus the MAKE DOORS note that design_session is not installed here. What is missing is an explicit contrast with the closest sibling, update_scad_parameter plus compile_scad: it never says 'use this instead of calling those two in sequence', which is the main selection decision an agent faces.

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