Skip to main content
Glama

repair_mesh

Repair STL mesh defects: weld coincident vertices, remove zero-area triangles, and optionally close holes via fan triangulation. Returns repair statistics and a residual defect report.

Instructions

Repair mesh defects: rounding-noise seams, degenerates, holes.

        Every pass first welds vertices that are coincident up to a tiny
        radius (0.1 µm by default) — scanned and AI-generated meshes
        routinely carry float rounding jitter that reads as thousands of
        phantom open edges, and welding is the honest fix for those.  The
        default pass then removes zero-area triangles and recomputes face
        normals.  Pass ``close_holes=True`` for the deep pass, which
        additionally finds boundary edges (edges shared by only one
        triangle) and closes small holes via fan triangulation — use it
        when the mesh is not watertight.

        Hole closing refuses rather than ruins: sewing triangles that
        merely re-stamp existing surface are discarded, and a closure
        that collapses the enclosed volume is rolled back with the
        reason in ``unrepaired``.

        The result states the output's actual condition: ``is_watertight``
        (which also refuses to certify a sheet-cancelling zero-volume
        surface), remaining boundary/pinch edge counts,
        ``enclosed_volume_mm3`` when the surface closes up, and — when
        defects survive the pass — an ``unrepaired`` list saying which
        defect classes this tool has no repair for (pinched edges, where
        3+ triangles meet along one line, are not holes and cannot be
        sewn; they must be fixed where the geometry was made).  Read
        ``unrepaired`` before telling the user the mesh is fixed.

        :param file_path: Path to the STL file to repair.
        :param output_path: Output path.  Defaults to overwriting the input.
        :param close_holes: Also close open holes and fix boundary edges
            (slower; default False).
        :param weld_tolerance: Weld radius in mm.  Empty = auto (0.1 µm or
            a millionth of the part diagonal); "0" disables welding.
        :returns: Dict with repair statistics and residual-defect report.

INLINE 3D STAGE: on success this tool also 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYes
close_holesNo
output_pathNo
weld_toleranceNo
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

With zero annotations provided, the description correctly carries the full behavioral disclosure burden and does so extraordinarily well: it reveals the 0.1 µm weld radius and why ('scanned and AI-generated meshes routinely carry float rounding jitter'), the destructive default of overwriting the input, the rollback-and-report safety mechanism ('a closure that collapses the enclosed volume is rolled back with the reason in unrepaired'), the refusal semantics, and the visible side effect of opening the inline 3D stage. No annotation contradiction exists since no annotations are present; this is a masterclass in honest documentation.

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?

Efficiently front-loaded with a one-line summary followed by a short why-explanation for the welding step, then the algorithmic passes, safety, return contract, and finally the structured param block. Dense but nearly every sentence earns its place; only minor verbosity remains in the parenthetical 'or a millionth of the part diagonal' aside and the 'refuses rather than ruins' framing, though the latter also conveys useful non-guarantee semantics.

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?

For a tool with both file-mutating side effects (default overwrite) and a GUI side effect (3D stage), zero annotations, and no output schema, the description covers everything an agent must know: the exact return-contract keys (is_watertight, enclosed_volume_mm3, unrepaired), the failure domain (pinch edges it refuses to certify), performance characteristics, and error semantics. No meaningful information gap remains for an agent to fill by guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 0% schema description coverage, the description must document everything — and it does: file_path's STL type, the overwrite-by-default behavior of output_path, close_holes' performance cost, and weld_tolerance's unit, auto-scaling ('a millionth of the part diagonal'), and the "0" disables-welding sentinel. The docstring param block is the only place an agent could learn these semantics since the input schema only contains bare property names; the description more than compensates.

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 opening sentence states a specific verb+resource+defect set ('Repair mesh defects: rounding-noise seams, degenerates, holes'), localizing the tool in seconds. It then distinguishes the standard repair path from diagnostics found in siblings — this is the fixer, while tools like diagnose_mesh / analyze_mesh_geometry are inspection-only, and the explicit defect-class enumeration leaves no ambiguity about the resource being acted on.

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?

Clear contextual guidance is given for pass selection ('use it when the mesh is not watertight') and for what the tool will not do ('pinched edges... must be fixed where the geometry was made'), which constitutes useful when-not guidance. No sibling tool is named explicitly (contrast with a 'use search_calls_extensive for user/workspace filtering' pattern), and with repair_mesh_advanced in the same namespace a one-line pointer would have cinched a 5; nevertheless the deep-vs-default decision rule is explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'

If you have feedback or need assistance with the MCP directory API, please join our Discord server