Skip to main content
Glama
ottonic

cad-mcp-server

by ottonic

Describe Model PMI and GD&T

describe_pmi
Read-onlyIdempotent

Reports dimensions, geometric tolerances, and datums declared in a STEP file, and checks dimensional callouts against controlled faces as satisfied, violated, or unresolved.

Instructions

Report the dimensions, geometric tolerances, and datums that a STEP artifact declares, as data: nominal, deviations, and tolerance form for each dimension; value, zone shape, material requirement, and datum references for each geometric tolerance; and the entity IDs each annotation applies to. characteristics checks each dimensional callout against the faces it controls, and reports satisfied or violated where that is arithmetic — a diameter read from the cylindrical faces the callout names — and unresolved with a reason everywhere else, so a callout that was not checked cannot be mistaken for one that was. Check value_resolved before comparing anything yourself. It is false when the magnitude could not be read and is reported as 0.0, which is what a genuine zero callout also reports; a location dimension defining a tolerance frame has no value of its own. A basic dimension comes back not-applicable: it defines a tolerance frame and states no limit of its own. An angle or a location callout comes back unresolved with needs-frame, because the angle between two faces and a location dimension direction both depend on the frame the callout is stated in. A datum reference carries the entity IDs of the shapes its datum is attached to. Without them a tolerance naming that datum cannot be evaluated, so report the datum as unlocated rather than treating the tolerance as met. unlocated_datums names those references for you; a tolerance that carries it is not checkable, and saying which datum is missing is the useful answer.Counts report both datum references and distinct datums, because a frame names its references one by one and the same datum appears once per frame. Values are in the declared unit, the same unit this server uses for measurements. Read pmi_kind before describing what a file does or does not declare: semantic means the callouts are readable data; graphical-only means the file does show requirements, drawn rather than encoded, so say they must come from the drawing or the engineer instead of saying the model declares none; none means it declares nothing at all. Use the artifact reference from inspect; entity IDs are valid only for that revision.

Input Schema

NameRequiredDescriptionDefault
uriYesSTEP file to read, as a file: URI or an absolute filesystem path.
includeNoSections to include: dimensions, tolerances, datums. Default: all three. Example: ["tolerances"].

Output Schema

NameRequiredDescriptionDefault
unitsYes
countsYes
datumsNo
artifactYes
pmi_kindYes
warningsYes
unit_noteNo
dimensionsNo
characteristicsNo
coordinate_frameYes
geometric_tolerancesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.1

TDQS

A4.6/5.0
Behavior5/5

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

Although annotations already mark this as a safe read-only operation, the description adds substantial behavioral context: how unresolved values arise, why basic dimensions are not-applicable, why angles and location callouts need a frame, how unlocated datums affect checkability, and that entity IDs are revision-bound. This goes well 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 purpose is front-loaded in the first sentence and the rest is dense with necessary domain guidance. It is longer than typical, but most sentences carry checkable behavioral rules; a small amount of repetition around unresolved callouts could be trimmed.

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 complexity of PMI/GD&T semantics, the description is complete enough for an agent to interpret the output correctly, especially alongside the existing output schema. It covers value resolution, frame dependence, datum location, pmi_kind distinctions, and unit assumptions.

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 coverage is 100%, so both parameters are already documented. The description reinforces that the URI should come from inspect and that entity IDs are valid only for that revision, but it adds little about the include parameter beyond the schema's own enum values.

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 specific verb and resource: 'Report the dimensions, geometric tolerances, and datums that a STEP artifact declares, as data.' It clearly distinguishes this from sibling tools like inspect and measure by emphasizing declared PMI data rather than file discovery or measurement.

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

Usage Guidelines5/5

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

It gives explicit usage guidance throughout: check value_resolved before comparing, treat unresolved callouts as not checkable, interpret pmi_kind before saying a file declares nothing, and use the artifact reference from inspect. These are direct when/when-not instructions tied to the tool's domain.

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