Connecting agents to Rhino

Back to the stack. We have covered company and model and harness (app or agent). Now: connecting agents to rhino. How does an agent get to touch Rhino? What is MCP, and why is it a standard? How is Lattice different?

MCP is like a restaurant. Rhino is the kitchen: the agent doesn't know how it works inside. A Rhino MCP server publishes a menu: each tool with a name and a description. The agent reads the menu, which enters its context; orders get_layers; the order travels through MCP, the waiter; Rhino cooks and the result comes back. Note: the menu is re-sent with every message, so a long menu costs tokens; more tools isn't always better. And because it's a standard, it's a plug: the same agent connects to Rhino, Grasshopper, GitHub or Drive, with no custom wiring for each. Illustrative tool names; they depend on the server.

MCP (Model Context Protocol)

A standard for connecting agents to programs. The program publishes a menu of tools; the agent reads it, orders, and receives results.

MCP server

The small program that exposes a piece of software's actions (for example Rhino) as MCP tools.

Lattice isn't magic: it's the same parts we've already seen. An agent with the same loop, decide, act, observe, with a harness built for Rhino. Its own bridge: Lattice talks to Rhino through its bridge server and tools, a direct cable, without MCP. And the models: it uses OpenRouter, so you pick the model for each task. It's a desktop app. With it: you describe the task in plain language and it writes the Python or C# for the ScriptEditor, runs and debugs it on the open file, and you pick the model seeing what it costs.

Lattice

A desktop agent and code editor for Rhino. It connects to Rhino through its own bridge and uses models through OpenRouter.