Design tokens with Figma MCP and Claude Code

Keep your design decisions in design tokens, and let both Figma and code read from them. Figma MCP lets an AI coding tool such as Claude Code read variables and components straight from the Figma file, so a prototype is built with the real values instead of guesses. Storybook then shows whether the result matches.

Here is how that works, and what I would set up first.

What are design tokens?

A design token is a named design decision: a colour, a size, a font, a duration. Instead of writing #0a0a0a in a stylesheet, you write color-text-primary. The name says what the value is for, and the value can change per theme.

Tokens are written in a plain JSON format, often following the W3C design token format. One build step turns them into CSS custom properties and any other format the product needs.

Why use roles instead of raw values?

Roles are the layer between a value and a component. A component asks for “text primary” and each theme answers with its own colour. That is how light and dark themes share one set of components without a second stylesheet.

On this website every value in CSS comes from a token. The dark values sit next to the light ones in the same token file. A button never knows which theme it is in.

What does Figma MCP add?

MCP is a standard way for an AI tool to talk to another application. The Figma MCP server gives Claude Code access to the Figma file: variables, components and the structure of a design.

In practice that means:

• The prototype uses the actual variables, not colours sampled from a screenshot.
• Components in code follow the structure of the components in Figma.
• When a token changes, the change can be traced from the file to the code.

This is the setup I use for coded prototypes. The tokens are synced via Figma MCP, the prototype runs on the real design system, and I check the result against Figma.

Where does Storybook fit in?

Storybook is the place where code components are shown with all their variants. It answers a simple question: does the built component look like the designed one? At NURI the handover ran through Storybook, and it kept design and code in sync while the team grew. The NURI case study has the details.

How do you set this up?

1. Name tokens by role. Start with colour and type, then space, radius and motion.
2. Store light and dark values together. One token, two answers.
3. Build the tokens into code in one step. Everything downstream reads the output.
4. Connect Figma and your AI tool through MCP. Let the prototype read the real file.
5. Show everything in Storybook. Review components there, not in screenshots.

Key takeaways

• Tokens are named design decisions, shared by design and code.
• Roles make themes cheap.
• Figma MCP gives an AI tool the real variables and components.
• Storybook is the check that design and code still match.

More on how this fits into my process is on the How I work page. The next step is design to code.