AI for CAD Tools
A Model Context Protocol server exists for SolidWorks, Onshape, Fusion 360, and Creo, but only two of those are shipped by the vendor. Here is what each one actually reaches.
·
⏱
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
MCP support across CAD platforms splits cleanly into two tiers right now. Fusion 360 and Onshape have official, vendor-built servers, though Fusion’s reach into project data and Onshape’s narrow FeatureScript scope are not interchangeable capabilities. SolidWorks and Creo have no vendor server at all, only community projects that vary in maintenance and openly admit their own gaps. None of the four reaches across platforms, so a team standardizing on more than one CAD tool still needs a layer that reads across all of them rather than picking a different agent per platform.
Every major CAD platform now has something you could point to and call an MCP server. That single fact hides four very different situations. An MCP server that a vendor built, tested, and put in its own app store is not the same thing as a solo GitHub repository maintained by one contributor in their spare time, even when both technically speak the Model Context Protocol and both let an AI agent "connect to your CAD tool." One has a support contract behind it. The other has an open issue tracker and a project page that says, in its own words, that it is early and unfinished.
This matters because an engineering team deciding whether to wire an AI agent into SolidWorks, Onshape, Fusion 360, or Creo is really asking two separate questions at once: does an MCP server exist for this platform, and if so, who built it and what did they actually let it touch. Below is what each of the four looks like today, checked against the vendors’ own documentation and the projects’ own scope statements rather than the vendor’s marketing page.
MCP Servers, and Why the Label Alone Tells You Nothing
The Model Context Protocol is an open standard for how an AI agent discovers and calls tools, not a certification of what those tools do. Anyone can stand up a server that speaks MCP correctly and wraps almost nothing underneath it, and anyone can point an AI agent at a CAD platform’s existing scripting API and call the result an MCP server. Both are technically accurate descriptions and neither tells you whether the agent can read a bill of materials, edit a parameter, or only fetch a file name.
Three questions cut through the label every time: who built and maintains it, what surface of the CAD tool does it actually wrap, and does that surface include the data a real engineering task needs, such as assembly structure, parameters, or a BOM, rather than only project metadata like folders and permissions. A fourth question matters just as much in practice: where does the server run. A vendor-hosted server usually inherits that vendor’s existing login and permission model, so an agent only sees what the person connecting it is already allowed to see. A community-built server more often runs locally against the same files a person could open by hand, which keeps design data off any outside network but also means access control is whatever the local machine already enforces, nothing more.
The next four sections answer those questions platform by platform: two platforms with no vendor server at all, one with a narrow official server, and one with the broadest official coverage of the four.
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
SolidWorks: Community-Built, and Dassault Has Not Shipped One
Search for a SolidWorks MCP server and more than one open source project turns up, several with long lists of callable tools covering custom properties, bills of materials, drawing export, and macro execution. None of them come from Dassault Systemes. Each is maintained by an individual developer or a small group, versions and reliability vary between them, and more than one project’s own documentation says plainly that it is early and unfinished. There is no vendor-hosted endpoint, no official support channel, and no guarantee that a given server keeps working across a SolidWorks version update.
That does not make these servers useless. It means the burden of vetting, securing, and maintaining the connection sits entirely with whoever installs it, with no vendor to file a ticket against when something breaks. A closer look at what one of these servers can actually drive today, tool by tool, is in our SolidWorks MCP breakdown. AutoCAD sits in the same position: several independent servers, each wrapping a different automation surface, and none of them built or supported by Autodesk either.
Onshape: An Official Server, Narrowly Scoped to FeatureScript
Onshape is the one platform in this comparison where the MCP server is genuinely official. Onshape Labs, PTC’s early-access program for emerging Onshape technology, ships a FeatureScript MCP Server through the Onshape App Store. It lets an AI client generate FeatureScript, Onshape’s native programming language, from a plain-language description, insert that code into a document, run it, and refine it based on the result. The output is a reusable custom feature that behaves like a native toolbar command afterward, not a one-off model.
The scope is deliberately narrow. As Onshape frames it, the agent is not asked to generate geometry directly, it is asked to generate the code that defines how geometry gets created. That is a meaningfully different, and safer, boundary than letting an agent edit a model directly, but it also means this server answers "build me a custom feature," not "read this assembly and tell me what changed." For that second question, an agent is back to going through Onshape’s regular REST API, with its own separate set of limits covered in what that API actually hands over.
Fusion 360: The Fullest Official Coverage, Split Across Two Servers
Autodesk ships two separate official MCP servers for Fusion, and the split between them is the detail worth knowing before wiring either one in. The Fusion Data MCP server operates at the project and organization layer: it can navigate hubs and projects, create and organize folder structures, add team members and set their permissions, and manage items within folders. By Autodesk’s own description, it does not touch active design geometry, modeling operations, or a live design session at all.
The separate Fusion MCP server is the one that reaches into an actual design session, built on top of Fusion’s existing API and scripting ecosystem to carry out modeling steps and multi-step design changes. Autodesk has been explicit that this is part of a broader company strategy to give AI systems trusted, secure access to real design workflows, not a side project. Between the two servers, Fusion 360 has the most complete official MCP coverage of the four platforms here, though a team still has to pick the right one for the task: project administration versus in-model changes are two different servers, not one. Where Fusion’s AI coverage sits relative to Autodesk’s other native tools is covered in our full Fusion 360 AI tools review.
Creo: No Official Server, and Where That Leaves an Agent
PTC has not shipped an official MCP server for Creo Parametric, even though its Onshape team, also part of PTC, has already released one for a different product line. The active project in the Creo space is CREOSON, a longstanding open source toolkit for programmatic Creo access, maintained by an individual community contributor, which now has an experimental AI MCP interface layered on top. Community testing has shown it handling real tasks, including generating technical drawings from part models and adjusting Pro/PROGRAM logic for assembly configurations, but the same discussion is candid about the gap: the API for the operations people actually want to control is not fully exposed, and sketch-level automation remains unreliable. The project’s own roadmap talks about packaging its capabilities into guided "skills" so an agent understands what CREOSON can and cannot do, which is itself an admission that the raw connection is not self-explanatory yet.
That leaves Creo in a similar position to SolidWorks: usable through community effort, but with no vendor commitment behind the connection and real edges to the API surface underneath it. It also leaves a gap none of these four servers close on their own, since each one only reaches its own platform. A team running SolidWorks for one product line and Creo for another still needs something that reads across both, plus the PDM and ERP systems sitting next to them, and answers a question in one place instead of four. That cross-system retrieval, rather than in-model editing, is exactly where Leo sits: on top of whichever CAD tool a team already runs, MCP server or none, reading across it and the PLM, PDM, or ERP data around it. The same built-versus-bought pattern shows up one layer up the stack too, in what each major CAD and PLM vendor’s own built-in AI actually ships.
FAQ
See What Leo Reads Across Your Stack
One retrieval layer across CAD, PDM, PLM, and ERP, no MCP server required.
Whichever CAD platform your team runs, and whichever of these servers it has or lacks, Leo reads across your tools and answers questions without waiting on a vendor roadmap.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
