Figma MCP + Claude Code: How AI reads your file and writes lossless code

The designer transfers the Figma file to the developer. A week later, he looks at the collected screen and does not recognize it. The retreats float, the colors are almost the same, but not the same, the icons are replaced by the nearest from the library, the states of the buttons are collected by an eye. No one is to blame: the developer honestly looked at the layout, the designer honestly drew it. Just in between is a thick layer of manual interpretation.

Figma MCP is trying to remove this layer. The idea is simple: Claude Code (or another agent) connects to Figma directly through the Model Context Protocol, reads the structure of the file as data rather than as a picture, and generates code by real tokens rather than an approximate “see blue button.” On paper, it sounds like “design > code in one click.” In practice, this is a new workflow in which there is something to break - it just breaks now in other places.

## What is Figma MCP

MCP is a protocol through which an AI agent accesses an external data source in a structured form. Not a screenshot, not an export to PNG, not a Dev Mode link for the eyes, but a tree of layers, components, variables, auto-leaut, with all the names and connections.

For Claude Code, this means something like this. You say, “Collect a product card component from the Product Card frame on the Catalog page.” The agent goes to the file, finds the desired frame, sees that inside there is an instance of the Button component with the primary/medium option, a token of bg/surface/raised color, indentations 12/16, text/body/m typography. And generates JSX (or Vue, or SwiftUI) already with these names – if the project is connected to the same tokens.

The key shift here is not "AI writes code." AI is already writing code. The shift is that AI no longer guesses design — it reads it.

## Why is it important right now

Previously, a bundle of “Figma → code” was held on two crutches: Dev Mode for people and plug-in generators for machines. They both had one thing in common: they worked with visual results, not intent.

• Dev Mode shows CSS, but does not know that this padding is a space/16 token, not a magic number.
• Generator plugins produce a div soup in which neither your system component nor your <Button> can be found.
• The LLM screenshot hallucinates class names and comes up with hex codes close to the real ones.

The MCP link decides not “how to draw a button” but “how to reuse an existing button from the codebase to names from the design system.” This is not about the speed of the prototype. This is about the fact that frontend and design cease to diverge.

This is not about touching a new toy. Teams that have a design system that lives in two parallel universes — tokens in Figma and variables in code — get a chance to bring them together. Those who do not live anywhere will receive a mirror through MCP: the agent will very quickly show that the system exists only in words.

## When it really helps and when it doesn’t

An MCP agent is not a universal layout converter. It has a zone where it pays off instantly, and a zone where it creates more work than it saves.

### Where it works well

• Assembly of typical screens from ready-made components: lists, forms, cards, settings.
• Transferring the screen from one breakpoint to another, when the designer made a desktop, and the mobile is needed “according to logic”.
• Updating the existing code for changes in design: the indentations, token, option have changed - the agent finds places and rules.
• Generation of Storybook stories and component states according to variants from Figma.

### Where it breaks

• Castomy animation and complex interactions - they are not in the file as data, the agent will think.
• Screens painted “freelance”: frames without auto-layout, colors with hexes, text override over the instances. An agent will honestly translate this chaos into code.
• Business logic and data states: loading, empty, error – if they are not in the layout, they will not be in the code.
• Availability: contrasts, focus, ARIA – MCP is not an auditor, it is a translator.

The rule of thumb: the more disciplined a file is in Figma, the more useful MCP is. On a dirty file, the agent becomes a dirt amplifier.

### File readiness checklist for MCP

• All colors, typography and indentations - through variables / tokens, without hard code.
• The components are assembled as components, not as groups of layers.
• Auto-layout wherever there is a structure; manual positioning is for illustration only.
• Layer and frame names are CardProduct, not Frame 482.
• Component variants cover real states, not just “as on the main.”.
• Icons are from a single library with meaningful names.

If there are more than two “nos” on this list, we order the file first, then connect the agent. Otherwise, you automate not the design system, but the lack of it.

## Workflow: from layout to pool request

The bare bundle "MCP is connected, agent is going to Figma" does nothing by itself. Useful it works only within an understandable cycle: the designer prepares the frame, the developer (or the designer himself) formulates the request, the agent collects the code, the person reviews the result and returns edits to the design or code. Without either of these steps, you get either handsome trash or endless correspondence with the agent.

### Step 1. Preparation of the frame as a “contract”

