How to Connect Claude to SOLIDWORKS with MCP

To connect Claude to SOLIDWORKS, you run a small local program called an MCP server on the same Windows machine as SOLIDWORKS, register it in Claude Desktop’s claude_desktop_config.json, and restart Claude. The MCP server exposes a handful of “tools” (read custom properties, export a PDF, list assembly components) and implements each one with ordinary SOLIDWORKS API calls. Claude decides when to call a tool; the server does the actual work through the SOLIDWORKS COM API. Claude never touches SOLIDWORKS directly.

The rest of this article explains the moving parts, shows a generic configuration, walks through a minimal server you can build yourself, and covers what works well today and what does not.

What MCP is, in plain terms

MCP (Model Context Protocol) is an open protocol that defines how an AI application talks to external tools. Think of it as a standard plug shape. Instead of every AI client inventing its own way to call your code, the client speaks MCP, your server speaks MCP, and they agree on three things:

• Discovery: the server tells the client which tools it offers, with a name, a plain-language description and a schema for the parameters.
• Invocation: the client asks the server to run a tool with specific arguments.
• Results: the server returns text or structured data, which the model reads and reasons about.

For a local integration like SOLIDWORKS, the transport is usually standard input and output: Claude Desktop launches your server as a child process and exchanges JSON messages with it over stdin/stdout. No ports, no web server, nothing exposed to the network.

Why Claude needs a tool server to act on SOLIDWORKS

A language model on its own can only produce text. It can write you a VBA macro, explain what IModelDoc2.SaveAs3 does or suggest a configuration naming scheme, but it cannot open your assembly. SOLIDWORKS is automated through its COM API, which only works on the machine where SOLIDWORKS is installed and running. Something local has to hold a reference to ISldWorks and make the calls.

That is the MCP server’s job. It is the bridge between a model that reasons in text and a desktop application that only understands COM. This also explains why simply pasting files into ChatGPT or Claude gets you so little: the model sees a binary SLDPRT, not the feature tree, the properties or the references. If you want to compare what chat-only AI can and cannot do for engineering, our SOLIDWORKS AI vs ChatGPT showdown covers that ground.

The architecture: client, server, SOLIDWORKS API

There are three layers, and it helps to keep them separate in your head:

Layer	Runs where	Responsibility
Claude Desktop (MCP client)	Your Windows workstation	Chat interface, sends prompts to the model, decides which tools to call, asks you to approve calls
MCP server	Local process launched by Claude Desktop	Declares tools, validates arguments, calls the SOLIDWORKS API, returns results as text
SOLIDWORKS + COM API	Same workstation	Opens documents, reads properties, rebuilds, exports, saves

The model itself runs in Anthropic’s cloud, so the prompt and whatever your tools return (property values, file names, BOM rows) are sent to the model. Your SOLIDWORKS files are not uploaded unless a tool reads their content and returns it. Design your tools with that in mind: return the data the task needs, not entire documents.

How to connect Claude to SOLIDWORKS: configuring Claude Desktop

Claude Desktop reads its MCP servers from a JSON file. On a standard Windows installation it lives at %APPDATA%\Claude\claude_desktop_config.json (the Microsoft Store version keeps it under its package folder in %LOCALAPPDATA%\Packages). Each server is an entry under mcpServers with a command to launch and optional args:

{
  "mcpServers": {
    "solidworks": {
      "command": "C:\\Tools\\SwMcp\\SwMcp.exe",
      "args": []
    }
  }
}

If your server is a Python script, the command is the interpreter and the script path goes in args:

{
  "mcpServers": {
    "solidworks": {
      "command": "C:\\Python312\\python.exe",
      "args": ["C:\\Tools\\sw_mcp\\server.py"]
    }
  }
}

A few practical points we see trip people up:

1. Close Claude Desktop completely (including the system tray icon) before editing, then start it again. The file is read at startup.
2. Back up the file first. If you already have other servers configured, add your entry inside the existing mcpServers object, separated by a comma.
3. Use doubled backslashes in paths. It is JSON, so a single backslash breaks the file.
4. Check for a hidden .txt extension if you created the file in Notepad.

Once Claude restarts, ask it something like “What tools does the solidworks server provide?” If the server started, Claude will list them.

Other AI clients, ChatGPT included, have been adding MCP support, but how they connect (local process vs remote server) differs by product and plan. The server side stays the same; only the client registration changes.

Building a minimal SOLIDWORKS MCP server

You do not need a framework to understand this, but the official MCP SDKs save a lot of protocol plumbing. Both the C# and Python SDKs let you declare a tool as an annotated method. Here is a minimal C# server with one read-only tool that returns the custom properties of the active document. It uses the ModelContextProtocol NuGet package with the .NET generic host, plus the SOLIDWORKS interop assemblies.

using System;
using System.ComponentModel;
using System.Text;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using ModelContextProtocol.Server;
using SolidWorks.Interop.sldworks;

var builder = Host.CreateApplicationBuilder(args);
// Route host logging to stderr: stdout is reserved for MCP messages
builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace);
builder.Services.AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();
await builder.Build().RunAsync();

[McpServerToolType]
public static class SolidWorksTools
{
    static ISldWorks GetApp() =>
        (ISldWorks)Activator.CreateInstance(Type.GetTypeFromProgID("SldWorks.Application"));

