An AI agent that generates a prototype from your design system is only as good as what it can read of that system, and most agents in 2026 read almost nothing - they see a prompt, average their training data, and produce something that looks like a generic design system rather than yours. The Storybook MCP server changes the input. It gives an agent a structured, live window into your actual components and the tokens they consume, so that when you ask it to build a screen, it reaches for your real Button with your real variants and your real spacing tokens instead of inventing a plausible button from scratch. This lesson wires a Figma library to a Storybook instance through the Storybook MCP server, demonstrates an agent reading components and tokens to generate a prototype, and produces the artifact that proves it works: a functioning Figma-to-Storybook connection plus a Lovable prompt that uses the connection correctly rather than hallucinating around it.

The Problem the Connection Solves

Start with what happens without the connection, because it is the failure this whole pattern exists to prevent. You ask an AI prototyping tool - Lovable, v0, any of them - to "build a settings page using our design system." The tool has your prompt and nothing else. It does not have your component library, your token file, or your documentation. So it does what a generation model always does: it produces the average of every settings page and every design system it has seen, which is competent, generic, and not yours. The buttons are plausible buttons, not your Button. The spacing is reasonable spacing, not your 8-point scale. The result looks like a design system, which is exactly the trap - it has the polish without the membership.

You then spend an afternoon correcting it: swapping the generic components for your real ones, re-spacing to your scale, fixing the colors to your tokens. This is the manual-refinement tax in its purest form, and it recurs every single time, because nothing about the correction taught the tool anything for next time. The fundamental problem is that the agent had no access to your system. It was asked to build with your components while being unable to see them. The Storybook MCP server is the access layer that fixes this at the source: instead of correcting the agent's guesses after the fact, you give it the real thing to read before it generates.

What the Storybook MCP Server Actually Exposes

Storybook has been, for years, the place where a design system's components live as running, documented, interactive instances - each component with its variants, its props, its states, rendered in a browser. It is the closest thing most teams have to an executable specification of their design system. What the Storybook MCP server does is make that executable specification readable by an AI agent through the Model Context Protocol, the standard way agents connect to external context in 2026.

Concretely, an MCP-enabled agent connected to your Storybook can query what components exist (your Button, Card, Modal, Input), what variants and props each one has (the Button has a variant prop with values primary, secondary, ghost, and a size prop), and - when your tokens flow into Storybook - what design tokens are in play and what values they resolve to. The agent stops guessing what your button looks like and starts reading what your button is. This is the difference between an agent that hallucinates a PrimaryCardButton that does not exist in your system and an agent that uses Button variant="primary" because it read that the real prop exists and the made-up component does not. The MCP server turns your Storybook from documentation a human reads into context an agent consumes.

An agent that cannot read your system builds the average of every system. An agent that can read your Storybook builds with your actual components and tokens. The MCP server is the difference between correcting the agent's guesses after the fact and giving it the real thing to read before it generates.

Wiring the Figma Library to Storybook

The connection has three links, and each one closes a seam where the brand could otherwise fragment. The first link you already built: the token file is the source of truth, and it flows into both Figma (through Figma Variables) and into Storybook (where the components consume the same tokens as CSS variables or their platform equivalent). This is what makes the Figma library and the Storybook components two views of one system rather than two unrelated artifacts. If your Figma Button and your Storybook Button both resolve color.action.primary to the same value from the same source, they are genuinely the same component expressed in two tools.

The second link is Figma Code Connect, which maps a Figma component to its real code counterpart - it tells the system that the Button frame in Figma corresponds to the Button component in code, with this prop mapping. This is the bridge that lets a tool reading the Figma side know the real code component and props on the other side, rather than guessing. The third link is the Storybook MCP server itself, which exposes the Storybook components (and the tokens they consume) to the agent. Stack the three and you have a continuous chain: the token file feeds Figma and Storybook, Code Connect maps Figma to the code components, and the MCP server lets the agent read the Storybook side. An agent at the end of that chain can read a design intent and resolve it all the way down to real components built on real tokens, because every link is wired rather than inferred.

The practical setup is a collaboration with engineering, and that is the honest truth of this lesson: a brand or product designer rarely stands up an MCP server alone, and should not pretend the wiring is a solo designer task. What the designer owns is the system being connected - that the tokens are clean, the components are documented, the Code Connect mappings are correct - and the verification that the connection produces correct output. The engineer owns the server plumbing. The pattern is a joint artifact, and recognizing that is part of operating as a senior IC rather than overreaching into a claim you cannot back.