The frame you give to the agent is a technical assignment. If it does not contain names, tokens and states, TK is considered missing.

• Name the frame as the component in the code will be called: OrderSummary, not Order summary / final v3.
• Gather inside all the states you need: default, hover, disabled, loading, empty, error. What is not written is not in the code.
• Remove the “draft” layers from the frame: hidden options, notes, old versions. The agent sees everything, including what you forgot to hide.
• Check that the instances of components are instances, not disassembled copies.

### Step 2: Formulation of the request

Asking an agent is not “do it nicely.” This is a short, dense description of the boundaries of the problem.

A good template goes something like this: “Assemble the X component from the Y frame on the Z page. Use existing components from src/components/ui. Take the tokens from src/styles/tokens.ts. Don’t touch routing and states – just layout and props

The narrower the area, the cleaner the result. “Collect the whole screen of the checkout” is almost always worse than three separate section requests.

### Step 3. Review of the result

The generated code should be read, not just run. Look at the review in this order:

1. Did the real tokens and components of the system pull up, or did the agent start new ones.
2. Does the structure match the frame: nesting, auto-layout, directions.
3. The names of props and variants are close to those adopted in the code base.
4. What the agent came up with: classes, utilities, wrappers, which were neither in the design nor in the project.

The last point is the most insidious. Agents like to add “useful”: extra div wrappers, ARIA attributes at random, unused states. This is the noise that all of this is about.

## Diagnosis: Why the agent gave the wrong

When the result is clearly past, the problem is almost always in one of the four places. First, check the file, then the query, then the MCP configure, and only last, the model.

### Symptom: instead of tokens - hexes and magic numbers

Most likely, in the frame, the colors and indentations are set directly, without variables. The agent honestly read what he saw. It is treated not by editing the code, but by editing styles in Figma: transfer the layer to the token and ask to regenerate.

### Symptom: Components from the library are ignored

Two frequent roots. Either the project does not have a list of available components (the agent does not know about them), or the Figma instance has been dismantled (detached) and the agent sees a set of layers, not a component. Check both.

### Symptom: "It looks like it, but not like it"

The layout structure looks normal, but the indentations float and the flex behaves strangely. It is almost always a missing or broken auto-layout in the frame. The agent tried to reconstruct the geometry by coordinates - and guessed not everywhere.

### Symptom: the agent comes up with props and options

This means that the component variants in Figma either do not cover the desired case, or are named so that they cannot be deduced meaning (Variant 2, state-new). Normalize the names of variants under those adopted in the code: size, tone, state.

## Anti-Patterns That Break Everything

• Ask the agent to “fix the design on the fly”: add a state that is not in the layout. Conditions are a decision, not a layout, they are made by a person.
• Generate the entire screen and commit without a review. For the third time, you will find three different Button and two sets of tokens.
• Keep both product screens and research drafts in one file without separation. The agent will pull out the draft sooner or later.
• Use MCP as a replacement for the design system. If you don’t have a system, the agent won’t create it for you; it’ll just fix it in the code.
• Hide the code base from the agent “so as not to get confused”. On the contrary, the more it sees existing components and tokens, the less it invents.

## How to Incorporate This into Your Work

MCP is not a “developer tool” that the designer has nothing to do with. On the contrary, the quality of what an agent delivers depends 80% on the file the designer made. Therefore, to build a bundle makes sense primarily in the design routine.

### In the daily work on the layout

• Before you give the frame to the development, run it through the agent yourself. Not for the sake of code, but for the sake of verification: what the agent did not understand, the person will not understand.
• Use generation as a mirror of a design system. If an agent pulls out three different components for one button, you have three different buttons in your system, you just don’t notice them.
• Compare the generated JSX to your frame by structure. The discrepancy almost always indicates a sloppy auto-layout.

### Questions for a layout review before MCP

• If I were an agent and only saw this frame, what kind of screen would I understand?
• Are all the values here references to tokens, not local styles?
• Are all the conditions the product needs really drawn?
• Names of layers and variants - can you guess from them what it is called in the code?
• What in this file should not get into production - and is it removed?

### Segment summary

MCP does not make bad files good and does not replace the design system. It makes clear what was smeared between Figma and code: where you have order, and where agreements are only verbal. A designer who treats a frame as a contract gets a predictable code output. A designer who treats a frame as a picture gets predictable chaos — just now generated faster.

## Advanced scenarios: where MCP really pulls

