Figma MCP design system prep for AI agents

In March, Figma opened the canvas to agents. Its launch post says the use_figma tool works with your components and variables, and that auto layout, components and variables are the structures agents operate on. Claude Code, Codex, Cursor, Copilot and others can connect.

The same post gives no guidance on preparing a file. It points to the help center and developer docs for the rest. Figma's MCP server FAQ fills in some practical limits. You need a Full seat to write outside your drafts. Fonts must be uploaded to your Figma account. Components must be published before Code Connect mappings can be completed. And the output "is beta quality and may need manual review and cleanup."

That last line matters most. Figma is telling you the agent is a fast first pass, not a finished one. How much cleanup you face depends on inputs you control.

On October 29, Figma's VP of engineering described the model behind the agent in How we're training a Figma-fluent editing model. The post is candid about one thing worth repeating. Post-training improves the model's part of a larger system that also includes canvas context, design system context and tools. Two of those three are your files. A better model does not rescue a messy library.

Bitovi ran the agent against real components and wrote up the result in Figma just opened the canvas to agents. The good news first. From an existing Button, the agent produced a component set with correct variants, styles and clean layer names.

The agent "doesn't pick up on a linked design system unless you tell it to. Every time." It used plain frames for some components while using real library components for others. Left to defaults, it hardcoded colors, spacing and type. Bitovi's summary is the line I would put on a wall: the agent optimizes for the literal goal you gave it, not the implicit standards in your head.

Hardcoded values are not a model flaw you wait out. A designer who never opened the variables panel produces the same output. The agent is a very literal junior, so every gap in your system gets reproduced, quickly.

Treat one test with care. Bitovi's piece is one team's experience, and output varies between runs. The pattern is useful. No one has published a failure rate.

Practitioner guides, such as the Figma file best practices in the camoa dev guides and a uxdesign.cc practical guide, agree on the problems. They are blog advice, not Figma documentation, so read them as heuristics. I rank them by cost.

Hardcoded fills and spacing. If a button's fill is a hex value instead of a variable, the agent has nothing to bind to and copies the hex. Bind every fill, stroke, radius and gap to a variable first. This single fix removes the failure Bitovi saw most clearly.

Primitives and semantic tokens matter here. A variable named blue-500 tells the agent a color. A variable named action-primary tells it a purpose. Agents choose by purpose when you ask for "a primary action", so semantic names carry the instruction.

Generic layer names come next. "Frame 234" and "Group 1" give the agent no hint about what a thing is, and the code it produces inherits the vagueness. Name layers the way an engineer would name a component, and match component and property names to your code (a "Style" property in Figma against a "variant" prop in code is enough to break mapping).

Then structure. Agents read auto layout as intent. If a card has fixed positions instead of padding, gap and direction, the agent cannot tell what should grow and what should wrap. Guides also warn against nesting auto layout very deeply, though I have not seen a measured threshold, so treat any specific number as folklore.

Finally, missing descriptions. Guides report that component descriptions reach the agent as context. A two-line note on a star rating component, saying what its states mean and when not to use it, costs nothing and is read every time.

Figma's answer to inconsistency is skills, which are markdown files that spell out workflow steps, sequencing and conventions. The foundational /figma-use skill teaches the agent how the tool works, and teams can add their own. Figma says skills make output more predictable because the same prompt can yield different results from a non-deterministic model.

Read that as a statement about where your effort belongs. A prompt lives for one request. A skill lives for every request after it. Bitovi's suggested directives show the right grain. Check for a linked design system before generating anything, and use variables for color and spacing.

This is the logic behind approval UX for agents. You cannot review every action at agent speed, so judgment moves into rules written in advance.

My first skill would be short. Name the library to use and require the agent to load it before drawing anything. State that every color, space and radius comes from a variable, and that a missing token should be reported, not invented. Say which components to use for buttons, inputs and cards, and that plain frames are never acceptable as stand-ins. Describe the naming pattern for new layers. End with what to report: any value the agent could not bind, and any component it had to build.

An agent that lists its own exceptions turns cleanup from a hunt into a checklist.

Figma's own numbers show real progress. Typical tasks are about 20% faster than in beta. Against expert designers in head-to-head testing, the new agent beats or matches the previous production agent 62% of the time. User ratings are 33% higher and users undo the agent's work 60% less often.

Those are Figma's internal results, measured on its own tasks, and the post itself says one evaluation is only one input among many. They show the model improving. They do not show your library behaving.

The post also names errors that remain, such as overlapping icons and text and clipped arrows. These are visual faults that structure alone will not prevent. They are why Figma's agent takes a screenshot of its own output and iterates on mismatches, and why you should still look at what it makes.

A better model helps everyone equally. An agent-ready file helps only you, and it makes each model upgrade mean less cleanup.

Do this on a duplicate of your library, as Figma recommends, never on the live file.

On day one, audit variables. Find every fill, stroke, radius and spacing value in your core components that is not bound to a variable. Start with the 20 most used components.

On day two, rename. Replace generic layer names in those components, and align component and property names with the code names your engineers use.

On day three, check auto layout in your cards, forms and navigation. Every container should express direction, gap and padding rather than fixed positions.

On day four, add descriptions to components that have states or usage rules. Keep each to two or three lines.

On day five, write your first skill using the template above and run five fixed prompts against the duplicate, such as a settings page, a card variant, a form with errors, an empty state and a mobile screen. Record how many values were hardcoded and how many components were faked with frames. Run the same five after any change to the skill.

That count is your metric. If you already test your system visually, the method in AI agent visual regression testing for design systems pairs well with it, since it catches the clipped and overlapping output Figma admits still happens.

If the first week shows twenty hardcoded values, you have learned something real about your library, and you learned it before the agent shipped the same flaws into a product. That is the point. The agent is a mirror, and it is more honest than a design review.