Why we are moving away from MCPs?
5 min read
Our open-source Rhino MCP server has hit 6,000 downloads so far. However, after spending months trying to develop it into a remote one for real use, we reached a conclusion - MCP just doesn’t fit CAD’s realities.
Over the past year, MCP (Model Context Protocol) has exploded across the AI developer community. It promises a universal way for LLMs to interact with tools. We’ve seen this firsthand. Our open-sourced Rhino MCP connector has been used for tasks like batch-modifying column widths, adjusting mullion dimensions based on vision ratios, and running design-variation analyses. (If you’re curious, we’ve shared several tutorial videos on our YouTube channel.) But we learned a few lessons along the way:
Multi-user x Multi-instance nightmare
MCP is great for hooking single-user-interface apps/APIs with an LLM, but CAD opens a new instance for every model file. Technically, you can spin up one server per instance, but then the management becomes untangling spaghetti. A helpful way to understand this contrast is through UI/UX design tools. In Figma, designers work within a unified environment, where multiple projects and files all live in a single, shared workspace. CAD, by nature, functions very differently: each file (.3dm, .rvt, .blend, etc.) is its own standalone instance. On top of that, a CAD project is often fragmented across numerous variation or component files (facade panels, mechanical parts, assemblies, and more). This means MCP isn’t managing one workspace - it must interpret, track, and operate across many independent files at once.
MCP is great if it's a one-way street
MCP shines for simple, single calls, but CAD needs rich, bi-directional communication. Even though MCP is moving to support streamable HTTP, bi-directional interactivity (server-initiated requests, interactive updates, session resumability) is not yet mature. Think of something like a route-planning agent: it uses MCP to fetch locations and navigation data from Google Maps – a clean, single-direction, and self-contained request. CAD workflows are fundamentally different. Here, the agent is co-editing with the human user. While the designer is modifying the model, the agent must continuously reference updated geometry, validate results, adjust parameters, and re-evaluate. These steps can repeat dozens of times within a single task — far beyond a simple one-time information retrieval.
Extra Latency
An extra layer of the MCP server means one more round of delay: 𝘳𝘦𝘲𝘶𝘦𝘴𝘵 → 𝘴𝘦𝘳𝘷𝘦𝘳 → 𝘊𝘈𝘋 → 𝘴𝘦𝘳𝘷𝘦𝘳 → 𝘢𝘨𝘦𝘯𝘵. This is doubling roundtrips, compared to if you could skip the server layer and directly make tool calls to the CAD in the agent loop. A useful example here is Claude Code. When Claude executes functions like grep, read, or update, it calls them directly. This would cut the processing time by at least half compared to inserting an MCP layer, as every file read, every search, every update would incur two additional hops before the model even sees the result. CAD compounds this even further. The agent isn’t just reading a file or updating a line of code; it’s modifying heavy geometry, checking results, adjusting parameters, and repeating this cycle continuously. Adding an extra MCP layer multiplies latency at every step, making the feedback loop noticeably slower and far less usable in practice. And that’s still not counting the harder problems: overflowing context windows, CAD’s deeply entangled APIs, and the security restrictions required for running agents on desktop environments.
Our Rhino MCP Server Still Exists — Try It Yourself
Our MCP server is still available and open-sourced, and we actively encourage you to experiment with it. The best way to understand any tool in the AI era is to try it yourself. For many builders, MCP may still be the perfect bridge for lightweight automations or custom local agents. At the same time, we believe that CAD also needs its own flavor of protocol: one designed for multi-instance lifecycles, high-bandwidth context, and true bi-directional communication.
What’s next for Reer?
With our new architecture in place, we’re opening the door to an entirely different interaction model. You’ll see Reer move beyond text-only commands and into more expressive, intuitive ways of communicating design intent. This isn’t just a technical shift; it’s a foundation for a faster, richer, and more natural AI × CAD experience.
We can’t wait to share what’s coming.