1. Home
  2. Rhino MCP
  3. Troubleshooting

Rhino MCP not working? Fixes by symptom

Rhino MCP failures are one of three things: the plugin is not loaded, the bridge was never started, or your AI client cannot launch the server. Rhino makes the middle one easy to check — and it is the most common cause by a wide margin.

Updated 11 September 2026 · ZirenAI

Check this first — it is usually this

On the community rhinomcp route the TCP listener does not start with Rhino. You start it by typing a command, and if you never do, the plugin sits there installed and completely inert. No error appears anywhere.

In Rhino's command line:

mcpstart

If it starts, you will see the listener come up on 127.0.0.1:1999. Try your AI client again before changing anything else. More people are stuck here than on all the other causes on this page put together.

“Unknown command: mcpstart”

Unknown command: mcpstart

What it means. The plugin is not loaded, so its commands do not exist. Installing through Package Manager is not enough on its own.

The fix. Two things, in order. First, restart Rhino — the plugin does not register its commands until you do, and this catches most cases. Second, check Tools → Options → Plug-ins: the plugin should be listed and enabled. If it is listed but disabled, enable it and restart again. If it is not listed at all, the install did not complete — reinstall from Package Manager.

“spawn uvx ENOENT”

Error: spawn uvx ENOENT

What it means. Your AI client could not find the uvx command to launch the server. Nothing to do with Rhino.

Why it happens. A desktop application does not inherit the PATH from your shell. uvx runs fine in your terminal, so the command clearly exists — the GUI app simply cannot see it.

The fix. Put the absolute path in the config. Run which uvx (macOS) or where uvx (Windows) and use the result:

{
  "mcpServers": {
    "rhino": {
      "command": "/Users/you/.local/bin/uvx",
      "args": ["rhinomcp@latest"],
      "env": { "RHINO_MCP_HOST": "127.0.0.1" }
    }
  }
}

Restart the client fully afterwards.

“Error executing MCP tool: Not connected”

Error executing MCP tool: Not connected

What it means. The client knows about the server but the connection is not live when the tool is called.

The fix. Both halves must be up: Rhino open with mcpstart run, and the server process alive. If the server exits on launch, run its command by hand in a terminal — the startup error is informative and is swallowed entirely when the client launches it in the background.

“Connection refused” on 127.0.0.1:1999

Connection refused. Is the MCP server running?

What it means. Something reached out to port 1999 and nothing answered.

The fix. Either the listener is not running — run mcpstart — or the host and port in your configuration do not match what the plugin bound to. Confirm RHINO_MCP_HOST is 127.0.0.1 and that nothing rewrote the port.

Port 1999 is already taken

What it means. mcpstart cannot bind because another process holds the port. Everything else looks healthy.

The fix. Find out what is on it:

lsof -nP -iTCP:1999 -sTCP:LISTEN     # macOS / Linux
netstat -ano | findstr :1999          # Windows

Stop that process, or move the bridge to another port — and change it in both the plugin and the client configuration. Changing one side only produces a silent failure that looks exactly like the connection problem above.

The server is not listed in the client at all

What it means. The client never read your configuration, usually because the JSON is invalid. Many clients fail silently rather than saying so.

The fix. Run the file through a JSON validator. The three usual culprits are a trailing comma after the last entry, curly quotes pasted from a web page, and unescaped backslashes in a Windows path:

"command": "C:\\Users\\you\\.local\\bin\\uvx.exe"

Then quit the client completely and reopen it.

A tool fails asking for a newer plugin

What it means. The server and the Rhino plugin are versioned separately. When the server is newer than the plugin, a tool that needs the newer half fails with an instruction to update rather than doing something unexpected — which is the right behaviour, if a surprising one to meet mid-task.

The fix. Update the plugin in Package Manager and restart Rhino. If you pinned the server with rhinomcp@latest it moves on its own, so this will recur; pin an explicit version on both sides if you need stability.

It stopped working after a Rhino upgrade

What it means. Plugins are built against a specific Rhino version. The community package targets Rhino 8; McNeel's RhinoAI currently develops against a Rhino 9 branch. A major upgrade can leave you on the wrong side of that line.

The fix. Match the build to your Rhino version, and expect to redo this at each major release. It is a recurring cost of the free routes rather than a one-off.

It works, then times out on bigger jobs

What it means. The request needed more round trips than the client allows. Operations across hundreds of objects are the usual trigger.

The fix. Split it. "Re-layer the façade panels, then rename them" completes where "tidy up the whole model" times out. This is a limit of the current tooling, not a misconfiguration.

Or skip all of this

Every failure on this page is one ZirenAI handles for you. It installs the plugin and the runtime Rhino needs, starts the bridge — including after a restart — and re-checks the connection before every run, naming the failing part when it breaks.

Download for Windows