Guides

Local bridge architecture

What runs on your machine, what a device activation actually grants, and why the answer is the only thing that ever crosses the network.

Guide · Desktop connector architecture

The SolidWorks and Inventor connectors both run as a local bridge: a small program installed on the same Windows machine as the CAD application, alongside it, not instead of it. It's worth understanding what that actually means, and what it rules out, before pointing an AI assistant at production drawings.

Three things, one machine

Three pieces are involved, and only one of them isn't local to your workstation:

The CAD application — SolidWorks or Inventor — running normally, with a part, assembly, or drawing open, exactly as it would be without any connector installed.

The local bridge — installed on that same machine, running alongside the CAD application, using the application's own supported extensibility surface to read and drive the document that's already open. It never reaches for a file on disk that isn't already open in the application; it acts on the live session.

Your AI client — Claude, ChatGPT, or any other MCP-capable client — connected to your ForgeMCP workspace the same way it connects to every other server on your plan. When it calls a CAD tool, that call reaches the local bridge on your machine; the bridge does the work locally and returns only the result.

What actually crosses the network

Not your model. A tool call like "what's the mass of this part" or "set this dimension to 40mm and rebuild" travels to your machine as a small instruction, and what comes back is the specific answer — a number, a list, a boolean, a path to a file the bridge just wrote — not the underlying geometry. Raw CAD data has no reason to leave the workstation it's already on, so the design doesn't move it. This is also, incidentally, why the connector is fast for read operations and honest about slow ones: reading a mass property is instant because it never waits on a network transfer of anything but the answer itself.

Device activation: what it grants, and what it doesn't

The first tool call from a freshly installed bridge shows a device activation code instead of doing anything. Approving that code at your workspace's activation page links that one machine to your account — not a blanket credential, not something that grants access from anywhere else. Every subsequent call from that machine is attributed to it and billed against your plan's device allowance, and an admin can revoke a specific device's activation without touching any other machine's.

This matters for a shared workstation or a contractor's laptop the same way any per-device credential matters: the blast radius of a compromised or lost machine is that one activation, not the whole workspace.

The honest limits

A local bridge can only act on a document that's genuinely open in a running CAD session — there's no cached model for it to answer from if the application is closed, and no way for it to reach a file that hasn't been opened. It also means the connector inherits whatever the CAD application's own extensibility surface actually exposes: capabilities that surface doesn't cover aren't available through the bridge either, which is why both the SolidWorks and Inventor pages are specific about which operations are supported today rather than claiming full parity with the desktop UI.

Related