AI for CAD Tools
What a SolidWorks MCP server can and cannot drive today: real API capabilities, deployment and auth limits, and where AI judgment still has to sit on top.
·
⏱
8 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
The Model Context Protocol does not add CAD intelligence, it adds a standard wire format for tools that already existed. For SolidWorks, every server built on it today wraps the same decades-old COM API used by VBA macros, so it can reliably read properties, pull a BOM, trigger a macro, or export a file, but it cannot reason about what change is actually correct, and it runs with whatever access the logged-in Windows user already has rather than a separate permission model. Treat a SolidWorks MCP server as a scriptable remote control, evaluate it the way you would a new macro from an unfamiliar source, and keep the harder judgment work, knowing which change is right for this part and this standard, in a layer built to reason over your own engineering knowledge rather than one built only to relay commands.
Search GitHub and more than one open source project calling itself a SolidWorks MCP server turns up. Some list over a hundred callable tools: read a custom property, pull a bill of materials, export a drawing, run a macro. None of them come from Dassault Systemes, and most say plainly, in their own documentation, that they are early and unfinished. That gap between what gets announced and what actually ships is worth closing before an engineering team wires an AI agent into a design environment on the strength of a demo video.
Here is what the Model Context Protocol actually standardizes, what a SolidWorks-facing server built on it can realistically drive today, where it runs out of road, and what still has to sit on top of the connection itself before any of it is trustworthy.
What MCP Actually Standardizes
The Model Context Protocol is an open specification Anthropic published in November 2024 and later handed to the Agentic AI Foundation, under the Linux Foundation, in December 2025. It solves one specific problem: before it existed, every AI assistant that wanted to read a file, query a database, or call an API needed a purpose-built connector, and every new tool needed a new connector built for every assistant separately. Anthropic described this as an N times M integration problem. MCP replaces the N times M with one shape: a host, which is the AI application itself, a client inside that host, and a server that exposes a defined set of tools and data. Host and server communicate over JSON-RPC, either locally through standard input and output or remotely.
None of that is CAD-specific. MCP does not know what a feature tree is, does not understand a tolerance stack, and ships with no built-in awareness of SolidWorks. What it standardizes is the wire format and the shape of the conversation: here is a list of tools, here is what each one needs as input, here is what it returns. Everything CAD-specific comes from whoever builds the server, and for SolidWorks that has so far been independent developers, not the vendor.
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
What a SolidWorks MCP Server Can Actually Drive Today
Every SolidWorks MCP project found in public repositories wraps the same underlying layer: the SolidWorks API, a COM automation interface that has existed since the 1990s and is the same interface behind VBA macros and most third-party SolidWorks add-ins. An MCP server puts a tool-calling interface in front of that API so an AI agent can invoke it by name instead of a person writing a macro by hand. Within that constraint, a handful of things are genuinely working in the projects available today:
Reading and writing custom properties on parts, assemblies, and drawings, the same properties that drive title blocks and Parts & BOM Management exports.
Pulling mass properties, configuration data, and bill of materials structure out of an open assembly.
Triggering existing macros and templated automation sequences, rather than writing new logic from a prompt.
Exporting to neutral formats such as STEP, and drawing formats like PDF or DXF.
Basic sketch and feature creation, where the feature is one the API already exposes a defined method for, such as an extrude or a hole wizard call with fixed parameters.
One project on GitHub lists 109 separate tools spanning modeling, sketching, drawing, analysis, export, automation, templates, and macros. That breadth is real, but it is breadth inherited from three decades of COM API surface, not a new capability MCP invented. The protocol is the delivery mechanism. The SolidWorks API is still doing all the work, with the same access rules and the same failure modes it has always had.
What It Cannot Drive Yet
The honest limitations show up in the same repositories that list the capabilities. More than one of these projects ships with a simulated or mock mode as the default, meaning a tool call returns a plausible-looking response without ever touching SolidWorks, and only switches to real automation once a developer explicitly enables it. That is a reasonable safety default for a project under active construction, but it means a demo transcript alone is not proof that a given action ran against a real model.
Three limits matter more for an engineering team evaluating this seriously:
There is no vendor-supported MCP server. Every project surfaced here is community-built, with no service level agreement, no certification, and no guarantee it keeps tracking the next SolidWorks release.
Generating new geometry from an open-ended prompt is not the same as calling an existing API method. A server can invoke a hole wizard or an extrude because the API defines a method for it. It cannot reliably turn "make this bracket lighter" into a correct feature sequence, because that judgment is not exposed as an API call for it to invoke.
The API is synchronous and single-session by design. It was built for one macro talking to one open SolidWorks instance, not for an AI agent making unattended, concurrent, or long-running changes across a vault of files.
None of this makes the protocol useless. It means the honest description of a SolidWorks MCP server today is a scriptable remote control for an API that already existed, not a new engineering capability on its own.
The Auth and Deployment Gap Nobody Advertises
The SolidWorks API is a local, in-process COM interface. It runs on the same Windows machine as SolidWorks, under the same user session, with the same file and network permissions that user already has. An MCP server wrapping it inherits that shape: it is not a hosted, multi-tenant service with its own login screen, it is a local process that needs SolidWorks installed, licensed, and already open on that machine.
That has real consequences for how a security-conscious engineering team should think about deploying one. There is no separate authentication layer between the AI agent and the CAD file the way there would be for a cloud API with scoped access; ontrol is whatever the operating system and the PDM vault already enforce for that logged-in user. Giving an agent write access through a server like this means giving it exactly the access that user has, including check-in and check-out rights in PDM if that user holds them. A read-only tool set is the safer starting point, and even then, an agent invoking a macro on a production file is still an agent running arbitrary automation with a live SolidWorks license attached to it. Any team piloting this should treat it the way it would treat a new macro from an unfamiliar source: reviewed, scoped, and run against a copy first.
Where an AI Intelligence Layer Fits On Top
Wiring an agent to the SolidWorks API, through MCP or otherwise, answers the question of how a command gets from a prompt to the software. It does not answer the harder question: how does the agent know which command is correct for this part, this material, this tolerance stack, this customer's standard. That is a knowledge problem, not a connection problem, and it is the gap most integration projects leave open.
Leo sits as an intelligence layer on top of an organization's existing PDM, PLM, and CAD environment rather than replacing the connection layer underneath it. It is trained on more than a million pages of standards, handbooks, and technical references, and it connects to a company's own knowledge base so an answer about a specific bracket or a specific tolerance is grounded in that company's prior designs and documented standards, with a citation attached, rather than a plausible-sounding guess. Whether the underlying CAD platform is SolidWorks, Autodesk, or something else barely changes that layer, because the value sits in knowing what should happen, not in which wire protocol carried the instruction.
Teams already comparing general-purpose assistants against SolidWorks or reading about what a general AI assistant can and cannot do inside AutoCAD are running into the same split: the wiring keeps getting easier, and the judgment layer is the part still worth being careful about. The same split shows up again for what an Onshape API hands an AI agent, and in the broader question of what an AI agent needs to actually do versus merely suggest inside a CAD workflow.
FAQ
See Leo AI Inside Your CAD Environment
Connect your standards and PDM data to one AI layer built for engineers.
Leo AI connects to your PDM, PLM, and CAD environment and answers engineering questions with citations from your own standards and design history.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
