Skip to main content
Glama
ottonic

cad-mcp-server

by ottonic

Measure Geometry

measure
Read-onlyIdempotent

Computes distance, thickness, draft, ray-grid hits, point geometry, sections, and edge continuity from STEP entity IDs for CAD inspection and validation.

Instructions

Measure distance, wall thickness, draft, rays/ray grids, point geometry, planar sections, or edge continuity. Use the artifact reference and entity IDs from the same find_entities result. Lengths are in the declared unit, which is labelled on every result. Ray grids report their grid size and can be refined with max_rays up to 20000. Fetch the cad://help resource for the required fields of each kind. Returns geometric measurements only, not engineering acceptance or design recommendations.

Input Schema

NameRequiredDescriptionDefault
kindYesMeasurement to perform. Each kind takes a different argument set; see the field notes here and the per-kind requirements in cad://help.
checksNopoint_analysis: one or more of contains_body, classify_face, closest_face_point, surface_curvature, edge_projection.
detailNoPer-sample detail to return: "stats" (default), "samples", or "hits".
originNoray and ray_grid: explicit ray origin [x, y, z]. Mutually exclusive with origin_mode.
pointsNopoint_analysis: points to test, in model coordinates (mm), up to 100.
sourcesNodistance only: entities to measure from (face:N, edge:N, body:N, or a component-scoped form).
spacingNoray_grid: grid pitch in the STEP artifact’s declared length units, at most 1000.
summaryNodistance only: "all" returns every pair, "minimum" (default) returns the closest pair only.minimum
targetsNodistance only: entities to measure to.
artifactYesRevision-bound STEP reference from inspect: { uri, revision, format, units }. Rejected if the file changed since inspect.
max_raysNoray_grid and thickness: maximum ray casts, 1 to 20000. Default 4000. Raising it allows a finer grid at proportionally higher cost.
directionNoray and ray_grid: ray direction as an explicit [x, y, z] vector. Mutually exclusive with direction_mode.
toleranceNocontinuity and point checks: geometric tolerance in millimetres.
entity_idsNoEvery kind except distance: the entities to measure. Faces for thickness, draft, ray and ray_grid; edges for continuity; faces or bodies for section and point_analysis. Up to 100 IDs.
origin_modeNoray and ray_grid: place the origin at the entity extent instead of passing origin: extent_min, extent_center (default), or extent_max.
max_distanceNoray, ray_grid and thickness: ignore hits beyond this distance in the STEP artifact’s declared length units.
plane_normalNosection: cutting-plane normal.
plane_originNosection: a point on the cutting plane.
bidirectionalNoray and ray_grid: also shoot from the origin in the opposite direction.
direction_modeNoray and ray_grid: "axis" shoots along the entity axis, "normal" along the entity normal (faces only). Mutually exclusive with direction.
pull_directionNodraft only: mould pull direction as an explicit [x, y, z] vector. Mutually exclusive with pull_direction_mode.
pull_direction_modeNodraft only: "axis" or "normal" shortcut for the pull direction (faces only). Mutually exclusive with pull_direction.

Output Schema

NameRequiredDescriptionDefault
kindYes
unitsYes
artifactYes
subjectsYes
coordinate_frameYes
entity_id_schemeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.1

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: units are declared and labelled on every result, ray grids report their grid size, max_rays can be raised to 20000, and the tool deliberately returns geometric measurements rather than engineering judgments.

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?

The description is front-loaded with the measurement kinds and then adds only operational constraints, units, ray-grid behavior, help-resource guidance, and output scope. Every sentence contributes useful selection or invocation context without becoming a parameter manual.

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?

Given the tool's complexity, the full input schema, the output schema, and the read-only annotations, the description provides enough context for correct selection and invocation. The cad://help pointer is especially important for the kind-specific argument sets, and the output schema can carry return-value details.

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 input schema already carries most parameter meaning. The description adds some useful context, including that artifact and entity IDs should come from find_entities, that lengths use the declared unit, that max_rays can reach 20000, and that cad://help documents per-kind required fields, but it does not substantially explain the 22-parameter surface beyond 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 starts with a specific verb, "Measure", and enumerates the exact measurement kinds the tool performs: distance, thickness, draft, rays, point geometry, sections, and continuity. It also clarifies the boundary that results are geometric measurements only, not engineering acceptance or design recommendations, which helps distinguish it from downstream analysis tools.

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?

It gives clear prerequisite guidance: use the artifact reference and entity IDs from the same find_entities result, and fetch cad://help for the required fields of each kind. It does not explicitly compare when to use measure versus siblings like inspect, diff, or describe_pmi, so it stops short of full when/when-not guidance.

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