WF 06 MCP — Claude Inside Rhino

WF 06

MCP — Claude Inside Rhino

MCP · Claude Desktop · Rhino · Grasshopper

Week11

SurfaceWF04 Patch

DueThu Nov 19

AssignmentConnect Claude to Rhino, then run a slope analysis both ways — submit one viewport of the landform Claude built through MCP, your .gh shell with its .py file, and one isometric of the colored slope mesh.

Submit to Miro board

Claude Desktop

→

MCP

→

Rhino

→

Grasshopper

→

Slope Mesh

This week you connect Claude directly to Rhino and let it work inside your model. The analysis — coloring a terrain by slope — is the exercise. MCP is the skill.

MCP servers exist for Blender, QGIS, Figma, browsers, spreadsheets. Install one here and you know how to install one for whatever software you pick up next. You write no code today: Claude handles every command line and every script.

Part 1 Connect Claude to Rhino

01 What MCP Is Read first

Chat Claude works from your description of a model. It never sees the file. MCP — Model Context Protocol — is an open standard that changes that: a small adapter sits beside a program and publishes what that program can do as a list of tools Claude is allowed to call. With the Rhino one installed, Claude reads your document, queries objects, builds geometry, and captures the viewport to see what it made.

A standard, not a Claude feature. Learn the pattern once and it carries to every other program that has a server.
Everything runs on your machine. The server talks to Rhino locally; your model stays where it is.
You stay responsible for the output. Claude edits your real document — save before you start and check what changed.

The standard is young — published late 2024. Some servers are excellent, many are abandoned prototypes. Rhino's is one of the good ones.

02 Install the Bridge RH SETUP

Install Claude Desktop from claude.com/download and sign in. Open the Code tab, pick any folder, and ask:

Research the available Rhino MCP servers, install the best-maintained one for me, and tell me in plain language what you put on my computer.

That is the whole step. Claude searches, picks a server — most likely jingcheng-chen/rhinomcp — installs what it needs, writes the config, and restarts itself. Approve the steps it asks about.

One thing it hands back to you: the Rhino-side plug-in installs from inside Rhino. Claude will tell you when — Tools → Package Manager, search rhinomcp, Install, restart Rhino.

Read the plain-language answer before moving on, and ask follow-ups until it makes sense. Knowing what landed on your machine is the transferable half of this step.

03 Open the Port, Confirm the Link RH

⚠

Type mcpstart in Rhino's command line every session. That opens the bridge on port 1999. Restart Rhino and you type it again. Keep one MCP client connected at a time.

Then open a normal Claude Desktop chat and ask:

What's in my Rhino document?

A correct answer lists your layers and object counts. If Claude says it has no Rhino tools, restart Claude Desktop; if it says the connection failed, run mcpstart again.

Part 2 Route A — Claude Works in the Model

04 Build a Landform by Asking RH

Start a fresh Rhino file and save it. Then describe terrain the way you would to a studio-mate:

On a layer called Terrain, build me a 60 × 40 m landform: a ridge running northeast, a shallow valley draining to the southwest corner, and a flat terrace about 12 × 12 m near the low end. Surface it, then capture the perspective viewport and show me.

Look at what comes back and correct it in words — steeper ridge, move the terrace toward the valley. Claude re-captures the viewport each time, so it sees its own result and can fix it before you have to explain the problem.

Name things precisely. "the surface on my Terrain layer" beats "my surface." Specification is still the skill.
Ask to see the script. Claude runs Python inside Rhino to do this — ask for it and read what you are shipping.

05 Slope Analysis, In the Document RH

Open your WF04 terrain and ask for the analysis on the real surface:

Read the surface on my Terrain layer. Color it by slope — green under 5%, yellow 5–10%, red over 10% — bake it as a mesh on a new layer, then capture the perspective viewport and check the steep zones read correctly.

Under the hood it measures the angle between each surface normal and world Z. Flat is 0°, vertical is 90°. Your thresholds are design thresholds — walkable, wheelchair-accessible, water-shedding — so choose them and be able to say why.

Patch extends past your boundary. Tell Claude to exclude faces outside it. You don't need to know how — only that the problem exists.

Part 3 Route B — Grasshopper, and the Shim

06 The Python Component, by Hand GH PY

Route A gave you one answer. A Grasshopper definition gives you a dial. Start by doing it the plain way — ask Claude for the script and paste it in yourself:

