How to Connect Claude to AutoCAD (MCP, 2026)

People keep searching for how to plug Claude into AutoCAD, and the answers online are mostly demo videos with the boring parts cut out. Here is the honest version: what Autodesk actually ships, what the community servers do, the requirements that will stop half of you at step one, and the class of work this setup still cannot touch no matter how good the model gets.

What MCP actually is

The Model Context Protocol is an open standard Anthropic published in late 2024 for connecting AI assistants to outside tools and data. The useful mental model is a plug standard rather than a feature: an MCP server exposes a set of tools, and an MCP client such as Claude Desktop or Claude Code discovers those tools and calls them on your behalf. The protocol itself knows nothing about CAD.

That distinction matters for expectations. When somebody says “Claude can now use AutoCAD”, what they mean is that somebody wrote a server exposing AutoCAD operations as tools, and Claude is calling them. The quality of the result depends on that server as much as on the model. It is closer to giving Claude a keyboard than to giving it CAD skills.

What Autodesk officially ships

This is where most write-ups get sloppy, so be precise about it. Autodesk has released the Product Help MCP Server, which gives AI assistants secure, read-only access to official Autodesk help content across more than 110 products, at no cost. It is genuinely useful. If you have ever lost twenty minutes to a command flag or a system variable, having the documentation answerable in conversation is a real time saver.

It also does not touch your drawings. It reads documentation. Autodesk has separately published guidance on building MCP servers against Autodesk Platform Services, which covers cloud side work such as browsing hubs and projects through the Data Management API. That is document management, not drafting.

The servers that drive the desktop app

Several community projects expose AutoCAD itself. They differ mostly in how they get commands into the application, and the route determines what works.

Headless script execution

Runs .scr and .lsp scripts against .dwg files using accoreconsole.exe, the console version of AutoCAD. No visible application, no user interface, which makes it the right shape for batch work across many files. You will not get a screenshot back, so verification is on you.

AutoLISP dispatch into the running app

The most common approach on LT. One well documented project posts keystrokes into AutoCAD's window to trigger an AutoLISP dispatch command, exchanging commands and results through JSON files on disk. It is inventive, and it works, and it is also exactly as fragile as it sounds if the window loses focus or a modal dialog appears.

A .NET plugin

A custom plugin loaded inside AutoCAD gives real-time command execution with a proper API rather than synthesised keystrokes. Cleaner, but it needs full AutoCAD rather than LT, since LT does not load .NET plugins.

Tool coverage across these projects lands in a similar place: creating and opening drawings, entity operations for lines, circles, polylines, arcs and rectangles, layer management, blocks and attributes, text and dimensions, viewport control, plotting and export. Some go further with P&ID symbols, external references and layout handling. One exposes eight consolidated tool groups, another nineteen, and the difference is mostly packaging.

What you need before you start

This section will save some of you an afternoon. The requirements are stricter than the demo videos suggest.

Two disappointments worth stating plainly. AutoCAD LT for Mac does not support AutoLISP, so the LISP based servers will not run there at all. And LT has no ActiveX or COM automation and no Visual LISP IDE, which rules out any project built on those older automation paths, including a fair number of tutorials still floating around.

Individual tools have their own gaps too. In at least one project, offset, fillet and chamfer work only through the live application path and not the headless backend, and the P&ID tools need a specific third-party symbol library installed at a specific path. Read the limitations section of whichever project you pick before you build a workflow on it.

Wiring it up

1. Pick a server and read its source. These are community projects of varying maturity, and you are about to give one write access to your drawings. Half an hour reading beats a week recovering.
2. Check your AutoCAD version and edition against the table above. This is where most attempts stop.
3. Install the server and its dependencies natively on Windows, following the project instructions rather than a video.
4. Register the server in your MCP client config so Claude Desktop or Claude Code can see it. Restart the client afterwards.
5. Open AutoCAD and load whatever plugin or LISP the server needs.
6. Test on a scratch drawing. Ask for something small and verifiable, like a rectangle at a known size on a named layer, and confirm it landed correctly before trusting anything larger.

What it is genuinely good at

Having used this class of tooling, the pattern is consistent. It is strong wherever the work is describable in words and tedious to do by hand:

• Repetitive geometry. A bolt pattern, a grid of identical openings, a run of parallel lines at a fixed spacing. You describe the rule and it executes it.
• Layer and standards cleanup. Auditing a drawing against a layer standard and moving entities where they belong is exactly the kind of tedious pattern matching this handles well.
• Batch operations. The headless path over a folder of drawings, running the same export or purge on each.
• Scripting without learning AutoLISP. Describing what you want and having it write and run the LISP is a real productivity shift for people who never had time to learn it.
• Answering questions about a drawing, such as counting entities on a layer or reporting which blocks are used.

For a wider view of what current models can and cannot do with CAD data generally, our post on whether Claude can read CAD files covers the format side, and whether Claude can make technical drawings covers the drawing side without any MCP involved.

What it still cannot do

Here is the part the demo videos skip, and it is the part that decides whether this solves your actual problem.

An MCP server gives Claude a command channel, not perception. It can issue a command to draw a 40 by 25 rectangle. It has no way to know that your part is 40 by 25 unless you tell it. Every dimension in the output came from you or from a guess, and a confidently drawn guess is worse than no drawing at all.

That rules out the thing most people actually want. If you have a physical part, a photo, a scanned sketch or a supplier drawing, and you want a dimensioned CAD drawing of it, no AutoCAD MCP server will get you there. The bottleneck is not the command channel. It is working out the geometry and scale from an image, which is a different problem entirely, covered in getting dimensions from a photo.

The other honest limits:

• It does not know your standards. Title blocks, layer conventions, dimension styles and the way your shop wants things annotated all have to be specified, every time, unless you build them into a template first.
• Verification is still yours. The headless path gives you no visual feedback at all, and even with screenshots you are the one deciding whether the drawing is right.
• It is not deterministic. The same request twice can produce slightly different command sequences. Fine for exploratory work, a problem for anything you need to reproduce exactly.
• Complex or fragile drawings punish it. Deeply nested references, heavy constraints and unusual custom objects are where things go quietly wrong.

Letting a model run code on your machine

This deserves more attention than it gets. Several of these servers expose a tool that executes arbitrary AutoLISP, which is the point, since it is what makes them flexible. It also means the practical trust boundary is not the tool list, it is whatever the model decides to write.

At least one project drives AutoCAD by posting keystrokes into the running application window. That works, and it also means anything else listening to that window is part of the picture, and a stray dialog can put a command somewhere you did not intend.

Sensible precautions, none of which are exotic:

• Work on copies, not live production drawings, until you trust the setup.
• Keep it off shared network pathswhere a mistake becomes everyone's mistake.
• Have real version control or backups, because undo across a scripted batch is not a plan.
• Read what the server exposes and disable the tools you do not need.
• Watch the first runs. Approving tool calls one at a time is tedious and it is also how you learn what it actually does.

Where this fits in a real workflow

The clean way to think about it is that these are two different problems with two different tools.

They compose well. Generate the drawing from the part with TechDraw AI, export DWG or DXF, open it in AutoCAD, then let an MCP server handle the repetitive cleanup and standards work inside the file. What does not work is expecting one of them to do the other's job, which is where most of the disappointment with this tooling comes from.

If you are choosing where to spend your setup time: the official docs server is free and takes minutes. A desktop server is worth it if you do genuinely repetitive AutoCAD work and are on a supported Windows setup. And if what you actually needed was a drawing of something you can photograph, start there instead, because no amount of MCP configuration will get you to it.