Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

thicken_mesh_walls

Thicken thin part walls by offsetting surfaces outward by a set amount, fixing models flagged as fragile by printability analysis while keeping round holes sized for screws.

Instructions

Thicken a part's walls by moving every surface out amount_mm.

        Two routes, and the reply says which ran:

        * **The CAD file** -- pass the part's STEP file (``.step`` /
          ``.stp``), or a mesh Kiln converted from one that still sits
          beside it.  The CAD kernel moves every face exactly, and round
          holes keep their size so screws still fit.  Walls gain twice the
          amount; the outside grows twice the amount on every axis.
        * **A mesh** with no CAD file -- vertices are moved and the result
          is MEASURED against the input: the thinnest wall must gain at
          least the amount, the surface must stay closed, and every hole
          must survive.  A result that fails is refused with the
          measurements and your file is left as it was (on a part with
          holes and thin features this is the usual outcome -- use the
          CAD route).

        Openings that are not round holes (slots, vents, cutouts) narrow by
        twice the amount on either route.

        Use after ``analyze_printability`` or ``predict_print_failures``
        flags thin walls.

        AGENT DISPLAY CONTRACT: the reply carries a before|after
        self-check of the part.  Look at it and write what changed before
        calling the job done.

        :param file_path: The part: a STEP file, or a mesh (STL/OBJ/3MF).
        :param amount_mm: How far every surface moves out, in mm (0-5).
        :param output_path: Output path (defaults to ``<name>_thickened.stl``).
        :param keep_hole_size: Keep round holes at their diameter
            (default).  False lets them close in with everything else.
        :returns: ``path``, ``method`` (``cad`` or ``mesh``), the
            measurements before and after, and a ``note``; or a refusal
            saying why the result was worse than the part.

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": {
      "file_path": "<file_path>"
    },
    "name": "thicken_mesh_walls"
  }
}

Input Schema

NameRequiredDescriptionDefault
amount_mmNoHow far every surface moves out, in mm (0-5). Default: 0.5.
file_pathYesThe part: a STEP file, or a mesh (STL/OBJ/3MF).
output_pathNoOutput path (defaults to ``<name>_thickened.stl``). Default: "".
keep_hole_sizeNoKeep round holes at their diameter (default). False lets them close in with everything else. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / amount_mm / description
      Previous value: -"Default: 0.5."New value: +"How far every surface moves out, in mm (0-5). Default: 0.5."
    • addedInput schema / properties / file_path / description
      Added value: +"The part: a STEP file, or a mesh (STL/OBJ/3MF)."
    • changedInput schema / properties / keep_hole_size / description
      Previous value: -"Default: true."New value: +"Keep round holes at their diameter (default).  False lets them close in with everything else. Default: true."
    • changedInput schema / properties / output_path / description
      Previous value: -"Default: \"\"."New value: +"Output path (defaults to ``<name>_thickened.stl``). Default: \"\"."
  2. Changed5 schema fields changedv1.5.0
    • removedInput schema / properties / amount_mm / default
      Removed value: -0.5
    • addedInput schema / properties / amount_mm / description
      Added value: +"Default: 0.5."
    • addedInput schema / properties / keep_hole_size
      Added value: +{
+  "description": "Default: true.",
+  "title": "Keep Hole Size",
+  "type": "boolean"
+}
    • removedInput schema / properties / output_path / default
      Removed value: -""
    • addedInput schema / properties / output_path / description
      Added value: +"Default: \"\"."
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Far beyond the annotations, it discloses what happens on each route (walls gain twice the amount, non-round openings narrow), that the mesh result is verified against measurements and refused if worse, and that a failed run leaves the input file untouched. That refusal/no-damage behavior is exactly the context destructiveHint=false alone cannot convey, and it is consistent with the annotations.

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?

Well front-loaded: purpose, then route-by-route behavior, then the trigger, then params and returns, with the operational asides (display contract, inline stage) at the end where they don't crowd out the core. Slightly long, and the ':param' restatements duplicate the schema, but nearly every sentence carries information an agent needs.

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?

With no output schema, the description still specifies the return payload (path, method, before/after measurements, note, or a refusal explaining why) and the default output filename. For a four-parameter geometry mutation tool with two execution paths, that covers everything needed to call it and interpret the result.

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 baseline is 3. The description adds real meaning for amount_mm (surfaces move outward, walls gain double, holes preserved) and keep_hole_size, but the ':param' block largely restates the schema strings rather than extending them.

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 first line gives a specific verb and resource plus the geometry semantics: 'Thicken a part's walls by moving every surface out *amount_mm*.' It then splits the operation into two named routes (CAD kernel vs mesh) so an agent can tell exactly what it is and what it is not, which separates it from siblings like hollow_mesh_model or simplify_mesh_model.

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 explicitly names the trigger condition ('Use after analyze_printability or predict_print_failures flags thin walls') and gives route selection guidance: prefer the CAD route when a STEP file exists, since the mesh route usually fails on parts with holes and thin features. It does not cover when not to thicken at all (e.g. versus hollowing or scaling), so it stops short of a full when/when-not 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