// Two Figma files — a design system and production screens — become frontend code through MCP. The DS file generates .md specs, the screen file generates components. The tooling shifts under you, so the specifics here are pinned to mid-2026.
// Overview — full pipeline at a glance
Figma's Dev Mode MCP server opened in beta on 2025-06-04. Today there are two ways to run it, and the choice matters.
The remote server, added 2025-09-23, is the one to reach for. It's hosted at mcp.figma.com/mcp — no Figma desktop app, no local process. Point Claude Code at that endpoint and you're connected. The local server still exists, but it runs through the Figma desktop app and needs a Dev or Full seat.
Either way, the server is the bridge. Claude Code never touches Figma directly — it asks the MCP server, and the server talks to Figma. Build the bridge before anything else. Nothing downstream works until it's standing.
The pipeline is driven by two distinct Figma sources: a Design System file and a Screen file.
The Design System Figma file defines tokens, components, variants, and usage guidelines. Claude Code calls get_design_context to read it and generate a structured set of .md specifications — design-system.md at the top, foundations/ (color, typography, spacing), and components/. Token values come from get_variable_defs, which returns the variables and styles bound to the current selection.
That tool used to be called get_code. The rename is the reason this page carries a date — the surface shifts, so the specifics have to be pinned to a moment.
The Screen Figma file represents real product screens composed using the Design System. The same tools derive patterns/ and templates/ from it — how screens combine DS components into layouts and flows.
Screen specs reference the DS — they don't override it. The DS definitions always win.
During code generation, Claude Code reads the Screen Figma and maps each node to the corresponding DS definitions. What keeps the output from being a pile of divs is Code Connect — a contract that binds a Figma node to the real component in your library, so generated code mirrors your components instead of reinventing them. You author that mapping through the CLI or, now, an in-app mapping UI. Figma variables map to DS tokens, so generated components use the same values as the spec.
The original 4-layer structure (Base → Semantic → Component → Tailwind) had three structural problems: no State layer for interaction/status tokens, Component tokens overloaded with state responsibility, and Tailwind appearing too early as a design layer rather than a rendering layer.
The revised architecture adds two critical layers:
State layer sits between Semantic and Component. State tokens define transformations, not static values. Hover applies darken(8%) to color tokens, elevate(+1) to surface tokens, ring(2px) to focus tokens. Components never define states inline — they compose Semantic + State references, preventing naming explosion (no sidebar-hover, sidebar-active, sidebar-error). Component tokens define stable slots, not state variants.
Platform layer sits between Component and Tailwind. It handles theme resolution (light/dark mode), density variants (compact/cozy), and reduced-motion preferences. Platform tokens resolve per context: --primary outputs #0F62FE in light mode, #4589FF in dark. The DS remains technology-agnostic; only the platform bridge changes when switching from Tailwind to CSS-in-JS or native.
Underlying the entire structure is a token dependency graph: primary-hover → primary → accent-600. Every token knows its upstream source. So when accent-600 changes, you can trace what breaks, derive dark mode automatically, and catch regressions in QA.
Full pipeline: Figma → Base → Semantic → State → Component → Platform → Tailwind.
Review follows dependency order, not parallel execution. Design Agent and Copywriter Agent run first in parallel — visual fidelity and text/tone have no mutual dependency. Design output goes to Dev Agent — code quality, token usage, component architecture. Copy review is resolved in parallel and incorporated before QA.
QA Agent runs last as the final gate. It performs token audit, visual diff against Figma source, and WCAG AA accessibility checks. QA always sees the fully reviewed build — never a partial state.
FAIL is classified, not generic. QA routes failures to their source: design issues go back to Design Agent, code/token issues to Dev Agent, accessibility issues go back with the specific WCAG criterion that failed. This prevents the "loop back to build" black hole where nobody knows what to fix.
The pipeline is real, but it isn't seamless. Some things it will not carry, and you find out fast.
Every response is capped at roughly 20kb. Select a large frame and the call overflows — Figma's own docs warn that a big selection can blow past the model's max output. So you select narrow, generate, move on.
Images and assets don't come through. The tool writes a placeholder where your artwork should be, and you wire the real file in yourself. Custom fonts are the same story — unsupported. The system font renders; your typeface doesn't.
There's a ceiling on calls, too: 200 a day on Pro and Org seats, 600 on Enterprise. Enough for a work session, not enough to be careless.
The one I actually hit building this site was closer to home. Claude Code caps a single MCP tool response at 25,000 tokens by default. A dense DS spec sailed past it and the call errored out. The fix was one environment variable — MAX_MCP_OUTPUT_TOKENS, raised to give the response room. Set it before the wall, not after.
Constraints are part of the pipeline too. Encode them once, so you don't rediscover them on the next screen.