Demonstrating the Agent Reading Components and Tokens

A connection you cannot demonstrate is a connection you cannot trust, so the heart of this lesson is showing the agent actually read your system. The demonstration is a before-and-after, and the contrast is the proof. Before the connection, you prompt the agent to build a screen using your design system, and you watch it invent: a button component with a prop your system does not have, spacing values off your scale, a color close to but not equal to your brand. The output is the generic average, and you can name exactly where it diverged from your system.

After the connection, you give the agent the same prompt with the Storybook MCP server available, and you watch it query. It reads that Button exists with variant and size props, that Card exists with a padding prop bound to a spacing token, that the spacing scale is 4, 8, 12, 16, that color.action.primary resolves to your exact brand value. Then it builds the screen using those real components, real props, and real token values. The difference is visible and specific: the after-output uses Button variant="primary" where the before-output used a hallucinated component, and uses your exact spacing where the before-output used an approximation. You are not asserting the connection works; you are showing the agent reach into your system and use what it found, which is the only evidence that means anything.

The Lovable Prompt That Uses the Connection Correctly

The artifact that proves you understand the pattern is not just the connection but a prompt that exploits it correctly, and there is real craft in writing one. A bad prompt for a connected agent ignores the connection and over-specifies, telling the agent exactly what HTML and CSS to write, which defeats the purpose - you have a connected system precisely so you do not have to hand-specify the components. A good prompt does the opposite: it describes the screen in terms of intent and the design-system vocabulary, and explicitly instructs the agent to use the connected system rather than inventing.

So a correct Lovable prompt for a connected agent reads something like: "Build a customer settings page. Use our design system components from the connected Storybook - the Card for each settings group, Input for fields, Button variant='primary' for the save action and variant='ghost' for cancel. Use our spacing tokens for all gaps, not arbitrary values. If a component or prop you need is not in our system, stop and tell me rather than inventing it." Read what that prompt does. It speaks in your component and prop names, which the agent can verify against the MCP server. It instructs token use over arbitrary values. And the last sentence is the most important: it tells the agent to surface a gap rather than hallucinate across it, which converts the agent's most dangerous failure mode (confidently inventing a component) into a useful signal (telling you your system is missing something the screen needs). A prompt that includes that instruction is a prompt written by someone who understands that the connection's value is precisely that the agent can now know the difference between what your system has and what it does not.

Notice that the prompt does not specify implementation. It does not say "make the button blue" or "use 16px padding." It says "use Button variant='primary'" and "use our spacing tokens," and trusts the connected system to resolve those to the right values - blue and 16px - from the source of truth. That trust is only warranted because the connection exists and you verified it. On an unconnected agent the same prompt would fail, because the agent has no way to resolve variant='primary' to anything real; on a connected, verified agent it succeeds, because the prompt and the connection were designed for each other.

A Worked Read: What the Agent Actually Queries

It helps to make the abstract "the agent reads your system" concrete by walking through what a query actually looks like in practice, because seeing it demystifies the whole pattern. You give a connected agent the prompt to build a settings page. Before it writes a line of UI, it asks the MCP server a series of questions, and the answers shape everything it produces. It asks, in effect, what components are available, and gets back a list: Button, Card, Input, Select, Toggle, Modal. It asks what props Button takes, and learns variant (primary, secondary, ghost, destructive), size (sm, md, lg), and disabled. It asks what spacing values exist and learns the scale is 4, 8, 12, 16, 24, 32. It asks what color.action.primary resolves to and gets your exact brand value.

Armed with those answers, the agent's output is constrained to reality. When it needs a save button, it does not invent a styled element - it reaches for Button variant="primary" because it confirmed that variant exists. When it needs to separate settings groups, it uses your Card with a gap from the real spacing scale, not an arbitrary 14 pixels. When the prompt asks for a destructive "Delete account" action, it uses Button variant="destructive" because it read that the destructive variant is real, rather than coloring a generic button red and hoping. Every choice the agent makes traces back to something it read, which is precisely the property that makes the output yours. The query step is invisible in the final artifact, but it is the entire reason the artifact is system-compliant, and being able to point to it - "here is what the agent read, here is how the output reflects it" - is how you demonstrate the connection is real rather than asserted.

