Building Arbor · Part 4

One conductor, many surfaces

Steven Neamonitakis

One low building drawn five times side by side in five different architectural notations: plan with hatched wall poché, section with hatched cut walls, plank elevation with a square window, axonometric wireframe, and dense cross-hatched silhouette with a window opening left as paper. A continuous vermillion datum line and dimension chain run below all five, unifying them.
One building drawn five ways, all tied to one reference line. The MCP server was that line for Arbor’s tokens, specs and research. Illustration made with an image model.

Part 4 of Building Arbor, a series about my year on Linktree’s design system.

Each of those tools knew something different. The problem was that you had to know which one to ask.

The design tokens lived in Figma. So did the component specs, which I configured with the Specs CLI and Figma plugin to understand our Figma components’ structure and map it to the structure of our code. The research lived in its own corpus. Each one was true, and each lived somewhere you had to go looking for. So I gave Arbor an MCP server that acted as a conductor over all of them.

Routing, not remembering

Instead of a human deciding “for this question I should check Figma, but for that one I need the specs, and for this other thing I should go read the research,” the MCP server made that routing decision itself. Ask it something, and it dispatches: this part goes to Figma to check the live token values, this part goes to the specs to check the component contract, this part goes to the research corpus for how the frontier handles it. Then it composes the answers back into one coherent response.

That’s the difference between a pile of good tools and a system. A person shouldn’t have to hold the whole map of where every kind of truth lives in their head just to ask a straight question. The conductor holds the map. You ask, and it knows who to ask, and it comes back with an answer that’s already reconciled across all of them.

The docs read from the same place

And once you have that front door, everything can walk through it. The documentation site itself consumed the same MCP server. The docs weren’t a separate artifact someone had to remember to update. They were another view of the same reconciled truth, so when the system’s answer changed, the docs changed with it.

Most teams treat docs as a maintenance tax and slowly lose the fight to rot. Making them a read-only view of live state means there’s nothing left to maintain.

The same instinct, at its conclusion

It’s the Figma plugin and the researcher taken all the way: don’t make people go find the knowledge. Put a single front door in front of all of it, and let the system route.

There was one surface left to reach, though: the one where engineers actually decide. That’s the last post.

Up next