I’ve built two plugins so far with Claude — Woolly Rhino and Selectinator — and both are in the Package Manager for Rhino 8 and the Rhino 9 beta.
Woolly Rhino output: fur grown on a handbag model
I don’t write or read code. What I do have is a very clear idea of how Rhino ought to behave, and it turns out that’s the part that’s hard to automate. So this post isn’t about learning to code. It’s about the workflow that makes an AI assistant actually productive on a Rhino plug-in, and the handful of things that will waste your time if nobody warns you.
At the bottom there’s a zip with some files you drop into your project folder. They tell Claude how all of this works, so you don’t have to explain it every time.
The one thing that shapes everything
A compiled Rhino plug-in can’t be reloaded while Rhino is running. Once Rhino has loaded your plug-in, the only way to test a change is to close Rhino and reopen it. There’s no workaround, and every AI assistant will try to invent one.
That single fact drives the whole workflow. It means your bottleneck isn’t writing code — Claude will produce more of that than you can use. Your bottleneck is checking it: getting each new build into Rhino and deciding whether it actually does the right thing. Everything below is about making that process easier.
The good news is that it’s mostly a solved problem. Compiling doesn’t need Rhino closed — only the one-second file copy does. So the loop is: build while Rhino is still open, then close it, Claude copies over the new code, reopen. Twenty seconds, not two minutes. The zip includes a script that does all of that in one command — a PowerShell one for Windows and a bash one for macOS, since the folder layouts are completely different between them.
What you need, and what it costs
Four things, plus Rhino 8 or later — the MCP doesn’t exist for Rhino 7. One of the four costs money; the other three are free downloads. It all works on Windows and on Apple Silicon Macs.
Claude — monthly cost for the Pro plan
claude.com/download for the app, claude.com/pricing for the plans.
The desktop app itself is free and works on every plan, including the free one. What you’re mainly paying for is how much you can do per day. On a free account you’ll run out partway through your first real session, so a Pro plan with a monthly fee is recommended to get a lot of work done in a short timeframe.
Two things worth knowing before you sign up:
- Usage resets on a rolling five-hour window, and there’s also a weekly cap. Nobody publishes exact numbers, and they change.
- This kind of work burns through usage faster than chatting does, mostly because every picture of your Rhino viewport is expensive to send. It’s easy to get through a day’s allowance in an afternoon without meaning to. The fixes are simple once you know them, and I’ll come back to them below.
Rhino MCP Platform — free
In Rhino: run PackageManager, search Rhino-MCP-Platform, install, restart Rhino, then run MCPConnect. That dialog gives you a line of text to copy — paste it into Claude and it wires itself up. (There’s also an Install tab that writes the config directly, if you’d rather it didn’t go through the chat.) It’s a McNeel project, MIT licensed, no cost. Docs: mcneel.github.io/RhinoAI/docs/.
What “MCP” actually means. It stands for Model Context Protocol, which tells you nothing, so: on its own Claude can only read and write text — it can’t see your screen or touch your programs. An MCP is a small piece of software that sits between an AI assistant and some other application and hands the assistant a menu of specific things it’s allowed to do there. That’s all it is. The Rhino MCP’s menu includes items like “list the objects in this document”, “select these faces”, “run this command” and “show me the viewport”. Claude picks from the menu; Rhino does the work; nothing else on your machine is exposed.
The upshot is that Claude can do a lot of its own checking in Rhino — running commands, reading back what’s in the document — instead of you relaying everything by hand.
MCPConnect hands you the line to paste into Claude
This is the Apple Silicon part. The Rhino MCP Platform only ships an Apple Silicon build, so Intel Macs aren’t supported. M-series Macs are fine.
GitHub Desktop — free
desktop.github.com/download. Free and open source, Windows 10+ and macOS 12+. On a Mac, the download page asks whether you have an Apple or an Intel chip — pick correctly.
What it’s for. It keeps a snapshot of your project every time you tell it to. When an experiment goes badly, you can click a button and you’re back where you were an hour ago. That’s the whole reason it’s on this list: you don’t need to learn what “git” is, you need the undo button. It’s what makes letting an AI loose in your project folder feel reasonable rather than reckless. Get a free GitHub account alongside it so your work lives somewhere other than your laptop. This also makes it easy to move between machines and pick up a project you started elsewhere. Just tell Claude to pull the repo down from Git and start working where you left off.
.NET SDK 8 — free
dotnet.microsoft.com/download/dotnet/8.0. Free, from Microsoft. Roughly a 200 MB download.
And yes, it runs on a Mac. “Microsoft .NET” sounds like it couldn’t possibly, but it’s been cross-platform for years. On the download page, macOS users want the .pkg installer — Arm64 for Apple Silicon, x64 for Intel. It needs macOS 14 Sonoma or later, which is the tightest requirement in this whole list.
What it is: the compiler — the thing that turns the code Claude writes into a plug-in Rhino can load. That’s its entire job here. You’ll never open it, and you don’t need Visual Studio or anything else.
One confusing bit. You may read that Rhino 8.20 and later already install .NET 8 and wonder whether you can skip this. You can’t. Rhino installs the runtime, which runs finished plug-ins. The SDK is what builds them. Same family, different job.
The workflow
- Make a folder for the plug-in, and unzip the kit into it. In GitHub Desktop, File ▸ New repository, give it your plug-in’s name and pick where it lives — that creates the folder and starts tracking your changes in one move. Then put the contents of the attached zip in that folder. (On Windows, easiest is to double-click the zip, Ctrl+A, and drag — “Extract All” insists on making a subfolder you don’t want.)
- Point Claude at that folder and tell it what you want the plug-in to do. On the very first go it will create the project itself,
.csproj, from your description — there’s an official Rhino project template it can install and run. - It builds. Rhino can stay open for this.
- Close Rhino, let the script copy the new build in, reopen.
- Check that the new build actually loaded before you judge anything — you can ask Claude to check this for you.
- Test the plug-in yourself in Rhino, and give Claude screenshots to explain what needs changing next.
- When it’s genuinely working, publish it so other people can install it.
That first step matters more than it looks. Everything afterwards assumes one folder that holds the plug-in, the kit files and the change history together — Claude reads its instructions from there, the build script writes there, and GitHub Desktop is watching the whole thing so a bad afternoon is two clicks from undone. Put it somewhere you’ll find it again; mine all live in a Git_Repos folder.
the project folder once the kit files are in it
Step 2 is worth an example, because it’s the bit people assume needs to be technical and it doesn’t. Here’s the prompt I actually started Woolly Rhino with:
Let’s make a plugin for Rhino that creates hair as thin meshes on a selected object. I want the individual meshes to be joined together into a single disjoint mesh in Rhino to keep performance fast. I want this plugin to work on Windows and Mac and in Rhino 8 and Rhino 9 which is currently in WIP development.
Not a line of code in it. What it does have is the things only a Rhino user would know to say: thin meshes rather than curves, joined into a single disjoint mesh because thousands of separate objects would crawl, and the versions and platforms it has to work on. That’s the whole trick — you’re not describing an implementation, you’re describing the constraints a plug-in has to live inside. Claude can write the C#; it can’t know that a few thousand loose meshes will bring Rhino to its knees unless you tell it.
Claude waiting for Rhino to close, then deploying and relaunching
Step 4 has a catch the first time through. The script works by overwriting the copy of your plug-in that Rhino already has, which means on day one there’s nothing to overwrite and it’ll tell you so. Fix it once — drag the freshly built .rhp onto an open Rhino, which registers it — and every deploy after that just works. Claude can talk you through it; it’s in the zip.
Step 5 is the one that bites everybody. If the new build didn’t land, you’ll see the old behavior, assume the fix failed, and spend an hour fixing things that were never broken. Just ask: “check that the build I just deployed is the one Rhino has loaded.” Claude can query the running Rhino directly and tell you which file it took and when that file was built.
confirming Rhino loaded the build you just deployed
There’s a trap here worth knowing about, because it looks identical to a failed deploy. Most plug-ins only load when first used, not when Rhino starts — so a freshly launched Rhino genuinely hasn’t loaded yours yet. Run one of its commands, then check.
Step 6 is where you earn your keep. A command that reports success has only told you it didn’t crash — it hasn’t told you the geometry is right. So run it, look at it with your own eyes, and when something’s off, screenshot it and paste it into the chat. Crop to the bit that matters, take it from the angle that shows the problem, scribble on it if that helps. A picture beats a paragraph of description, and it’s usually faster to take than to write.
a screenshot pasted into the chat, and what Claude did with it
Claude can grab the viewport itself through the MCP, and now and then that’s genuinely useful — checking a result mid-task without interrupting you. But those images eat your usage allowance fast, and left alone it will take one after every change whether you needed it or not. The files in the zip already tell it not to, and to ask you instead, so you shouldn’t have to bring it up.
One habit that is worth building: ask for two or three related changes at once rather than one at a time. Every check costs a Rhino restart, and left to itself Claude will happily rebuild after every small edit.
Step 7, and what the words mean
Two bits of Rhino vocabulary you’ll need for this, because nothing explains them anywhere obvious:
The Package Manager is the command you already know — PackageManager in Rhino, the same window you used to install the MCP. It’s Rhino’s app store: a searchable list of plug-ins that installs and updates them for you, and it’s the same list for everybody. Getting your plug-in into it is what “publishing” means here. There’s no review process and no gatekeeper. You push it and it’s there.
A .yak file is the thing you push. It’s just a zip with a specific name and a small text file inside describing your plug-in — the name, version, author, description, keywords and icon that people see in the listing. “Yak” is also the name of the little command-line tool that builds it, so you’ll see the word used for both. Rhino ships with that tool already installed; nobody needs to download anything extra.
That’s the whole concept. A .yak file is your plug-in plus its shop label, and the Package Manager is the shop.
And you can do this yourself — nobody has to do it for you. McNeel’s guide walks through the whole thing from a PowerShell prompt: creating a Rhino plug-in package. Or just ask Claude once you’re happy with the plug-in; it’s a few commands and Claude knows them.
Two things to know before you push. A version you publish can’t be edited or overwritten, only pulled out of circulation afterwards, so it’s worth getting right. And there’s a free test server that gets wiped nightly — push there first, look at how your listing actually appears in the Package Manager, then push for real.
the finished plug-in in Rhino’s Package Manager
Things that cost me time
- Esc stops Claude mid-flight. Easily the most useful key on the keyboard here. The moment you can see it’s heading the wrong way — misread what you asked, off fixing something you didn’t mention, about to rebuild when you wanted it to wait — press Esc. It stops there, and you can redirect it. Same goes for when you hit Enter and immediately think of the thing you should have said: Esc, add it, carry on. Letting a wrong turn run to completion wastes both your time and your usage allowance, and there’s no prize for politely waiting it out.
- If Claude can’t see Rhino, run
MCPStartin Rhino. The connection usually starts itself when you launch Rhino, but not reliably — a Rhino that was already open, a second file, or an instance that didn’t come up properly will all leave Claude talking to nothing.MCPStartfixes it in a couple of seconds; just press Enter at the port prompt. It’s the first thing to try, before you go looking for a real problem. - Anything you drag with the mouse can’t be tested automatically by Claude through the MCP. The MCP lets Claude run commands and scripts, but it can’t hold down a mouse button and drag — so brush tools, dynamic dragging, anything with live feedback under the cursor is off-limits to it. Half of Woolly Rhino falls into this category. Those parts you test yourself, by hand, every time. What Claude can do is check the underlying calculation with a script, then hand the interactive part back to you.
- Never let a plug-in store its settings inside its own installed folder. Rhino cleans that folder out on startup and the files vanish.
- Watch what happens after a conversation compacts. I work in one long thread for a whole stretch of development and let it compact itself when it fills up, which mostly works fine. But what survives a compaction is a summary, and summaries lose things. If you notice it forgetting a decision you settled an hour ago, or getting vague about something that used to be specific, start a new conversation pointed at the same folder. You’re not starting from scratch when you do —
CLAUDE.mdand your actual code are the real record. That’s most of the reason for having them. - Tell Claude to save a memory. If you spend some time getting something right with Claude and think you’ll do it again on another project, ask Claude to save a skill memory to help itself later. This is precisely what I’ve done and shared here to help streamline the Rhino plug-in creation process.
Give it a licence
Worth doing before you publish, and it takes five minutes. Without a licence file, nobody legally has permission to use or redistribute your plug-in — which is more restrictive than most people intend, not less.
MIT is the usual choice for a free Rhino plug-in, and it’s what I’ve used for both of mine. It’s short, it’s widely understood, and it says: use this, change it, ship it in something commercial if you like, just keep the copyright notice — and don’t come after me if it breaks. That last part is the bit that matters to you as the author.
The other two you’ll see are Apache 2.0 (much like MIT, plus an explicit patent grant) and GPL-3.0 (copyleft — anything built on top of it also has to be open source, which is a real restriction on anyone wanting to use your work commercially). choosealicense.com explains the differences in plain English and gives you the exact text to copy.
Once you’ve picked one, the file needs to be in four places, and it’s the last one people forget:
LICENSEin your project folder, so GitHub shows it- inside the
.yakpackage, atmisc/LICENSE— if your Package Manager description says MIT and the file isn’t in the package, that’s a promise you haven’t kept - named at the end of your Package Manager description
- in the License Agreement field on Food4Rhino, if you have a listing there
Ask Claude to set all four up; it’s in the zip. And the obvious caveat — I’m not a lawyer, and if your plug-in is commercial, has several authors, or was written on your employer’s time, that’s worth more thought than a forum post can give it.
The zip
rhino-claude-kit.zip (33.7 KB)
Put the contents in your project folder and you’re done — there’s nothing to configure and nothing to rename. Claude reads your plug-in’s name, version, target framework and command names out of your .csproj itself, and the build script does the same, so it takes no arguments beyond which step you want. START-HERE.txt covers the one Windows unzipping quirk and what each file does.
Nothing in there is specific to my projects. Take what’s useful, ignore the rest, and let me know if you have questions… or just ask Claude 
You can search my name in the PackageManager to find plugins I’ve made with Claude. At the time of this post there are two but the possibilities keep expanding and I plan on making more! I hope you’ve found this information useful and I look forward to seeing the tools you create for Rhino.
-Brian J.