The Workflow in Practice, and the New Collaboration Point

Running this pattern day to day changes the shape of a prototyping session in a specific, useful way. The old session was: prompt, wait, receive generic output, spend an afternoon correcting it toward your system, repeat. The new session is: prompt in system vocabulary, the agent queries and assembles from the real system, you receive system-compliant output in minutes, and you spend your time on the thing that actually needs you - reviewing whether the system-compliant screen is a good screen. The mechanical reconciliation that used to eat the session is gone, absorbed by the connection. What remains is design judgment, which is where it always should have been.

The pattern also creates a genuinely new collaboration point that did not exist before: the gap report. When the agent, following your prompt's instruction, stops and says "the screen needs a date-range picker and your system does not have one," that is a new and valuable signal. It is the agent telling you, from real use, where your system is incomplete. You then make a systems decision: add the component to the library through proper governance, rework the design to compose existing components, or note the gap for a future system iteration. The agent is a good gap-detector and a poor system-architect, so its report feeds your judgment rather than replacing it - but the report itself is information you never used to get, surfaced precisely because the agent could read your system well enough to know what was missing. This is the collaboration the connection makes possible: the agent assembles from what exists and tells you honestly what does not, and you decide what to do about the difference, which is exactly the senior-IC judgment the connection frees you to spend your time on.

Where This Can Still Go Wrong

The connection is powerful, which means its failures are quieter and more dangerous than the obvious hallucination it replaces. Three are worth naming. First, a stale Storybook: if the MCP server exposes a Storybook that has drifted from your real production components, the agent reads confidently from a wrong source and produces output that matches a system you no longer ship. The connection is only as trustworthy as the freshness of what it exposes, which makes keeping Storybook current a load-bearing maintenance task, not a nice-to-have.

Second, incomplete documentation: the next lesson is entirely about this, because an agent can read that a Button exists and still misuse it if the Storybook does not document the intended use, the constraints, and the edge cases. Reading the prop is not the same as understanding when to use it. Third, over-trust: a connected agent produces output that is right about components and tokens, which makes it tempting to skip the design review entirely - but using the right components correctly does not guarantee the right screen. The agent can assemble your real Button, Card, and Input into a settings page with broken hierarchy, a destructive action in the wrong place, or a flow that does not serve the user, all in flawless system-compliant components. The connection guarantees system membership; it does not guarantee good design. That judgment - the generation-versus-understanding gap from the very first lesson of this program - remains yours, now applied to output that is harder to dismiss because it is built from your real parts.

Key Takeaways

• Without access to your system, an AI prototyping agent builds the average of every design system it has seen - competent, generic, and not yours - and you pay the manual-refinement tax correcting it every time. The Storybook MCP server fixes this at the source by giving the agent the real thing to read before it generates, instead of correcting its guesses after.
• Storybook is the executable specification of your design system - components with their variants, props, and states, running and documented. The MCP server makes that specification readable by an agent, so it queries what components and props actually exist and uses Button variant="primary" instead of hallucinating a PrimaryCardButton that does not exist.
• The connection is three links: the token file feeds both Figma (via Variables) and Storybook (as consumed tokens); Figma Code Connect maps each Figma component to its real code counterpart and prop mapping; and the Storybook MCP server exposes the components and tokens to the agent. Stacked, they let an agent resolve a design intent down to real components on real tokens, every link wired rather than inferred.
• This is a joint artifact with engineering, and saying so is part of operating as a senior IC. The designer owns the system being connected (clean tokens, documented components, correct Code Connect mappings) and the verification of correct output; the engineer owns the server plumbing. Do not claim the wiring as a solo designer task.
• Prove the connection with a before/after demonstration: the unconnected agent invents components and approximates spacing; the connected agent queries the real Button, Card, spacing scale, and token values and builds from them. Showing the agent reach into your system and use what it found is the only evidence that means anything.
• A correct Lovable prompt speaks in your component and prop names, instructs token use over arbitrary values, and tells the agent to surface a gap rather than invent across it - converting the agent's most dangerous failure (confidently hallucinating a component) into a useful signal. The connection guarantees system membership, never good design; the generation-versus-understanding judgment stays yours.