The base case "frame → JSX" is just the entrance. The bundle is starting to pay off where days used to go by synchronizing design and code.

### Scenario 1: Component migration across all screens

The system has a new version of Input - with a different error state and a different icon. In Figma, this switched to a single component property. In the code - no: somewhere old markup, somewhere custom wrappers, somewhere generally copypaste.

Here the agent works not as a generator, but as a workaround. Ask him to go through the screens, find places where the old instance was used, and match them with the new version. Do not rewrite everything, but show the list and offer a patch for each case. The decision is made by you, but the discrepancy map is collected automatically.

### Scenario 2: Elevating Design Tokens from Code

The reverse problem: the repository already has variables, but Figma has a scattering of local styles. We give the agent code tokens as a source of truth and ask you to check with the frame: where the values coincide, where they do not, where in the layout there is a magical number that already has a name in the code.

At the output is the list "here should be the variable color.surface.muted, and #F4F5F7." Then it works in Figma hands, but the appearance of the problem appeared.

### Scenario 3: Analysis of the layout from the external team

A file came from a contractor or a nearby product group. The structure is foreign, the names of layers are foreign, there are no tokens of their own. Before MCP, that meant a day to "decrypt." Now, ask the agent to make a primary map: which components are used, which ones are already in our system, which are new, which duplicates existing under another name.

Not to generate immediately. In order to understand what they brought.

### Scenario 4: factual documentation

An agent can describe what he sees. If the team does not have a resource to keep a storybook with your hands, you can put it on the role of a documenter: by component in Figma, collect a list of options, states, examples of use, and fold next to the code. This will not replace thoughtful guidelines, but will close the basic layer of “what is in the system at all.”.

## How to Incorporate This into the Team Process

MCP ceases to be one person’s personal trick once you start committing the generated code. From now on, we need a contract.

### Minimum rules in the team

• The generated code goes through the same review as the hand-written code. No "well, it's from Figma, it should be OK.".
• The source of truth is fixed once and explicitly: either Figma or code. Not "how it works.".
• The names of components and props are synchronized in both directions. If the code was renamed to Figma, and vice versa.
• Larger generation (whole screens) go to separate PR rather than mixing with feature.
• If an agent gets into another part of the codebase, it's a stop signal, not "he'll figure it out.".

### Roles around the ligament

It is important to know who is responsible for what, even if the team is small.

• The designer keeps the file clean: tokens, auto-layout, names, options.
• Frontend keeps the code clean: what components are considered canonical, what props exist.
• The system designer (if any) keeps the correspondence between the two worlds.
• An agent is the fourth participant who does not have the right to vote, but has the right to ask questions through the discrepancies he highlights.

## How to check the quality of the result

The most common mistake is to evaluate the generated code according to the principle “looks like a layout – then OK”. This is the surface layer. There are three more under it, and each breaks in its own way.

### Four layers of verification

1. Visual. Does the pixel match the frame on the desired breakpoints? The simplest and the most deceptive: on this layer of bugs mask.
2. Structural. Are the actual components from the system used, rather than freshly assembled duplicates? Do the names of the props match those of the code.
3. Semantic. The button is button, the link is a, the title is h2, not three div styles. This is the one that almost always leaves first.
4. ** Behavioral.** Conditions (hover, focus, disabled, loading, error) are not drawn in Figma for free - they must be either in the layout or spoken in the task. If they don't, the agent will figure them out, and it will be a bug in the trade.

### Checklist before merge

• Is there any new hexes and pixel values in diff that already have a token.
• Is there a duplicate of the existing component under a new name.
• The states of the interactive elements are covered — not just default.
• Accessibility has not subsided: contrast, focus, semantics, alt-texts.
• The adapter is hand-tested, not "the agent said it worked.".

## How to explain the decision to the team

The Figma MCP+agent bundle sounds tech-friendly, and so it’s easy to sell it wrong – like “AI is going to be built now.” It's a bad frame: it puts the team in a defensive posture and promises savings that won't come.

It is more useful to put it this way: we reduce not the time for code, but the time for reconciling the design with the code. The bottleneck has always been not in the JSX set, but to make sure the developer understands the layout just as the designer intended it. The agent is closing that gap.

And one more honest wording for stakeholders: MCP makes a design system mandatory, not desirable. It used to be possible to live with local styles and “agreements in words”—slowly, but you can. Now any such inaccuracy instantly turns into bad code. This is not a minus of the tool, this is its main property: it does not forgive what was not worth forgiving.

