Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

analyze_model_geometry

Read-only

Identifies overhangs, bridges, thin walls, and other slicing-critical regions in a 3D model so adaptive slicing parameters can be optimized per region.

Instructions

Detect geometric regions in a 3D model that affect slicing.

Analyzes model geometry to identify overhangs, bridges, thin walls,
top/bottom surfaces, fine details, and curved surfaces.  Each region
gets optimized slicing parameters in the adaptive plan.

Args:
    model_path: Path to an STL or 3MF file for analysis.
    model_stats: Pre-computed geometry statistics dict (from slicer
        preview or external tool).  Keys include ``height_mm``,
        ``overhangs``, ``bridges``, ``thin_walls``, etc.

Provide either ``model_path`` or ``model_stats`` (or both —
``model_stats`` takes precedence).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "analyze_model_geometry"
  }
}

Input Schema

NameRequiredDescriptionDefault
model_pathNoPath to an STL or 3MF file for analysis.
model_statsNoPre-computed geometry statistics dict (from slicer preview or external tool). Keys include ``height_mm``, ``overhangs``, ``bridges``, ``thin_walls``, etc.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / model_path / description
      Added value: +"Path to an STL or 3MF file for analysis."
    • addedInput schema / properties / model_stats / description
      Added value: +"Pre-computed geometry statistics dict (from slicer preview or external tool).  Keys include ``height_mm``, ``overhangs``, ``bridges``, ``thin_walls``, etc."
  2. Changed2 schema fields changedv1.5.0
    • removedInput schema / properties / model_path / default
      Removed value: -null
    • removedInput schema / properties / model_stats / default
      Removed value: -null
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond that the description adds the precedence rule between the two inputs and the downstream effect on the adaptive plan, but says nothing about failure behavior for bad/missing files, cost of analyzing large meshes, or what the analysis output looks like.

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

Conciseness5/5

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

Two short front-loaded sentences establish purpose and outputs, followed by a tight Args block. No filler, and the alternative-input rule is placed last where it matters most.

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?

Read-only, two optional parameters, no output schema — a modest surface. However, since there is no output schema, the description carries the burden of explaining what is returned, and 'each region gets optimized slicing parameters in the adaptive plan' is too vague to tell the agent whether this call returns regions, parameters, or a plan reference.

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 description coverage is 100%, so the baseline is 3, but the description earns extra credit by stating the interaction rule that both parameters may be supplied and that model_stats wins. The enumeration of stat keys (height_mm, overhangs, bridges, thin_walls) largely duplicates the schema, but the precedence semantics are genuinely new information.

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 opens with a specific verb and resource ('Detect geometric regions in a 3D model') and enumerates the region types it finds (overhangs, bridges, thin walls, top/bottom surfaces, fine details, curved surfaces). It is clearly not a generic mesh inspector, but it never names or contrasts with close siblings such as analyze_mesh_geometry, detect_mesh_pockets, or generate_adaptive_slicing_plan, so the agent must infer the boundary.

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?

Usage is only implied through the mention that regions feed the adaptive plan. The parameter paragraph does give a real selection rule ('provide either model_path or model_stats, model_stats takes precedence'), which is useful, but there is no guidance on when to call this versus the related geometry-analysis or slicing-plan tools.

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