Skip to main content
Glama

Fit Features to Mesh

mesh_to_features
Read-only

Use this when you are handed an STL, OBJ or 3MF of a mostly prismatic mechanical part (plate, bracket, spacer, flange, housing block) and need an EDITABLE kernelCAD model of it rather than a faceted lib.fromSTL import. Deterministic, measured, self-verifying: it welds and checks the mesh, segments planes and cylinders, picks the extrusion axis, slices each band and fits exact lines / arcs / circles, snaps near-round values (each snap recorded), then emits a readable .kcad.ts with named param()s — a revolve for concentric round stacks, extruded profiles otherwise, .hole()/.holes() for through, blind and counterbored bores (axial and side-drilled), .cutout() for pockets, .fillet() for constant-radius edge blends (radius measured on the sharp edge, edges grouped by radius and picked with the shortest exact edge query), boolean subtractions for what no drilling feature can reach. It then EVALUATES that script and compares it with the mesh: volume IoU (column ray casting) and symmetric surface deviation (max + RMS), over up to 4 refinement passes. Returns { script, ledger, fidelity: { maxDeviationMm, rmsMm, volumeIoU, verdict: faithful | approximate | failed, thresholds }, unmatchedRegions, features, passes }. A fillet or sharp reading is kept by which measures better; variable-radius blends and chamfers are reported, not forced. The verdict is computed from the numbers — faithful needs IoU >= minIoU AND max deviation <= maxDeviationMm AND a watertight mesh AND no unmatched region. Freeform surfaces, tilted planes and side bosses are listed in unmatchedRegions (reference.mesh.freeform-region-unmatched), never silently dropped. The ledger uses fact ids equal to param names, so resolve_assumptions on the written .ledger.json yields paramOverrides for set_param. Pass { out } to write the script and ledger; the mesh itself is never modified.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
outNoWrite the emitted script to this .kcad.ts path and the assumption ledger to the sibling .ledger.json.
dataNoMesh bytes as base64 — use when the server cannot see your filesystem.
fileNoPath to a .stl (binary or ASCII), .obj or .3mf mesh. One of file / data is required.
formatNoFormat override; default from the extension or the content.
minIoUNoVolume IoU a faithful verdict requires. Default 0.98.
maxPassesNoRefinement passes, 1–4. Default 4; stops early at the first faithful pass.
maxTrianglesNoRefuse meshes above this triangle count instead of stalling. Default 300000.
maxDeviationMmNoMax surface deviation (mm) a faithful verdict allows. Default max(0.25, 0.1 % of the bbox diagonal).
weldToleranceMmNoVertex weld distance in mm. Default max(1e-4, 1e-6 × bbox diagonal).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
meshNoClean-up and watertightness report for the input mesh.
errorNoFailure message (failure).
ledgerNoAssumptionLedger { facts, unresolvedCount }; dimension fact ids equal the param names (success).
passesNoPer-pass tolerances and measured fidelity.
scriptNoThe emitted, evaluable .kcad.ts source (success).
writtenNo{ script, ledger } paths when out was given.
featuresNoBody kind, hole groups, cutouts, boolean remainders, params (success).
fidelityNoMeasured fidelity of the returned script (success).
errorCodeNo
diagnosticsNo
notRepresentedNo
unmatchedRegionsNoSurface regions no emitted feature represents: { kind, reason, areaMm2, triangleCount, centroid, bbox }.
reconstructedHolesNoHoles the B-rep hole detector finds on the reconstruction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the full pipeline: mesh welding/checking, plane/cylinder segmentation, extrusion-axis selection, slice fitting, rounding with recorded snaps, script emission, evaluation against the mesh, and fidelity comparison over up to 4 passes. It also spells out safety properties ('the mesh itself is never modified'), verdict thresholds, and the 'never silently dropped' policy for unmatched regions.

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 long and dense, but every sentence earns its place: trigger, algorithm, output shape, fidelity criteria, limitations, and ledger workflow. It is front-loaded with the most decision-relevant facts. The lack of paragraph breaks makes it harder to skim, but for a tool this complex the length is justified.

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?

With an output schema present and 100% parameter coverage, the description still supplies the missing behavioral context: return object fields, exact verdict conditions, refinement-pass behavior, unmatched-region handling, and the ledger-to-`resolve_assumptions` workflow. An agent has everything needed to call the tool, interpret the result, and know when the result is trustworthy.

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?

The input schema already documents all 9 parameters at ~100% coverage, so the baseline is 3. The description adds meaningful context for `out` (sibling `.ledger.json`, param-name fact ids, `resolve_assumptions` workflow) and ties `minIoU`/`maxDeviationMm` directly into the verdict formula. It does not re-explain `maxTriangles`, `format`, or `weldToleranceMm`, but those are already well covered by the schema.

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 description opens with a concrete trigger: 'Use this when you are handed an STL, OBJ or 3MF of a mostly prismatic mechanical part' and names the deliverable ('editable kernelCAD model'). It clearly distinguishes this tool from a faceted import or simple mesh inspection, and the title aligns with the described behavior.

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?

The first sentence gives an explicit 'Use this when' condition, and the description names the alternative it avoids: 'rather than a faceted lib.fromSTL import.' It also states boundary behavior: freeform surfaces, variable-radius blends, and chamfers are reported, not forced. However, it does not explicitly name sibling tools or state direct 'do not use this for X' exclusions, so the guidance is clear but not fully exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.