Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

splice_mesh_at_z

Combine top geometry from one STL with bottom geometry from another at a specified Z plane, clipping boundary triangles to create clean design iterations.

Instructions

Splice two meshes at a z-plane: top from one STL, bottom from another.

        Takes geometry ABOVE *z_plane* from *top_path* and geometry BELOW
        *z_plane* from *bottom_path*.  Triangles crossing the boundary are
        clipped cleanly.  No boolean ops -- works on non-manifold meshes.

        **Use case:** Combine a body with the correct top (e.g. logo from
        v5.3) with a body that has the correct bottom (e.g. larger pocket
        from v5.4) to create the next design iteration.

        :param top_path: STL providing geometry above z_plane.
        :param bottom_path: STL providing geometry below z_plane.
        :param z_plane: Z height (mm) where the splice happens.
        :param output_path: Output STL path. Auto-generated if empty.
        :returns: Dict with splice stats and output path.

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": {
      "top_path": "<top_path>",
      "bottom_path": "<bottom_path>",
      "z_plane": "<z_plane>"
    },
    "name": "splice_mesh_at_z"
  }
}

Input Schema

NameRequiredDescriptionDefault
z_planeYesZ height (mm) where the splice happens.
top_pathYesSTL providing geometry above z_plane.
bottom_pathYesSTL providing geometry below z_plane.
output_pathNoOutput STL path. Auto-generated if empty. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • addedInput schema / properties / bottom_path / description
      Added value: +"STL providing geometry below z_plane."
    • changedInput schema / properties / output_path / description
      Previous value: -"Default: \"\"."New value: +"Output STL path. Auto-generated if empty. Default: \"\"."
    • addedInput schema / properties / top_path / description
      Added value: +"STL providing geometry above z_plane."
    • addedInput schema / properties / z_plane / description
      Added value: +"Z height (mm) where the splice happens."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / output_path / default
      Removed value: -""
    • addedInput schema / properties / output_path / description
      Added value: +"Default: \"\"."
  3. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing that crossing triangles are clipped cleanly, that non-manifold input is tolerated, and that success opens an interactive 3D stage with automatic decimation of oversized meshes. It doesn't say whether an existing file at output_path is overwritten, which matters for a non-destructive-but-writing tool.

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?

Front-loaded with the core behavior, then mechanics, then use case, then a returns note. The repeated :param lines duplicate the schema and could be trimmed, but overall the text is tight and skimmable.

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, the description correctly summarizes the return value as a dict of splice stats plus output path, and it warns about the inline stage side effect. What's missing is only edge-case behavior, such as what happens when z_plane falls outside one mesh's bounds.

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%, and the :param blocks restate the schema text almost verbatim, adding no new meaning such as units handling or path format expectations. The only marginal addition is that output_path is auto-generated when empty, which the schema already states.

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 (splice two meshes at a z-plane) and immediately defines the split semantics: geometry above z_plane from top_path, below from bottom_path. The line 'No boolean ops -- works on non-manifold meshes' separates it from mesh-boolean siblings such as boolean_mesh_op and merge_mesh_files.

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?

Provides a concrete use case (take the correct top from v5.3 and the correct bottom from v5.4 to make the next iteration), which tells the agent when the tool is the right choice. It never names an alternative tool to use instead when a true boolean union is wanted, so the exclusion is implied rather than stated.

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