Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

separate_overlapping_parts

Separates parts that share material so they print as a kit, cutting overlapping meshes and opening an interactive 3D stage to inspect the result.

Instructions

Separate parts that share material, so they print as a kit. Opens Kiln's interactive inline 3D stage on the result (orbit/zoom panel in MCP Apps hosts; hosted sessions add a browser stage link).

Needs Kiln Pro.

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": {
      "part_paths": "<part_paths>"
    },
    "name": "separate_overlapping_parts"
  }
}

Input Schema

NameRequiredDescriptionDefault
design_idNoOptional design to track this under — every cut part is registered as a version on a "separated" branch. Default: "".
nozzle_mmNoSets the sliver and thin-wall floors. Leave unset for the only printer Kiln knows of, else 0.4; ``nozzle`` in the reply says which.
trim_sideNoPer-pair override, ``{"arm|torso": "torso"}`` names the part to cut (a JSON string is accepted).
output_dirNoWhere the complete kit lands — every part, cut or not (default: a fresh temp directory). Default: "".
part_namesNoDisplay names aligned with ``part_paths`` (default: file stems); ``trim_side`` and the recipes use these.
part_pathsYesOne sealed mesh per part, positioned as assembled.
include_fusionsNoAlso separate a small part fused into a large one (a multi-colour inlay); off, those keep their merge suggestion. Default: false.
max_loss_fractionNoCumulative cap on what one part may lose across its neighbours (default 0.5). Default: 0.5.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"Optional design to track this under — every cut part is registered as a version on a \"separated\" branch. Default: \"\"."
    • changedInput schema / properties / include_fusions / description
      Previous value: -"Default: false."New value: +"Also separate a small part fused into a large one (a multi-colour inlay); off, those keep their merge suggestion. Default: false."
    • changedInput schema / properties / max_loss_fraction / description
      Previous value: -"Default: 0.5."New value: +"Cumulative cap on what one part may lose across its neighbours (default 0.5). Default: 0.5."
    • addedInput schema / properties / nozzle_mm / description
      Added value: +"Sets the sliver and thin-wall floors.  Leave unset for the only printer Kiln knows of, else 0.4; ``nozzle`` in the reply says which."
    • changedInput schema / properties / output_dir / description
      Previous value: -"Default: \"\"."New value: +"Where the complete kit lands — every part, cut or not (default: a fresh temp directory). Default: \"\"."
    • addedInput schema / properties / part_names / description
      Added value: +"Display names aligned with ``part_paths`` (default: file stems); ``trim_side`` and the recipes use these."
    • addedInput schema / properties / part_paths / description
      Added value: +"One sealed mesh per part, positioned as assembled."
    • addedInput schema / properties / trim_side / description
      Added value: +"Per-pair override, ``{\"arm|torso\": \"torso\"}`` names the part to cut (a JSON string is accepted)."
  2. Addedv1.5.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds two genuinely new behavioral facts: the Kiln Pro tier gate and the side effect of opening an interactive viewer panel with automatic mesh decimation. It never says what the call returns, whether failures are partial (some parts not separable), or how long it takes.

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

Conciseness2/5

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

The purpose is front-loaded in one good sentence, but the INLINE 3D STAGE paragraph restates the first paragraph almost verbatim (viewer panel, orbit/zoom, browser stage link for hosts that lack it) at roughly 40% of the total length. That duplication crowds out information the agent actually needs.

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

Completeness3/5

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

For an eight-parameter geometry tool with no output schema, the description should carry more about results and failure modes. It explains where output lands and the Pro requirement, but the budget is spent on viewer marketing rather than on what a successful reply contains or what happens when parts cannot be separated.

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 parameter descriptions are already detailed (trim_side syntax, max_loss_fraction default, nozzle_mm fallback). The description adds nothing about any of the eight parameters, which is acceptable given the schema coverage but earns only the baseline 3.

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?

States a specific verb and resource: separates parts that share material so they print as a kit. That is concrete enough that an agent can tell it apart from slicing or plate-arrangement siblings. It does not name the nearby alternatives it competes with (split_mesh_by_component, plan_assembly_split, compose_assembly_parts), so it falls short of a 5.

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?

The condition for use is implied by 'parts that share material' and 'Needs Kiln Pro' gives a hard prerequisite, which is more than most definitions offer. However, there is no explicit when-not guidance and no routing to sibling tools that also split or merge kit parts, so the agent must infer the choice.

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