How do I give an AI coding agent design context?

Connect Figma's MCP server so the agent can read the design, map Figma components to code with Code Connect, export design tokens instead of hard-coded values, connect Storybook's MCP server so the agent knows your existing components, and write your design rules and decisions where the agent reads them.

Is a screenshot enough design context for an AI agent?

No. A screenshot shows how something looks, not which component, token, or spacing value it uses. Agents working from screenshots tend to rebuild components that already exist and hard-code colors and sizes. Use structured context from the design file and the component library.

What does Figma Code Connect do for AI agents?

It links components in your Figma files to the matching components in your repository. Figma's MCP server then gives agents references to your actual code components instead of generic generated code. It needs a Dev or Full seat on a Professional, Organization, or Enterprise plan.

Does Storybook have an MCP server?

Yes. The @storybook/addon-mcp addon serves an MCP endpoint from the Storybook dev server, at localhost:6006/mcp by default. It exposes component documentation, story lookup, and test runs. Storybook marks it as a preview, and the docs tools need a supported framework such as React, Angular, or Vue with Vite.

Where should design decisions live for AI agents?

Stable rules, such as always using spacing tokens, belong in CLAUDE.md or a path-scoped rule for UI files. Decisions with an owner and a reason, such as no modals in the mobile checkout, belong in a shared decision record the agent can read, so they survive when the person who made them is not in the room.

How to give AI coding agents design context

A designer hands off a checkout screen in Figma. An engineer asks an AI coding agent to build it from a screenshot.

The result looks close. It also hard-codes #4F46E5 instead of the brand token, builds a new button instead of using <Button variant="primary">, uses 14px spacing where the system says 16, and puts the address form in a modal, which the design team ruled out for mobile three months ago.

None of these are model failures. The agent had a picture, and a picture carries none of the information it needed. This guide covers the five layers of design context and the tools that supply each, with details from each vendor's documentation as of 4 November 2026.

The five layers of design context

Design context is more than how a screen looks. An agent building UI needs five kinds of information:

Layer	What the agent needs to know	Tool
The design	Layout, structure, which components and variables each layer uses	Figma MCP server
Design to code mapping	Which code component matches each design component	Figma Code Connect
Values	Colors, spacing, type as named tokens, not raw numbers	Design tokens (DTCG format)
The component library	What already exists in code, its props and usage	Storybook MCP server
Rules and decisions	What to always do, and what the team decided not to do	CLAUDE.md, rules, a decision record

A screenshot covers part of the first row. The rest is where the rework comes from.

Layer 1: the design, through Figma's MCP server

Figma's MCP server lets an agent read a Figma file as structured data instead of pixels. The remote server, at mcp.figma.com/mcp, doesn't need the desktop app. Its read tools include:

get_design_context: design context and code for the selected layers
get_variable_defs: the variables and styles a selection uses
get_metadata: a lightweight outline of the selection
get_screenshot: a screenshot, for when the agent needs to see it too
search_design_system: components, variables, and styles in your libraries

In Claude Code, install it as a plugin and authenticate through /mcp:

claude plugin install figma@claude-plugins-official

The server can also write to the canvas, which needs a Full seat. Reading designs is the part that matters for building UI.

Layer 2: map design components to code with Code Connect

Without a mapping, an agent sees a Figma component called "Button / Primary" and has to guess what it is in code. Usually it writes a new one.

Code Connect links components in your Figma files to the components in your repository. Dev Mode then shows your real code snippets, and Figma's MCP server gives agents direct references to your actual components. It supports React and React Native, HTML with Web Components, Angular, and Vue, SwiftUI, and Jetpack Compose.

There are two ways to set it up: Code Connect UI inside Figma with a GitHub connection, or the Code Connect CLI with template files in your repo. It needs a Dev or Full seat. Professional plans are limited to one library and one framework; Organization and Enterprise plans support more.

Of the five layers, this is the one that most reduces duplicate components.