### Segment summary

Advanced MCP scenarios are not “generation faster,” but the appearance of discrepancies between layout and code. The team process around the bundle is more important than the bundle itself: without an agreement on the source of truth and without an honest review, the agent simply disperses the existing chaos. Check the result on all four layers, not the picture. And sell the team not "AI writes code," but "we finally see where our design system flows.".

## Big checklist: launching a bundle in the team

If you’re just getting Figma MCP + Claude Code into the workflow, it’s easier to go through the list once than it is to deal with the consequences of PR.

### Before the first launch

• Figma allocates one file (or one page) as a source for the agent. Not “all our models”, but a specific canon.
• In this file, layers are cleaned: hidden remnants are removed, Frame 247 is renamed, duplicate components are glued together.
• The tokens are put into Figma variables rather than “laid in the file cap as examples.”.
• The code tells you where the design system lives: one package, one import path, without two parallel sets of buttons.
• We agreed which agent has the right to touch which folders. A design system folder is usually read-only for generation.

### Before every task

• The script is formulated, not “curb this frame.” What kind of screen, what states, what kind of data, what is considered a success.
• Specify which components of the system are to be used. If they are not in the system, this is a separate conversation, not a reason to breed new ones.
• Decided in advance: this is PR with a feature or PR with a new layout. Don't mix.

### Before merjah

• We went through diff eyes, not “green tests – merzhim”.
• No new hexes, pixel sizes, magic indentations.
• The hover/focus/disabled/loading/empty/error states are visible in the code, even if they were not in the layout.
• Localization is not broken: long lines do not break layout, RTL does not fall apart (if supported).
• Availability: focus styles, contrast, semantics, keyboard navigation.

## Anti-patterns that are easy to tread on

Most ligament problems are not tool bugs, but team habits that were tolerable before MCP and are now beginning to cut.

### “The agent sees the layout, why write ts”

The most expensive anti-pattern. Figma shows the final state, but it doesn’t show behavior, priorities, boundary cases, or what you keep in mind after three product calls. Without a short text next to the frame, the agent will honestly collect what is drawn and miss everything that was meant.

### One giant PR for the entire section

The temptation is clear: “let’s all onboarding at once for the evening.” No one will really read this PR review, minor discrepancies with the design system will pass, and in a month you will refactor what you yourself generated.

### Design system as a folder with examples

If Figma Button / Primary and Button / Primary 2 live nearby, the agent will poke both, sometimes in the same PR. Same in code: two sets of buttons mean two sets of bugs and a stable divergence from the layout.

### Silent token edits

The designer changes the main radius from 8 to 10 quietly. The agent honestly picks up the new value and rolls through half the components. No one noticed the decision, but everyone saw the consequences. Any edit to the token is an announcement in the channel, not a personal file.

### "The agent will deal with the legasi himself."

The old code has conventions that no one remembers. The agent is not reversing your story; he is tailoring it to what he sees from above. It is better to work with your hands or with a very narrow scope.

### Replacement of the revue with a run by Linter

Linter catches syntax, no point. The generated component can pass all the checks and at the same time duplicate the existing one, use incorrect props or break the API contract. Human eyes are still mandatory.

## Questions for a PR review from an agent

It’s helpful to keep this list open in the adjacent tab while watching diff.

• Does this component already exist in the system under a different name?
• Are all values taken from tokens, or has literature slipped somewhere?
• The names of the props match those of the code base, or did the agent come up with his own?
• Does the markup semantics match the role of the element, or is it div with onClick?
• What conditions are not covered, and why are they not in the layout?
• If you remove that PR, will something break elsewhere? Is there a hidden connection?
• Can this code be maintained without an agent, or have we just hired him in the state for good?

The last question is the most inconvenient and most useful. If the answer is “we can’t figure it out without an agent,” then the generation has gone deeper than it should.

## Practical outcome

Figma MCP + Claude Code is not a way to build faster, but a way to make visible what used to be hidden between designer and developer. A clean file turns into clean code for almost nothing. Dirty - in the dirty code, only now at such a speed that you will fix longer than you would write with your hands.

Therefore, the working strategy is simple: first order in Figma and in the design system, then an agreement within the team about the source of truth and areas of responsibility, and then an agent. In reverse, the bundle will also turn on, but it will work against you, not for you.