Say five AI clients — Claude, ChatGPT, Gemini, Perplexity, Grok — each want to talk to five CAD vendors — SolidWorks, Inventor, Onshape, Fusion, AutoCAD. Built as direct, bespoke integrations, that's 25 separate integrations: 25 auth flows to implement, 25 tool schemas to design, 25 things to keep working when either side ships a breaking change. Built against a shared protocol instead, it's 10: each AI client implements the protocol once, each CAD vendor gets a server built against it once, and any client can reach any server without either side knowing about the other in advance.
What a direct integration actually costs
A direct integration between one AI client and one CAD vendor isn't just an API call. It's an auth flow shaped to that vendor's own identity system, a set of functions or tools shaped to that client's own extension format, error handling for that vendor's specific failure modes, and a maintenance commitment for as long as both sides exist. None of that work transfers to the next vendor, or the next client — a team that builds a direct SolidWorks integration for one AI client has built nothing reusable for Inventor, and nothing reusable for a second AI client wanting the same SolidWorks access.
What a shared protocol standardizes
Model Context Protocol (MCP) defines one contract for the part of this that doesn't need to be vendor-specific: how a client discovers what tools a server offers, what each tool's inputs and outputs look like, how a tool call is made, and how a result comes back. A server that speaks MCP — list its tools, describe their schemas, respond to a call — is reachable by any client that also speaks MCP, without the server author writing anything client-specific and without the client author writing anything vendor-specific.
The client keeps its own job: rendering available tools to the user, handling consent before a tool runs, and deciding when to call one. The server keeps its own job: doing whatever it does — reading a CAD model, computing a tolerance, exporting a file — and reporting the result in the shape the protocol expects. Neither side has to understand the other's internals.
What this changes when a vendor's API moves
CAD vendor APIs change — SDK versions deprecate methods, cloud platforms rotate auth schemes, product teams rename things. In a direct-integration world, every AI client with that integration inherits the break on the vendor's own schedule. Behind an MCP server, the same change is absorbed once, on the server side, and the contract facing every AI client — the tool names, the schemas, the behavior — doesn't move. The AI clients that were already connected stay connected without doing anything.
Where ForgeMCP sits in this
ForgeMCP is the server side of that equation, built once per CAD platform and reachable from every MCP-capable AI client through the same connection — one workspace URL, added once in Claude, ChatGPT, or any other MCP client that supports custom connectors. Adding a new AI client to an existing ForgeMCP workspace is a client-side setting, not a new integration; adding a new CAD platform to ForgeMCP is one server, reachable by every client already connected.