One front door, several sources

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

A person shouldn’t need to know where every answer lives before asking a question.

Arbor’s design tokens lived in Figma. Component specifications described how the Figma library mapped to code. Research compared our choices with other systems. Each source was useful, but finding an answer meant knowing which one to consult and how its information related to the others.

I built an MCP server to act as a conductor across them. It gave people and agents a shared way to reach the system’s knowledge, while the individual sources kept their own jobs.

What the sources could tell us

A token tells you which value the system uses. A component specification describes its structure and contract. Research provides evidence for a choice or a recommendation about what to investigate next.

Those answers aren’t interchangeable. A recommendation from another system doesn’t establish what Arbor currently implements. A value in Figma doesn’t explain every constraint in a component’s code. Gathering the information is useful only if the answer keeps those distinctions clear.

I configured the component specifications with the Specs CLI and Figma plugin to understand our Figma components’ structure and map it to the code. That supplied a different kind of knowledge from the token values or the research corpus.

The work was to connect those kinds of knowledge without asking each person to assemble the map themselves.

Let the tool carry the map

Before the conductor, a question could turn into a sequence of searches: find the token in Figma, look up the component specification, then return to the research for the reasoning behind it.

The MCP server routed the request to the relevant sources and composed what came back. A question could need a live token value from Figma, a component contract from the specs, or a comparison from the research corpus. The server provided that route through the information.

That made the system easier to approach. Someone asking for help didn’t have to begin by learning how we’d organized all the tools behind it.

It also changed what I was designing. The interface was the path from a question to the evidence needed to answer it. The choices about where information belonged, how to retrieve it, and how to explain it were part of the same product problem.

A shared route doesn’t settle every answer

One front door is useful. It doesn’t make every source equally authoritative about every question.

When I think about a system like this, I want to distinguish what’s implemented, what’s specified, and what’s recommended. An answer can bring those together without treating a recommendation as a shipped capability. If they disagree, that disagreement is something to investigate.

We added provenance to Arbor’s guidance artifacts and MCP output so a consumer could see where information came from. That gives the next person something to inspect beyond the confidence of the response.

The responsibility for the sources remains. Someone still has to maintain a component contract, revise a recommendation, or decide which change should be made. Routing removes some of the work of finding the evidence. It doesn’t make the decision for us.

Docs from the same sources

The documentation site consumed the same MCP server. People reading the docs and agents retrieving guidance could reach the same underlying information through different interfaces.

That removed a source of duplication. A token or component fact didn’t need a separate manually maintained explanation in every tool that exposed it. When the underlying information changed, the views could draw on that change.

There was still documentation work to do: explaining why a choice existed, keeping the sources useful, and making sure the answer fit the question. Sharing the source reduced the number of copies we had to keep in agreement.

Write something once and then point at it. That was the principle behind the connection.

Different interfaces, shared decisions

The Figma plugin, documentation, and agent tools served different tasks. They didn’t need identical interfaces to draw on the same decisions.

The next part takes that knowledge into the pull request, then asks how we could check the guidance itself.