RhinoMCP: Driving Rhino 8 and Grasshopper from an MCP Client
RhinoMCP connects Rhino 3D to AI Agent through the Model Context Protocol (MCP)
At a glance
- What is it?
- RhinoMCP is an MIT-licensed Python bridge that exposes Rhino 8 and Grasshopper to MCP-speaking assistants such as Claude Code, Codex and Cursor. The design is unusually broad (native commands, RhinoScript-Python, RhinoCommon C#, viewport capture, batched Grasshopper graphs), and that breadth is also where its risk sits.
- Who is it for?
- Adopt RhinoMCP if you are on Rhino 8, comfortable with uvx, and want an assistant to build geometry, inspect a document, or assemble a Grasshopper canvas from natural language, including cases where the assistant writes RhinoScript-Python or RhinoCommon C# on the fly.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap RhinoMCP fills between a chat window and a Rhino document
Most AI assistance for CAD stops at text. You describe a shape, the assistant writes a script, you copy it into Rhino, run it, read the error, and paste the error back. RhinoMCP removes the copy-and-paste loop by putting the assistant on the other side of a live connection to the running application. The README frames it plainly: it connects Rhino to AI agents through the Model Context Protocol so that assistants like Claude and Cursor can model geometry, read your document, and build Grasshopper definitions by chatting. The audience is therefore specific. It is for Rhino 8 users on Windows or macOS who already work with an MCP-capable client and who want the assistant to act on an open document rather than produce a snippet for a human to run. It is not a general CAD automation library, and it is not a way to script Rhino from a headless server. The README states that RhinoMCP targets Rhino 8, so anyone on Rhino 7 or earlier is outside the supported range.
Two halves: a Rhino plugin and a Python MCP server joined over a local host
The architecture has two processes. Inside Rhino there is a plugin, installed through the Package Manager, which is what actually touches the document and the Grasshopper canvas. Outside Rhino there is a Python package, published on PyPI as rhinomcp, which speaks MCP to your assistant and forwards requests to the plugin. The environment variable RHINO_MCP_HOST, set to 127.0.0.1 in the config examples, is the address the server uses to reach the plugin. That split explains the install steps: the plugin is installed in Rhino, the server is installed in your assistant's configuration, and the bridge is started from inside Rhino. The README's quick start lists exactly those three phases. It also warns in a callout that you should run only one RhinoMCP server at a time, which is a direct consequence of a single local endpoint: two servers competing for the same host and port is a configuration you are told to avoid, not a supported multi-client setup.
The tool surface is wide, and the escape hatches are the interesting part
The README's capability tables split into Rhino and Grasshopper. On the Rhino side the assistant can create primitives and curves (points, lines, polylines, circles, arcs, ellipses, boxes, spheres, cones, cylinders, surfaces), transform and edit objects, run loft, extrude, sweep, offset, pipe and the boolean operations, project and split curves, manage layers and object attributes, query the document, capture the viewport, and measure length, area, volume and bounding boxes. On the Grasshopper side it can search the installed component library, inspect a component's inputs and outputs before placing it, add and position components, connect and disconnect parameters, drive sliders, toggles, panels and value lists, read structured data back out of outputs, run the solution, and surface runtime warnings and errors. Two details deserve attention. First, viewport capture means the assistant can work from what is on screen, which closes the feedback loop for visual tasks. Second, and more consequential, the assistant can run any Rhino command, execute RhinoScript-Python, or run RhinoCommon C#, with built-in RhinoScript documentation lookup. That is a deliberate design choice to leave no ceiling on what can be automated. It is also the feature that should shape how you deploy this.
Getting it running: Package Manager, uvx, and one config entry
Installation is three steps as documented. In Rhino, open Tools, then Package Manager, search for rhinomcp, click Install, and restart Rhino. For the client, the README offers an agentic route: paste the prompt asking the assistant to install https://github.com/jingcheng-chen/rhinomcp as a local MCP server named rhino. For a manual route, Codex takes one command, codex mcp add rhino --env RHINO_MCP_HOST=127.0.0.1 -- uvx rhinomcp@latest, and Claude Code takes claude mcp add rhino -- uvx rhinomcp@latest. The equivalent JSON block is an mcpServers entry named rhino whose command is uvx, whose args are ["rhinomcp@latest"], and whose env sets RHINO_MCP_HOST to 127.0.0.1. The launcher uvx comes from uv, and the README gives install lines for both platforms: brew install uv on macOS, or the PowerShell installer one-liner on Windows. Two constraints are stated rather than implied. ChatGPT apps and MCP connectors connect to remote MCP servers, not local stdio commands like uvx rhinomcp, so the README points ChatGPT users at Codex for local setup or at developer mode with a remote or tunneled endpoint. And the callout about running only one RhinoMCP server at a time applies to every client you configure.
Where the design bites: code execution, version pinning, and a hostname that is not authentication
The most important limitation is not a bug, it is the feature set. Running arbitrary Rhino commands, RhinoScript-Python, and RhinoCommon C# means the assistant's output is executed inside your Rhino session with whatever access that session has. The README presents this as depth for when you need more control, and it is, but it also means the safety boundary is your document and your machine, not the tool schema. Treat the connection as you would treat handing someone your keyboard. A second limitation is version coupling. RhinoMCP targets Rhino 8 on Windows and macOS, and the tools depend on Rhino 8's plugin and Grasshopper APIs, so there is no documented path for older Rhino versions. Third, the config examples set RHINO_MCP_HOST to 127.0.0.1, which keeps the bridge on loopback; the README does not describe any authentication layer, so the host setting is a scope control rather than a credential. If you tunnel the endpoint to satisfy a remote client, you are extending that scope, and the material does not describe what protects it. Finally, the single-server warning is a real operational constraint: parallel sessions against one Rhino instance are not a documented mode.
How it differs from writing Grasshopper scripts or Rhino scripts by hand
The obvious alternative is not another MCP server, it is the workflow most Rhino users already have: write a Python or C# script, or build the Grasshopper definition manually, and iterate yourself. The difference in approach is where the iteration happens. In the script workflow, the human is the feedback channel: you run the code, read the error, and edit. In RhinoMCP, the assistant is the feedback channel, and the README supplies it with the senses it needs to close that loop, namely document inspection, object info, filtered selection by name, color or category with AND and OR logic, and viewport capture. That is a meaningful difference for exploratory work, where the cost is in the number of round trips rather than in any single operation. It is not a difference that helps when the task is already well specified. If you know the exact script you want, writing it directly is faster and keeps the code reviewable in your own repository. RhinoMCP earns its place when the shape of the answer is unclear and you want to iterate against the live model instead of against your imagination.
Maintenance, release cadence, and what the MIT licence does and does not settle
The repository shows a 0.4.x line with 0.4.0 on 2026-09-09 and 0.4.1 on 2026-09-10, following 0.3.2 in June 2026, so the project is active and the version numbers are still pre-1.0. That matters for upgrade cost because the documented client config uses uvx rhinomcp@latest, which resolves to whatever the newest release is at the moment your assistant starts. If you want reproducible behaviour across a team, pin the version in the args array instead of tracking latest, and expect to re-check the tool surface when you bump it. The Rhino plugin is installed through the Package Manager and the README says to restart Rhino after installing, so plugin updates follow Rhino's own package flow rather than the Python client's. The licence is MIT, which in plain terms permits use, modification and redistribution with the licence text retained, but this is not legal advice and you should read the LICENSE file and your organisation's policy if you plan to redistribute or embed it. The README also links a continuation guide for autonomous improvement experiments under experiments/CONTINUE.md, which suggests active experimentation beyond the documented tool surface; treat that directory as work in progress rather than as a supported interface.
Editorial conclusion
Adopt RhinoMCP if you are on Rhino 8, comfortable with uvx, and want an assistant to build geometry, inspect a document, or assemble a Grasshopper canvas from natural language, including cases where the assistant writes RhinoScript-Python or RhinoCommon C# on the fly. Do not adopt it if you are pinned to Rhino 7 or earlier, if you need a hosted or remote MCP endpoint rather than a local stdio process, or if unaudited AI-authored code execution inside a production Rhino document is unacceptable. Verify first: the exact Rhino 8 build and OS you run, that uvx resolves rhinomcp@latest, that only one RhinoMCP server is running at a time, and whether the assistant's session is pointed at a scratch document rather than a live model.
Community notes