MCP — the Model Context Protocol — is an open standard that lets an AI agent call tools inside other software. Instead of the agent writing a script and hoping it runs, the software publishes a list of operations it supports, and the agent calls them by name with typed arguments.
Before MCP, connecting an AI model to a piece of software meant writing a bespoke integration for that one pair — this model, that application. Every combination was its own project, and none of the work transferred.
MCP splits that into two halves that do not need to know about each other. An application exposes its capabilities once, as an MCP server. Any MCP-capable client can then use it. Write one server for your software and every compatible agent can drive it; build one client and it can drive everything that speaks the protocol.
Three parts, and it is worth being precise about which is which, because almost every setup problem is really a confusion between them.
That last point is the substantive one. A tool call is checked against a schema before it runs, so a malformed request fails cleanly instead of executing something unintended. This is why MCP-based integrations behave more predictably than asking a model to emit a script.
CAD applications already expose rich scripting APIs — Ruby in SketchUp, RhinoCommon in Rhino, Python in Blender. Those APIs are what an MCP server wraps. The server publishes operations such as "create a group", "set a layer", "array these objects along a curve", and the agent composes them.
The consequence is that an agent can work inside a model you already have open rather than generating a file from scratch. It reads what is there, makes a change, and the change is a normal edit — undoable, and respectful of the tags, components and layers you already set up. That is a different proposition from text-to-3D generation, which produces a new object with no knowledge of your project.
It is not magic. The agent can still choose the wrong operation, and geometry that is 80% right often costs more to fix than to model by hand. What the protocol buys is reliability in the plumbing, not judgement in the design.
No, though it sits next to both. An API is what the application already offers to programmers. A plugin is code you install into the application. An MCP server typically uses the API, often ships as a plugin, and adds the one thing neither provides: a standard way for an AI agent to discover what operations exist and call them safely.
Only if you are wiring it up yourself. On the open-source routes you will meet all three parts, because you install the server, register it with your client, and check the plugin loaded — which is why the terminology is worth having. If the application sets itself up, the protocol is an implementation detail you never see.
The SketchUp and Rhino pages cover every route — including the open-source ones, written out in full.
SketchUp MCP →