Layer 3: replace raw values with design tokens

An agent that reads #4F46E5 from a design will write #4F46E5 into your code. An agent that reads color.brand.primary will use the token.

Design tokens are named values for color, spacing, type, and the rest. The Design Tokens Community Group published the first stable version of its format, 2025.10, on 28 October 2025. Tokens are JSON with $value and $type fields:

{
  "color": {
    "brand": {
      "primary": { "$value": "#4F46E5", "$type": "color" }
    }
  },
  "space": {
    "4": { "$value": "16px", "$type": "dimension" }
  }
}

Figma, Penpot, Sketch, Tokens Studio, and Style Dictionary are among the tools that support the format. Keep the token file in the repo, generate your CSS variables or theme from it, and the agent can read the source of truth directly. Figma's get_variable_defs tool returns the variables a design uses, so the agent can match a design value to a token name.

Layer 4: the component library, through Storybook's MCP server

Even with Code Connect, an agent needs to know how your components are meant to be used: props, variants, and which story shows the right pattern.

Storybook's MCP server serves that from your running Storybook. Add it with:

npx storybook add @storybook/addon-mcp

Then set componentsManifest: true in .storybook/main.ts, start Storybook, and connect the agent to the endpoint, http://localhost:6006/mcp by default:

claude mcp add --transport http storybook http://localhost:6006/mcp

Its docs tools (docs-list, docs-show, docs-show-story) let the agent look up components before writing new ones. Its development tools find stories by component and preview changes, and test-run runs your tests. Two limits: Storybook labels the MCP server a preview whose API may change, and the docs tools need a supported framework, such as React, Angular with Vite, or Vue with Vite.

Layer 5: rules and design decisions

The last layer is the one no design file holds: the rules and the reasons.

Stable rules go where the agent reads instructions every time UI work starts. In Claude Code, a path-scoped rule in .claude/rules/ loads only when the agent touches matching files:

---
paths:
  - "src/components/**"
  - "src/app/**/*.tsx"
---

# UI rules
- Use components from src/components/ui before writing new ones.
- Use tokens from tokens/ for every color, space, and font size. No raw values.
- Check Storybook docs for a component's variants before adding props.

Figma's MCP server also offers a create_design_system_rules prompt that generates a starting set of rules from your design system.

Design decisions are different. "No modals in the mobile checkout." "Destructive actions always need a confirm step." "The compact table density is for admin screens only." These have an owner, a reason, and a date. They change when the team learns something, and they are usually made in a design review or a Slack thread, not in a file. Put them in a rules file and they go stale; leave them in Slack and the agent never sees them.

Common mistakes

Building from screenshots. The agent can't see tokens, components, or spacing values in pixels. Connect the design file.

Skipping Code Connect. Without it, every new screen risks new duplicate components.

Tokens only in the design tool. If the token file isn't in the repo, the agent can't read the source of truth.

A rules file that grows forever. Keep UI rules short and path-scoped. Long files reduce how reliably Claude follows them; see why Claude Code ignores your CLAUDE.md.

Too many servers at once. Each MCP server adds tool definitions to context. Connect Figma and Storybook for UI work, not for every session.

Where Lockstep fits

Lockstep covers the design decisions in layer 5. It captures decisions from Slack threads, PRDs, and pull requests, including design review outcomes written there, and each becomes binding when its owner, often a design lead, approves it. Claude Code is briefed on the decisions that apply to its work at the start of each session, and any MCP agent can query them. When a decision changes, the old version stays visible as replaced.

It does not read Figma files, map components, or manage tokens; use Figma, Code Connect, and Storybook for those. Session briefings work with Claude Code today. See how it works.

Sources checked 4 November 2026

For other live context sources, see the best MCP servers for product engineers and dev teams. For the full context stack, see the best tools to give AI coding agents context. For how path-scoped rules load, see how Claude Code memory works.

Frequently asked questions