SR34 breaks rhinomcp "get" commands, need link to older SR

Hi all,

I updated Rhino 8 to the latest build today and my rhinomcp plugin
(v0.3.2.0, a third-party MCP integration) stopped working correctly
right after.

Symptoms:

  • “get” type commands (get_document_info, get_selected_objects,
    get_rhino_log) all fail on the client side with “Unknown command
    type” errors
  • However, the Rhino command line log shows these commands being
    received and completing successfully (“Executing command:
    get_document_info” / “Command execution complete”)
  • Object creation commands (create_objects) still work correctly
  • Reinstalling the plugin, restarting Rhino, restarting the PC, and
    clearing local caches did not resolve the issue

This started immediately after today’s update, so I suspect it may
be related to the SR34 update itself rather than the plugin.

Could someone please share a download link for the previous SR
(SR33 or earlier) so I can test whether reverting resolves this?

SystemInfo:
Rhino 8 SR34 2026-8-11 (Rhino 8, 8.34.26223.11001, Git hash:master
@f416e902495235e4e4a45cfc29ff1320cc8c70d8)
License type: Commercial
License details: Cloud Zoo
Windows 11 (10.0.26100 SR0.0) or greater (Physical RAM: 32GB)
.NET 8.0.23

Rhino plugins that do not ship with Rhino
C:\Users\563456356\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\rhinomcp\0.3.2\net8.0\rhinomcp.rhp “rhinomcp” 0.3.2.0

Thanks!

Sent English version of SR 33, let us know the results or if you need a different build

Follow-up Report: rhinomcp Command Failures

Summary

After the latest Rhino 8 update, several commands used via rhinomcp (a third-party MCP integration plugin) fail on the client side with Unknown command type errors. An earlier report in this thread described the issue as affecting only “get” commands, but further isolation testing shows the impact is broader than get-commands alone.

Reference thread: SR34 breaks rhinomcp "get" commands, need link to older SR

Environment

Item Value
Rhino version when the issue first appeared Rhino 8 SR34
Current version after downgrading Rhino 8 SR33 (8.33.26188.13001, 2026-07-07) Commercial
OS Windows 11
Already tried Downgrading to SR33 → did not resolve the issue

Symptom

The Rhino command line shows successful execution, but the client receives an error such as:

Communication error with Rhino: Unknown command type: <command name>

Isolation testing

Commands that work
Object creation
Object modification
Object info lookup (when id/name explicitly given)
Getting/setting current layer
Running native Rhino commands
Commands that fail Error
Getting full document info Unknown command type
Getting viewport info Unknown command type
Getting command history log Unknown command type
Getting currently selected objects Unknown command type
Selecting objects (by id, layer, or type) Unknown command type
Deleting objects Unknown command type
Getting/saving layer states Unknown command type
Getting the connectivity graph Unknown command type

New findings

  1. The problem is not limited to “get” commands. Selecting objects, deleting objects, and saving layer states all fail with the same Unknown command type error, regardless of the verb.
  2. Only a small, specific set of commands reliably works. Only object creation/modification, object info lookup by id/name, current-layer get/set, and running native commands were confirmed working.
  3. Downgrading to SR33 did not fix it. The workaround suggested earlier in this thread (reverting to SR33) was tried and did not resolve the symptoms. Current version after downgrade: Rhino 8 SR33 (8.33.26188.13001, 2026-07-07).

Questions for the Rhino team

  1. Is there any known change in SR34 (around command registration or the plugin API) that could explain this pattern?
  2. Since downgrading to SR33 did not help, could this be reproduced on an earlier build than SR33, or is it possible SR33 itself carries a related issue?

I changed the forum category to developer.

That’s not a Rhino error, this error comes from the rhinomcp plugin itself.

The plugin is replying when the Python server sends a command name that isn’t in the plugin’s dispatch table. The only thing i’m seeing is that you might want to pin/match the MCP
server version to the plugin version.