I Had Claude + RhinoMCP Write the Grasshopper — and It Understood Data Trees (Part 2)

Decomposing a concept into PoC stages, and the moment an AI handled graft / flatten correctly.

In Part 1, the concept and render for “Kanjun no Niwa” (環巡の庭) were locked inside ChatGPT. From here on it is the world of Grasshopper — numeric models and programs. The tool for that was Claude + RhinoMCP.

What I handed over — render + concept text + diagram

The first thing I gave Claude:

• The one confirmed final-goal render from ChatGPT
• The concept statement (one paragraph, the design intent)
• The three components (triple ring / entrance offset / wave-form height)
• A diagram decomposing each component

The diagram was what really worked. Handing over one diagram conveyed the idea far faster than writing “vary the height with a sin wave” in words. Claude actually compared the Rhino viewport against the diagram and render and tuned the visual toward them.

What I felt here: an AI relay is decided by the preparation on the handing-over side. If you don’t verbalize the components and intent in ChatGPT, a redo happens the moment you pass it to Claude.

PoC hierarchy — why I split it into 5 stages

Throwing the whole concept straight into Grasshopper was dangerous: 3 components, each with several variables, plus environmental scoring — more than 20 moving elements at once. So I used a PoC hierarchy:

• PoC0 — outer ring only → does a ring form?
• PoC1 — expand to 3 rings → do multiple rings line up?
• PoC2 — entrance offset + height modulation → is the concept visible?
• PoC3 — extract environmental numbers → does the analysis run?
• PoC4 — optimization in Wallacei → does a Pareto front come out?

Confirm it runs at each stage before moving on. This matters more precisely because an AI is writing it — an AI can write a large amount of code at once, which means a large amount of code that doesn’t run. Slicing the hierarchy lets you check the output in verifiable units.

From 1 ring to 3 — understanding the tree structure

PoC0 ran with the outer ring. For PoC1 (all three rings) Claude came back with an unexpected question:

If we expand the current code to 3 rings as-is, the code volume triples and maintenance breaks down. Copy-paste the same process, or cluster it once and call it 3 times?

Seeing that surprised me — it is actually thinking about maintainability at scale. But both options were a 50/100 for me.

Can you use a tree structure and process all 3 rings in one go?

Grasshopper’s Data Tree nests lists inside lists; it only behaves once you use graft and flatten correctly — exactly where people who can write GH and people who can’t visibly split. I sent the instruction half-doubting.

Pass the radii and counts as lists, graft into 3 branches, process in parallel, flatten back where needed — it followed Data Tree conventions. Not merely code that runs, but code that understood Grasshopper’s data structure. My prior expectation was that an AI would stumble here; Claude + RhinoMCP defied it. From here, the code stayed compact, and stepping up PoC1 → PoC3 caused almost no large rewrites.

Another surprise — the AI handled plugins too

Daylight performance was evaluated with Ladybug Tools — close to mandatory for environmental design in Grasshopper. The setup:

• Read Tokyo EPW weather data and build the sun path
• Place an evaluation mesh on the floor; compute annual radiation [kWh/m²/year]
• Define F1 as the area ratio exceeding a 500 kWh/m²/year threshold

Claude + RhinoMCP handled this Ladybug set normally — not just built-in components, third-party plugins too, wiring and inputs correct. That greatly widens the scope of writing GH with an AI: environmental analysis, optimization, structural analysis come into range. Two plugins worked (Ladybug, Wallacei); the outlook is others follow the same conventions.

Sorting out the variables and the performance axes

Variables (Gen): each ring’s radius R1/R2/R3; each ring’s louver count N1/N2/N3; wave amplitude and period; louver density distribution.

Fitness: F1 solar shading (floor area ratio with annual radiation ≥ 500 kWh/m²; smaller = stronger); F2 wave rhythm (more variation = better); F3 sightline / wind openness (wider spacing = better).

What mattered here was cleanly separating the Gen / Fitness correspondence — the precondition for handing it to Wallacei.

Next time — choosing from a Pareto front of 10

At PoC4, handing the variables and Fitness to Wallacei ran an optimization of Pop 50 × Gen 30 = 1,500 individuals. From there I compared a Pareto front of 10 and finally adopted one. Part 3 writes that choosing process — where numbers alone don’t decide. To be continued.

📚 Read more in this series

🇬🇧 I Built 100 Rhino Models Almost on Autopilot — with RhinoMCP × Claude Code (Medium) 🇬🇧 I Wrote 100 Grasshopper Programs with RhinoMCP × Claude Code (Medium) 🇬🇧 Part 1 — I Let AI Design a Pavilion (Medium) 🇯🇵 Japanese original (note)

Want the whole workflow in one place?

I put the full setup, the Claude Code prompting patterns, and the environmental-analysis walkthroughs into a practical guide — plus the 5 ready-to-run Grasshopper definition files Claude generated.

→ Get the guide + 5 GH files (Gumroad)

Studio.Allelishi is a research studio at the intersection of architecture, parametric design, environmental analysis, and AI.

Follow on X: @allelishi · Web: studio.allelishi.com