    [McpServerTool, Description("Returns the title and file-level custom properties of the active SOLIDWORKS document.")]
    public static string GetActiveDocumentProperties()
    {
        var model = (IModelDoc2)GetApp().ActiveDoc;
        if (model == null) return "No document is open in SOLIDWORKS.";

        var mgr = model.Extension.CustomPropertyManager[""];
        var names = (object[])mgr.GetNames();
        var sb = new StringBuilder().AppendLine(model.GetTitle());
        if (names == null) return sb.Append("(no custom properties)").ToString();

        foreach (string name in names)
        {
            mgr.Get6(name, false, out string raw, out string resolved,
                     out bool wasResolved, out bool linked);
            sb.AppendLine($"{name} = {resolved}");
        }
        return sb.ToString();
    }
}

Things worth knowing before you grow this into something real:

• The description is the prompt. Claude picks tools based on their names and descriptions. Write them like documentation for a careful junior engineer: what it does, what it returns, when not to use it.
• Keep stdout clean. With the stdio transport, stdout carries protocol messages. Send logging to stderr or a file, never Console.WriteLine. The .NET host logs to stdout by default, which is why the sample redirects the console logger to stderr.
• Mind COM threading. SOLIDWORKS is a single-threaded COM server. Serialize your calls, release objects you do not need, and expect long operations to block. Our article on memory access violations and unreleased COM objects applies here as much as it does to add-ins.
• Return compact, structured text. A BOM as a short table is far more useful to the model than a dump of every property on every component.

In Python the shape is the same: a FastMCP server, a decorated function per tool, and win32com.client to reach SldWorks.Application. C# gives you typed interop and cleaner handling of the API’s out parameters, which is why we tend to prefer it for SOLIDWORKS work.

Which tools to start with

Start with read-only tools, then add write tools one at a time:

1. Get active document info (title, path, type, configuration names).
2. Get custom properties (file and configuration level).
3. List assembly components with their file paths and suppression state.
4. Export the active drawing to PDF to a specified folder.
5. Run a named, pre-approved macro from a fixed folder.

That last one is a useful pattern. Rather than letting the model write and execute arbitrary code, you keep a library of reviewed macros and expose “run macro X” as a tool. If you are new to macros, see how to use VBA macros for SOLIDWORKS automation.

What works well today

In our experience, the reliable wins are the tasks where the API is deterministic and the model’s job is mostly interpretation and orchestration:

• Reading data: “What are the Description and Material properties on every part in this assembly that has no part number?” The model calls a listing tool, then a property tool, and summarizes.
• BOM questions: quantities, missing properties, duplicate part numbers, components from a given supplier folder.
• Batch exports: PDF, DXF or STEP for a list of files, with naming rules described in plain language.
• Generating macros: Claude writes good first drafts of VBA and C# against the SOLIDWORKS API, especially when it can query real property names and configuration names through your tools first. You still review and test them. For a community thread on using GPT models in this kind of work, see Anyone else using chat jippety! (GPT4) on CADOverflow.

Limits and safety

Be realistic about the following:

• Geometry creation is unreliable. Asking an LLM to model a part feature by feature through API calls produces fragile results: wrong sketch planes, under-defined sketches, selection by coordinates that miss. It can work for trivial shapes; it is not a modeling assistant.
• Human review is mandatory. Treat every write operation as a proposal. Configure your client to ask before running tools that save, overwrite or delete.
• One SOLIDWORKS session. The server talks to the running SOLIDWORKS instance on that workstation. Opening documents in the background, rebuilding or exporting will compete with whatever the user is doing interactively.
• Licensing. Automating SOLIDWORKS requires a licensed seat on that machine, and using a seat as a shared, unattended server raises license-terms questions you should check with your reseller.
• Data exposure. Whatever a tool returns goes to the model. Avoid tools that return entire files or sensitive customer data the task does not need.

Our rule of thumb: ship read-only tools first, add write tools that act on one file at a time, and only then consider batch writes behind an explicit confirmation.

What about SOLIDWORKS PDM?

Everything above is about SOLIDWORKS itself. If your files live in SOLIDWORKS PDM, the questions change: vault login, check-out state, workflow states, permissions and variables. For that we built an MCP server into PDMShell. It is installed and updated together with PDMShell, registers itself in Claude Desktop as pdmshell, uses your existing PDMShell machine license, and lets Claude look up command syntax, build searches and run PDMShell commands in your logged-in vault session. We walk through it in using Claude with SOLIDWORKS PDM through the PDMShell MCP server, and the setup details are in the PDMShell docs.

FAQ

Can Claude control SOLIDWORKS without an MCP server?

No. Claude can write macros and explain the API, but acting on a live SOLIDWORKS session requires a local program that calls the COM API. MCP is the standard way to give Claude that program as a set of tools.

Does a SOLIDWORKS MCP server send my CAD files to the cloud?

Only what your tools return is sent to the model. A tool that returns property values sends property values. Design tools to return the minimum data the task needs.

Can I use ChatGPT with SOLIDWORKS the same way?

The server side is the same MCP server. For PDM vault work, PDMShell connects to OpenAI through Codex rather than ChatGPT on the web: Use PDMShell with Codex. For other servers, check OpenAI’s current documentation for how your plan connects to a local MCP server.

Should I let Claude create geometry?

We do not recommend it for production work. Use it for data, exports and macro drafting, where results are easy to verify.

Need help with this?

We build SOLIDWORKS and SOLIDWORKS PDM API tools for a living, including MCP servers tailored to a company’s own workflows. If you want help designing safe tools for your team, contact us. For PDM, start with PDMShell and its built-in Claude integration.