AI for CAD Tools
What a CAD drawing measurement API returns, why the sheet, the solid and the property field disagree, and which interfaces need a licensed CAD seat open.
·
⏱
9 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
Reading a measurement out of a file you already own is four problems wearing one name. Decide first whether you need metadata, a derived geometric quantity, or the annotation an engineer actually placed, because the third is the hardest and the one people assume they are asking for. Expect the drawing text, the solid, and the property field to disagree, and treat overrides and graphical-only annotation as the usual causes. Pick the access pattern by what has to be running: a live desktop seat, a standalone reader, a cloud document interface, or a neutral geometry kernel. Then remember that the file interface cannot tell you whether the file is current. A correct number off a superseded sheet looks exactly like the right answer, which makes release state part of the measurement rather than a detail to check later.
Most of what gets written about CAD and APIs runs in one direction. Text goes in, geometry comes out. The quieter and far more common need runs the other way. You have forty thousand files on a server, a drawing someone released in 2019, and a question about a single bore diameter. Right now somebody has to open the file to answer it.
A CAD drawing measurement API is the machinery for answering that kind of question without a person opening anything. It is also where a lot of integration work quietly stalls, because "read the dimension" turns out to mean three different operations depending on where the number is stored, and because the file formats that hold engineering intent were never designed to be queried the way a database is. What follows is what these interfaces actually return, which of them need a licensed seat running somewhere in the background, and the point at which the number you read stops being the number that governs the part.
What a measurement API actually returns
The word measurement covers three separate operations, and almost every disappointing integration starts with a team assuming it asked for one and got another. Sorted by how easily they can be automated:
Metadata reads. Custom properties, configuration names, the revision field, the list of referenced components. These are values a person typed or a system stamped, stored alongside the geometry. Cheap to read, and available even in interfaces that cannot open a model.
Derived geometric quantities. Volume, mass, surface area, centre of mass, moments of inertia, bounding box, minimum distance between two faces. These are computed from the solid on request, so they are always consistent with the current geometry. They are also the ones no engineer ever placed on a drawing, which means they answer a different question than the one usually asked.
Annotation reads. The dimensions, tolerances and callouts an engineer deliberately placed, either on a 2D sheet or on the model as product and manufacturing information. This is what people mean in conversation, and it is the hardest of the three to get back out as data.
The gap between the second and third item is the whole problem. An API can tell you a hole is 12.004 mm across in the geometry it was handed. It takes a different kind of read to tell you the engineer called that hole 12 plus 0.02 minus 0, which is the only version of the number that a machinist or an inspector cares about.
IN PRACTICE
Leo uses a Large Mechanical Model trained on 1M+ technical sources. It also provides citations, so we don't have to guess whether a material property or tolerance is correct. We see 96% accuracy on technical queries.
- Dorian G., AI Engineer
Three places the number lives, and why they disagree
For any given feature, a released design usually carries the same quantity in three forms: the solid geometry, the annotation placed on top of it, and a property field somewhere in the file or the vault. They drift apart, and knowing how they drift is most of the skill in reading them programmatically.
Geometry is the only one of the three that cannot lie about itself, because it is measured fresh every time it is asked. It is also silent about intent. A 12.004 mm bore might be a 12 mm nominal with a deliberate allowance, or a modelling slip nobody caught. The geometry will not say which.
Annotation carries the intent, and this is where two specific traps live. On a 2D sheet, a dimension entity typically stores the value it measured from the geometry it points at, plus an optional text override that a person can type over the top. When those two disagree, an interface that reads the stored measurement and a human reading the printed sheet are looking at different numbers, and nothing in the file flags the conflict. On a 3D model, the distinction is between graphical and semantic annotation. Graphical annotation is drawn: arrows, leader lines and glyphs positioned in space, with no queryable value behind them, so reading it back means recognising pictures. Semantic annotation, which is what the STEP AP242 application protocol was extended to carry, stores the tolerance as structured data bound to the specific face it governs. The first is a picture of a requirement. The second is the requirement. If your supply chain has not committed to the second, the pitch for dropping drawings in favour of the annotated model gets much harder to make.
Property fields are the easiest to read and the least trustworthy, because they are usually maintained by hand. A material field or a stock size field that nobody updated after the last engineering change will be returned by the API with exactly as much confidence as a correct one.
Which interfaces need a seat open, and which do not
The practical question on most of these projects is not whether a measurement can be read, but what has to be running in order to read it. The answers divide into four patterns.
Desktop automation against a live session. The SOLIDWORKS API, the Creo toolkit interfaces and NX Open all drive an installed, licensed application. The interface is rich, because it reaches everything the user interface reaches, and it consumes a seat while it runs. Teams that go this route end up maintaining a dedicated machine whose only job is to open files on request, and they discover that one stuck modal dialog stops the queue.
Standalone readers that skip the application. The SOLIDWORKS Document Manager API is a separately licensed library that reads custom properties, configurations, references and preview images out of a file without starting SOLIDWORKS. It is well suited to crawling a directory for metadata. It is also explicitly not a geometry engine: it does not rebuild the model and it will not evaluate a measurement for you.
Cloud-native documents over a web interface. Onshape exposes documents through keyed web endpoints, including mass property calls at part and assembly level, and the ability to evaluate a FeatureScript expression against a document to compute something the stock endpoints do not cover. Because there is no desktop session in the loop, this runs on a server as naturally as any other service, which is a meaningful difference once a pipeline has to execute unattended. We went through the shape of that surface in more detail in what the Onshape API hands an agent.
Neutral geometry on a plain server. STEP and IGES files can be loaded by open geometry kernels, which means distance queries and mass properties run with no CAD license involved at all. What you give up is the feature tree, the configurations, and in the older STEP flavours the tolerance semantics. You get a shape, accurately, and very little about how it came to be that shape.
A newer wrapper around all of this is the Model Context Protocol, which puts a described tool surface in front of whichever of the four patterns is underneath. It changes how an assistant discovers and calls the operation, not what the operation can see, which is the distinction we drew in what a Model Context Protocol server can actually drive in SOLIDWORKS.
A 2D sheet is a different problem than a model
Teams that get model reads working often assume the drawing is the easy follow-on. It is usually the harder half, for four reasons that have nothing to do with each other.
First, views on a sheet are scaled projections. A length taken from sheet geometry has to be divided back through the view scale before it means anything, and a detail view at a different scale on the same sheet will quietly break a routine that assumed one factor. Second, the override problem above is concentrated here, because sheets are where people type over values under deadline. Third, a large share of released drawings exist only as exported or scanned sheets with no entities at all, just pixels. At that point the read is not a query, it is recognition, and the honest output is a value with a confidence attached rather than a value. That difference is exactly why a general purpose language model handed a drawing file produces something that reads plausibly and cannot be trusted dimensionally, which we worked through in why a chat assistant cannot read your CAD files.
Fourth, and most costly in practice: the file you measured says nothing about whether it is the file that governs. Released state, revision, and the change that superseded it live in PDM or PLM, not in the geometry. A measurement read correctly from a superseded sheet is still the wrong answer, and it arrives looking exactly like the right one. The boundary between what the file interface knows and what the data management interface knows is the same boundary we mapped in what the Teamcenter API actually gives engineering teams.
Making the answer available where the question gets asked
All of the above assumes the hard part is the call. On a real project it is not. The hard part is knowing which of forty thousand files to call it on, and then being able to show the person who asked why the returned number should be believed. An endpoint that answers a question about a known file does nothing for an engineer who does not know the file exists.
This is the layer Leo is built for. Leo is an AI assistant for mechanical engineers, trained on more than a million pages of standards, books and technical articles, and it reads CAD assemblies rather than treating them as opaque attachments. It connects to the knowledge base an organisation already has, so a question about a bore on a 2019 bracket starts by locating the bracket and the decisions around it, not by assuming someone already knows the file path. Leo offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others), which is how released state gets attached to a geometric answer instead of being assumed.
Leo sits on top of those systems as an intelligence layer rather than replacing them. The vault stays the vault and the release process stays the release process. What changes is that an engineer can ask in words, get the number, and see the source it came from. Every answer carries a citation the engineer can open, which matters more here than in most domains, because a dimension without a provenance trail is a dimension nobody will sign off. The platform is SOC-2 certified and GDPR compliant, no AI is trained on customer data, and intellectual property stays protected, which tends to be the first question asked when a tool is pointed at a vault full of released designs.
FAQ
Ask your own files the question
Leo reads your CAD assemblies and the knowledge base around them
See what an engineering assistant returns when the answer is already sitting in a file on your server, with a citation you can open and verify before anyone signs off.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
