Skip to main content
Glama

segment_mesh_regions

Split a 3D mesh into paintable surface regions defined by crease angle and minimum area, then display them so users can click regions and paint or assign materials.

Instructions

Split a mesh into paintable surface regions and show them.

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": {
      "input_path": "<input_path>"
    },
    "name": "segment_mesh_regions"
  }
}

Input Schema

NameRequiredDescriptionDefault
crease_degNoDihedral angle above which an edge bounds a region. Defaults to Kiln's shared crease angle. Lower finds more, smaller regions; higher merges them.
input_pathYesSTL, 3MF, OBJ or any mesh trimesh reads.
max_regionsNoCoarsen until at most this many regions remain. Omit for the mesh's natural partition.
partition_hashNoAccepted and ignored, so the whole ``segmentation_params`` bundle can be splatted into either tool. This call always mints its own from what it derives. Default: "".
include_face_mapNoAlso return the full face→region mapping (``face_map``: one int per input triangle, packed little-endian int32 and base64-encoded, in the input file's own triangle order). For apps that draw the mesh themselves and let the user click a region on it. Off by default — the map says nothing a person can read, and at the face ceiling it adds ~1.6 MB to the response. Default: false.
min_region_area_fracNoConfetti floor, as a fraction of total area. Both tools take it so the ``segmentation_params`` this call reports can be handed straight back to either of them and reproduce this exact partition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.5.1
    • addedInput schema / properties / crease_deg / description
      Added value: +"Dihedral angle above which an edge bounds a region.  Defaults to Kiln's shared crease angle.  Lower finds more, smaller regions; higher merges them."
    • changedInput schema / properties / include_face_map / description
      Previous value: -"Default: false."New value: +"Also return the full face→region mapping (``face_map``: one int per input triangle, packed little-endian int32 and base64-encoded, in the input file's own triangle order).  For apps that draw the mesh themselves and let the user click a region on it.  Off by default — the map says nothing a person can read, and at the face ceiling it adds ~1.6 MB to the response. Default: false."
    • addedInput schema / properties / input_path / description
      Added value: +"STL, 3MF, OBJ or any mesh trimesh reads."
    • addedInput schema / properties / max_regions / description
      Added value: +"Coarsen until at most this many regions remain.  Omit for the mesh's natural partition."
    • addedInput schema / properties / min_region_area_frac / description
      Added value: +"Confetti floor, as a fraction of total area.  Both tools take it so the ``segmentation_params`` this call reports can be handed straight back to either of them and reproduce this exact partition."
    • changedInput schema / properties / partition_hash / description
      Previous value: -"Default: \"\"."New value: +"Accepted and ignored, so the whole ``segmentation_params`` bundle can be splatted into either tool.  This call always mints its own from what it derives. Default: \"\"."
  2. Addedv1.5.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already indicate this is not read-only but is non-destructive. The description adds only that it splits and shows regions; it does not clarify what gets written, how the result is returned, or whether the input mesh is modified, so it adds little behavioral context beyond 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?

The description is a single front-loaded sentence with no wasted wording. 'Show them' is slightly vague, but the sentence is otherwise efficient.

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

Completeness2/5

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

For a six-parameter mesh operation with no output schema, the description does not explain the return shape, whether regions are persisted or only displayed, or how it differs from related painting and splitting tools. It is too thin for the tool's complexity and relies almost entirely on schema and annotations.

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 schema already documents all six parameters in detail. The description adds no parameter-specific meaning, and a baseline 3 is appropriate because the schema carries this dimension.

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 ('Split') and resource ('mesh') and names the output ('paintable surface regions') plus a display action. It is clear what the tool does, but it does not distinguish itself from siblings such as paint_mesh_regions or split_mesh_by_component.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of prerequisites, and no alternative tools are referenced. An agent must infer that this is the segmentation step before painting, rather than being told explicitly.

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