Rewriting the MCP Server
The MCP server we added to Sirius2 has been working, but it’s been fighting us on edge cases. The MCP client reports invalid array slots. The metadata grouping is off for some components. The SSE connection drops under load.
The first implementation was always a prototype. We wanted to see what happens when you give AI agents native access to a design system. The results were overwhelmingly positive. Agent-generated UIs went from “close but wrong” to “correct on first try” for component usage, props, and slot syntax. That made the rewrite worth doing properly.
What the prototype taught us
The hand-rolled JSON-RPC implementation over SSE and STDIO proved the concept. Agents with MCP access to Sirius2 produce dramatically better ORB templates than agents working from training data alone. That’s the important finding.
But the protocol implementation itself was fighting us. MCP’s surface is larger than it looks. The spec is clear about the happy path, but the interaction between capabilities, tool schemas, resource URIs, and transport-level concerns has enough subtlety that getting it right from scratch is a significant effort. We were spending more time debugging the protocol layer than improving the actual tools. That’s backwards.
The rebuild
The official ruby-mcp SDK handles all the transport and serialization. You define tools as Ruby classes with typed parameters, and the SDK handles everything else: JSON-RPC framing, capability advertisement, schema generation, error responses.
The rebuild took a fraction of the effort. The old implementation was deleted entirely. Every line. The new one defines the same tools (find_components, get_component_details, search_design_tokens, search_icons) plus adds resource support (listing all components, all tokens, all icons as MCP resources). The dispatcher is cleaner. The responses are correct. The connection doesn’t drop.
The lesson that became AnyMCP
The struggle with the first implementation is what led to AnyMCP. While fighting the protocol for Sirius2, I kept thinking: every team that wants to add MCP to their tools is going to hit the same friction. The protocol is standardized, but the implementation effort is not. You still need to set up transports, handle the handshake, wire up tool dispatch, manage connections.
AnyMCP came from asking “what if you didn’t have to do any of that?” Drop your tools in a folder, AnyMCP serves them as MCP. Auto-generate schemas. Playground for testing. One command to deploy. The Vercel model applied to MCP servers.
Both projects are better for the experience. Sirius2’s MCP server is now solid, built on the SDK, focused on the tools rather than the plumbing. And AnyMCP exists because the plumbing shouldn’t be everyone’s problem.