Write a slope analysis for a Grasshopper Python 3 component: it takes a terrain mesh and two percent-grade thresholds, and outputs a mesh colored by band. List the input names at the top as comments, and tell me how to set the component up.

Drop a Python 3 Script component, add inputs with the names Claude listed, paste the code in, and wire your mesh and two sliders.
Switch input marshalling off on the geometry input (right-click the component). With it on, the mesh arrives as a GUID the script cannot resolve — and it fails quietly.
Errors — paste the full message back to Claude. Run, error, fix is the normal way this goes.

Drag the sliders. That is the whole idea of the component: a box holding source code, whose inputs are ordinary variables named by the sockets you drew.

07 Why Move the Code Out Read first

Your script now lives inside the .gh file. Every revision is another round of copy-paste — and Claude cannot reach it: writing into that component through MCP means rewriting and reopening the whole document, which drops your wires and any unsaved work on the canvas.

A shim, in computing, is a thin piece of code that sits between two parts that do not quite fit and passes the call across, adding no logic of its own. Programs are full of them — a shim is how old software keeps running on a new operating system.

Here the shim is three lines that stay in the component and load an external .py. The .gh becomes a shell — sliders, wires, panels, all yours. The code becomes a plain file Claude edits and you can read.

08 Install the Shim GH PY

your-project\
│
├─ analysis.gh     THE SHELL — you build it, you own it
│    ├─ sliders, wires, panels
│    ├─ TERRAIN  (Python 3) ─┐   each component holds
│    └─ SLOPE    (Python 3) ─┤   the same three lines
│                            │
├─ terrain.py  <─────────────┘   THE CODE — Claude edits these:
├─ slope.py    <─────────────    plain text you can read,
└─ README.md                     diff, and hand to someone

Make a folder for the project, open it in the Code tab, and show Claude the pattern:

Save the slope script as a file in this folder, then give me this shim with the real path filled in — I'll paste it into the component in place of the code.

import os
p = r"C:\Users\you\your-project\slope.py"
exec(compile(open(p).read(), p, "exec"))

Replace the pasted script with the three lines Claude hands back. Everything else on your canvas stays exactly as it is — same sockets, same wires, same sliders.

Now the loop is short: Claude edits the file, you nudge any slider, the new code runs. No copy-paste, no save, no reopen, no Grasshopper restart.

Watch for

Empty inputs → socket names must match what the script reads, and geometry inputs still need marshalling off.
Old results → nudge a slider; the component re-reads the file only when it recomputes.
Moved folder → the path is absolute. Tell Claude where it went and it rewrites the line.

Open the .py and read it before you nudge the slider. That is the whole argument for this arrangement: the code sits still, in a file with your name on it, where you can watch it change.

What You Actually Installed

Two questions sit behind this, and mixing them up is what makes MCP confusing. How does Claude know what Rhino can do? That is MCP — the protocol. How does a command actually reach Rhino? That is a plug-in. MCP hands Claude the list of tools; the plug-in does the reaching.

   Claude
     |  speaks MCP
   rhinomcp server    a program on your
     |                computer, started
     |                by Claude Desktop
     |  port 1999
   rhinomcp.rhp       a plug-in loaded
     |                INSIDE Rhino;
     |                mcpstart opens
     |                the port
   your model

.rhp is just a Rhino plug-in — the same kind of thing as Human or Bowerbird, sitting in the same folder beside them. Neither half works alone, which is why the connection dies the moment Rhino quits. Expect this shape in any MCP you install next: an adapter outside, and a way in.

Other Software, COM, and CAD

Servers exist for Blender, QGIS, AutoCAD, Figma and plenty more. Almost all are written by the community rather than by the software vendors, so quality varies sharply. To try one, ask in the Code tab exactly as you did in Stage 02 — "research the available QGIS MCP servers and install the best-maintained one" — then have Claude read the code and tell you what that server can do before you trust it. Expect some repair work.

A note on COM. Rhino's server gets in through a plug-in. Most servers for older programs — AutoCAD included — use COM instead: a Windows mechanism from the 1990s that lets one application drive another from outside, with nothing installed inside it. Easier to set up, and more fragile. Versions have to match, and every value crosses a boundary where it can be misread. That is usually what you end up repairing.

The Grasshopper gap in Stage 07 is the same kind of thing: a seam nobody has built across yet. You crossed it with three lines of glue. Noticing where the seams are — and what cheap glue would hold — is most of what it takes to work with tools this young.