Rhino MCP: what to set up before you let an assistant touch your model

McNeel's troubleshooting page for the Rhino MCP Platform carries an entry headed "The assistant says it did something, but I don't see it." The advice underneath is ordinary housekeeping — check you are looking at the right Rhino window, run Zoom Extents, look on the hidden layers. But the heading is the most honest line published about this technology, because it names precisely what changes. Once an assistant is wired into Rhino, its account of its own work is a claim. Your model is the record.

That gap is small when the job is renaming layers and large when the job is a boolean on a wall you are about to issue. Everything below is about closing it before you need to.

What you are actually installing

Two pieces, on your machine, talking to each other.

The first is a Rhino plugin. For McNeel's own version it is called Rhino-MCP-Platform, installed through Rhino's Package Manager, and it adds an MCPStart command that opens a local connection. The second is a connector on the assistant's side — for Claude Desktop, a file called connector.mcpb you install as an extension; for Claude Code, Copilot, Codex, Gemini CLI or a local model, a few lines in a config file pointing at the same local router.

The thing that joins them is the Model Context Protocol — MCP, a published standard for letting an AI assistant call functions in software running on your computer. Anthropic released it in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025, which is why the same plugin works with assistants from four different companies. Each function the assistant can call is a tool call: a named, single action like create a layer, run a Rhino command, execute a Python script, save the document. The assistant chooses which ones to fire and in what order.

McNeel's platform is free, MIT-licensed, and public on GitHub. As of early September 2026 the Claude connector is at version 0.1.3. That number is not a criticism, but it is information: this is a young piece of software attached to the file you bill against.

There are also at least half a dozen unaffiliated projects called some version of "Rhino MCP," several of them predating McNeel's. They are not interchangeable, and a few carry real differences in how they connect. One widely used third-party server documents its own bridge as an unauthenticated loopback link and warns not to expose it beyond the local interface. Before you install anything, know whose repository it came from.

Why this is not a chatbot with a Rhino skin

The tools most practices have tried so far produce an artifact you then evaluate — an image, a paragraph, a block of code. You are the gate. Nothing reaches the project until you move it there.

An MCP connection removes the gate. The assistant is not describing a modeling operation for you to perform; it is performing it, in the open document, while you watch or while you read the next message. Between "make me twenty variations of that facade module" and twenty objects existing in your file, there is no step where you decide.

That is the point of the thing, and it is genuinely useful. It is also the reason four ordinary questions of practice arrive at once: which file it is allowed to open, what happens to work you cannot show a third party, how a change gets checked, and who says the model is right before it goes out. None of those are answered by the installer.

The consultant with edit access

Here is the shift in terms the office already understands. Until now, an AI tool has behaved like a consultant sending you markups: they propose, you implement, and the act of implementing is the act of checking. An MCP connection is closer to giving that consultant write access to the model itself. The work arrives finished, and your review is now a separate task you have to remember to do.

The analogy breaks in one place, and the break is the useful part. A consultant with edit access knows what they changed and can tell you next Tuesday. The assistant's memory of the session is a transcript of what it intended to do, produced by the same process that did it — which is exactly why McNeel had to write that troubleshooting entry. Ask it what it changed and you get a well-organized account, not an audit.

Under the hood this is less mysterious than it sounds, and worth knowing at one level of detail. A good deal of what the assistant does is write and run RhinoScript, Python or C# inside your Rhino process, then read back what happened. That is why the results can be so quick on repetitive work — renaming three hundred layers in a consultant's file, exporting a folder of views, placing a grid of options — and so unreliable on anything requiring it to see the geometry as a designer sees it. It is scripting at conversational speed, with the script written from a description.

Set the boundary before the first prompt

Six things to fix before you connect this to anything that matters.

Work on a copy, always. Not the issue model, not the file the team has open. A copy, or a scratch file made for the session. This one habit makes the other five less urgent.

Save before every write, and treat the save as your undo. Undo behavior across MCP tool calls varies by implementation and by version; some group changes into undo records, some do not, and a script that runs inside Rhino may not leave a single clean step to walk back. A saved file walks back reliably.

Know which tools execute code, and don't blanket-approve them. McNeel's own privacy document is admirably direct about this: the connector exposes run_command, run_python and run_csharp, which execute arbitrary code in the Rhino process, plus open_doc and save_doc, which can reach any file your user account can reach. Most MCP clients ask permission the first time a given tool is called and offer to remember the answer. Find that setting before you need it, and keep the code and file tools on ask.

Decide the confidentiality question in writing. Everything the connector returns to the assistant — geometry, command output, viewport screenshots — leaves your machine through your AI client and is governed by that client vendor's privacy policy, not McNeel's. McNeel states plainly that its connector collects nothing and sends nothing on its own. That does not settle whether a competition scheme under NDA should be screenshotted into a cloud assistant. Somebody in the practice has to answer that before a project architect answers it by default at eleven at night.

Match the versions. The router targets Rhino 8 unless you tell it otherwise. Grasshopper 2 tools require Rhino 9, which McNeel's documentation still labels WIP/BETA. Intel Macs are not supported, and neither is the .NET Framework build.

Name the reviewer. If model geometry produced this way goes into a drawing that is issued, the practice's existing checking procedure applies unchanged. Write down which person signs, and when. The interesting failure is not the assistant deleting something dramatic — that gets noticed. It is a plausible edit landing in a file nobody re-checks, because the assistant said it was done.

Where it breaks

The reporting gap is the honest headline, and McNeel documents three of its everyday forms: geometry created far from the origin, geometry on a hidden layer, and edits made in a different Rhino window than the one you are looking at. All three produce a confident "done" and a viewport that hasn't changed.

Rhino can crash mid-session; the connector notices and offers to relaunch, which is decent handling of a thing that should be rare and currently isn't. Grasshopper support divides awkwardly across GH1 and GH2. And the underlying weakness is spatial: the assistant is reasoning about your model through descriptions, screenshots and script output, not by looking at it the way you do. It follows instructions about geometry far better than it judges geometry.

There is a mismatch worth noting between the project's front door and its documentation. The landing page talks about creativity becoming a partnership. The privacy file says to treat the connector with the same caution as any tool that runs scripts on your machine. The second sentence is the one to bring to a partners' meeting.

Worth an hour, on a Saturday

Take the messiest consultant file you have — the one with two hundred layers named after somebody's export settings. Copy it. Connect the assistant, and give it one narrow job: rename and reorganize the layers to your office standard. Nothing else.

Then do the part that matters. Compare the result against the original yourself, layer by layer, and count what it got wrong. That number is your calibration, and it is worth more than any demonstration you will be shown this year. The entry in McNeel's troubleshooting page is not a bug report; it is a job description. The assistant says it did something. Looking is now part of your week.