Try double clicking the file instead of clicking “preview”
I have been using the MCP a lot, its awesome, but have ben having problems with agents working in Layouts, and so I asked Codex to describe the issue:
Potential destructive bug/footgun in Rhino MCP / rhinoscriptsyntax ObjectLayout getter
Environment:
- Rhino with Rhino MCP enabled
- Code executed through MCP execute_rhinoscript_python_code
- Python script using
import rhinoscriptsyntax as rs
Issue:
Calling rs.ObjectLayout(obj) as a read-only getter on layout-space objects appears to move those objects into model space.
Expected:
rs.ObjectLayout(obj) should return the page layout name/id for the object, without modifying the document.
Observed:
After running a script that only inspected objects and called rs.ObjectLayout(obj) while iterating over sheet/title-block objects, the objects disappeared from the layout sheet and appeared in model space. The Rhino document became modified, and a later repeat caused Rhino instability/crash.
Likely cause:
The RhinoScript signature is ambiguous:
ObjectLayout(object_id, layout=None, return_name=True)
The docs say:
- if layout is not specified, return the current layout
- to move an object from layout space to model space, specify
None
In Python, omitted optional argument and explicit None are hard to distinguish unless the implementation uses a sentinel. In this MCP/RhinoScript execution path, the getter call seems to be treated as the setter call.
Impact:
This is highly destructive for sheet workflows, because drawing sheets/title blocks are often in layout space. A read-only inspection script can empty a layout.
Suggested fix:
Provide a safe read-only getter, e.g. GetObjectLayout(object_id), or change ObjectLayout to use a non-None sentinel internally so omitted layout cannot be interpreted as “move to model.” At minimum, MCP/RhinoScript docs should warn that ObjectLayout(obj) may be unsafe and give a non-mutating RhinoCommon alternative.
I’d agree that’s a bug, good find!
RH-96724 rs.ObjectLayout(obj) moves objects
Hi @CallumSykes, a reproducible bug with the Rhino MCP Platform — run_python and run_csharp never execute on my machine, while run_command works perfectly. I’ve narrowed down the root cause below.
Environment
- Rhino 8.32.26160.13001, Windows, UI language: French
- .NET runtime: .NET Core 8 (coreclr 8.0.14)
- Rhino MCP Platform installed via PackageManager/Yak (router + slots working)
RhinoCodePlugin.rhpandRhinoScriptEditor.rhpboth present inProgram Files\Rhino 8\Plug-ins
Symptom
run_command→ works (e.g._Box,_SelAll,_Zoomall fine)run_pythonandrun_csharp→ always return, without running any code:
{"stdout":"Commande inconnue: -ScriptEditor\n","error":null}
(“Commande inconnue” = French for “Unknown command”)
Repro
- Connect the MCP to a running Rhino 8.32 (French UI), any document.
- Call
run_pythonwith e.g.print("hello")→ returns stdoutCommande inconnue: -ScriptEditor, nothing executes. run_commandwith e.g._Line 0,0,0 1,0,0works fine in the same session.
Root cause (confirmed on my machine)
On my French Rhino UI:
-ScriptEditor(no underscore, what the server seems to send) → “Commande inconnue” (unknown command)_-ScriptEditor(with underscore) → recognized, works-ÉditeurScript(French command name) → works
So the code-execution path invokes the command without the leading _. Prefixing it — _-ScriptEditor — makes it locale-safe and should fix run_python/run_csharp on any non-English Rhino UI. run_command already works because the caller passes _-prefixed commands.
Workaround for non-English users meanwhile: switching the Rhino UI language to English makes -ScriptEditor resolve again, so run_python/run_csharp start working.
Otherwise the MCP is great — run_command and viewport capture are rock-solid. Thanks for the work!
Ah yes sorry, I’m missing the _ how embarrassing, I’ll fix that here → Add _ to Run Script by clicky · Pull Request #85 · mcneel/RhinoMCP · GitHub
Layout space is really important for the practical use of the MCP with agents, particularly as I’m using it to title blocks automatically from practice workflows. I often find that, despite referring to layout objects that I name, agents it tend to work in model space by default and often make destructive changes before they can be reminded of the layout/model difference. So I think layout understanding is very important for practical use of agents w .3DM’s.
That’s a good point. I’ll have to think about how I can support this better 
I had good results with RhinoAiMCP
Anyone else?
But i would prefer to use the official mcNeel MCP I will test it soon!
I connected it with my pi harness for interchangeable AI-models while working and added some skills so whichever AI i use knows my basic model rules. The workflow is not good enough for working commercially yet but it will replace a lot of daily-tasks soon 
i like manual modelling more that texting with AI but lets see where the road leads. Setting Dimensions on the other hand, that i would be glad to get rid off 
As a fun test, I also asked Claude AI to generate a teapot in Rhino using curves that I had drawn myself. I simply sketched the main curves, and the command generated the geometry based on them. It was interesting to see that it actually worked and produced a recognizable teapot from my input curves.
Hey im very new to AI integration, but does this plug in also work for Grasshopper? and is the plugin compatible with MacOS?
Yes and yes