Figma's MCP Server Turns Your Design System Into Instructions for Agents

Your design system now has a second reader, and it does not look at pictures. In Figma's own evals, mapping components to code through Code Connect cut median agent token use by 29.5%. The Figma MCP server passes components, variables and code mappings straight to coding agents, so every gap in your system becomes a guess the agent makes on your behalf.

The short answer. To make coding agents use your design system correctly through the Figma MCP server, connect your most-used components to code with Code Connect. Bind every colour, spacing and type value to variables with code syntax, rename layers by intent and use auto layout. Then write a rules file that tells the agent which components to import and what never to hardcode.

What the Figma MCP server actually hands a coding agent

MCP, the Model Context Protocol, is the open standard that lets an agent call tools exposed by another application. The broader case for it as plumbing is covered in the analysis of MCP as an interoperability standard.

Figma launched the server in beta on 4 June 2025 as a desktop feature, then added a hosted remote endpoint on 23 September 2025. On 24 March 2026 it added a write tool, use_figma, so agents can also create and edit Figma files using your components and variables.

The read tools are the ones that matter for this argument. According to Figma's tools reference, get_design_context is the default entry point and returns code for a selection, React with Tailwind unless you ask for something else. get_variable_defs returns the variables and styles a selection uses. get_code_connect_map returns the mapping from a Figma node to a real code component, with its import path and a usage snippet.

There are also get_metadata for a sparse outline of large frames, get_screenshot for a visual reference, and on the remote server, search_design_system for finding components, variables and styles across libraries. A prompt called create_design_system_rules drafts a rules file for your repository.

Every tool returns exactly what your file contains. If a button is a detached group of rectangles called Frame 1268, that is what the agent receives.

Why your design system becomes agent input, not just guidance

A design system used to have one audience: people. Designers browsed the library, engineers read the docs site, and ambiguity got resolved in a Slack thread. People tolerate inconsistency because they can ask.

An agent cannot ask. It acts on whatever context it receives, and when that context is thin it fills the gap with something plausible. Figma's June 2025 launch post described the failure exactly. Given only a screenshot of a component, an agent will search the codebase. If it finds no match, it will likely create a new component from the image.

The same post made the token point with a red rectangle. A screenshot of red could match many tokens that share the same hex value. Figma knows which variable was applied, and if you have added code syntax to that variable, the server passes the exact code name to the model.

So the job of a design system has changed shape. It still has to be learnable by a new designer. It now also has to be unambiguous to a program that will follow it literally and at volume. This is the design-side version of the shift described in the piece on context engineering replacing prompt engineering. The quality of the output is set by the quality of the context, not the cleverness of the request.

My position is that this is good news for design system teams, and most of them have not noticed yet. The cost of a sloppy library shows up directly in token bills and in code that has to be rewritten.

What Figma's Code Connect evals actually measured

Code Connect is Figma's mapping layer between a Figma library component and the component that implements it in your repository. When a mapped component appears in a design, the MCP server includes its import path and a usage snippet. The agent is told which component to import and which props to pass.

In August 2026 Figma published the only controlled numbers available. The eval ran 27 design-to-code test cases twice, once without Code Connect and once with it, on Claude Sonnet 4.5 and Claude Opus 4.7. LLM judges scored output against reference snippets on a 1 to 4 scale covering correctness, quality, maintainability, completeness and best practices.

The medians: token use fell 29.5%, duration fell 19.6%, and code quality rose from 2 to 3. On the scale Figma used, 2 means poor and 3 means a solid implementation with minor issues. That is a meaningful step, from code you rewrite to code you review.

Coverage drove the result, not the feature

The more useful finding is buried in the method. Figma tested two React design systems. Its example Simple Design System is almost fully mapped, and Code Connect snippets made up about 20% of MCP responses. Its internal Figma Pattern Library has patchier coverage, at about 6% of responses.

Figma states plainly that coverage was the single biggest factor. In one Pattern Library task, a tab bar with buttons, the mapped run finished in about 77% of the time using about 62% of the tokens. The unmapped runs grepped through node_modules, hand-built tabs that did not work, and produced roughly 300 more lines of CSS.

Unmapped components do not only cost tokens. They produce plausible code that bypasses the system, which is exactly the debt described in the analysis of the vibe coding cleanup bill.

The Coinbase replication is smaller than its headline

In September 2026 Figma published a case study on the Coinbase Design System team. Their technical lead ran one form design, with a vague prompt, on Claude Sonnet 4.6, three times per condition in a blank codebase. Token use fell 11.5%, time to implementation 22.3% and cost 22.5%.

The qualitative result is more convincing than the percentages. Without Code Connect, agents built the Stepper component out of two progress bars and labels. With it, they picked the right Stepper and ListCell. Coinbase also reports that hallucinated icon and illustration names stopped once mappings were in place.

Coinbase moved from partial to full coverage in about four hours, using Claude Code and Figma's figma-code-connect skill to write mapping templates in parallel. The mapping work is now cheap enough that cost is no longer the excuse for skipping it.

Four structural changes design teams have to make

Figma publishes its own guidance on structuring files for the MCP server. Its line on Code Connect is blunt: it is the number one way to get consistent component reuse in code, and without it, the model is guessing. Here is that guidance turned into work a team can schedule.

Map the most-used components first

Figma's Code Connect guidance says to connect your core, most frequently used components first. That is the right order, because coverage is weighted by how often a component appears in handoff designs, not by how many components you have mapped.

Pull a usage count from your library analytics and map down the list. Buttons, inputs, list rows and layout containers will cover most screens long before you reach the long tail of specialist components.

Bind every value to a variable with code syntax

Figma's guidance is to apply variables for spacing, colour, radius and typography. The step most teams skip is code syntax. According to Figma's variables documentation, each variable can carry up to three code names, one each for Web, Android and iOS.

Without code syntax, the agent receives a Figma variable name and has to infer the code equivalent. With it, the agent receives the exact name your codebase uses. This is the cheapest change on the list and probably the highest-yield one per hour spent.

Rename layers and use auto layout

Figma recommends replacing default names like Frame1268 with intent-driven names such as CardContainer or ProductImage. The agent uses those names as structure. A layer called Group5 tells it nothing about what the element is for.

Auto layout matters for the same reason. Absolute positioning produces absolute code. Figma's own tip is to resize the frame before generating code and confirm it behaves as expected, which doubles as a quality check humans should have been running anyway.

Make Figma props match code props

Code Connect's documentation admits that design props and code props rarely match one to one, which is why property mappings exist. Mapping helpers translate a Figma variant called Primary to a code prop value of primary, or a boolean called Has Icon into an icon element.

Every translation is a place the mapping can drift. I would go further than Figma does and treat prop parity as a design system rule: same names, same variant values, same casing, in both places. Figma's eval noted that its Simple Design System was an easier case for an LLM precisely because names already matched between design and code.

Nested instances need care too. The docs say figma.children matches by layer name, which must stay identical across variants or use a wildcard. Icons should be exposed as instance-swap properties, and you should connect the backing icon component rather than the instance.

Design tokens for AI agents: modes, aliases and the DTCG standard

Design tokens are the named values, such as colour, spacing and type, that a system reuses everywhere. For agents, the hard part is not the base value. It is the context: light mode against dark mode, brand A against brand B, compact against comfortable density.

Here Figma's documentation is thin. The tools reference describes get_variable_defs as returning the variables and styles in a selection, and its troubleshooting page says nothing about variable modes. Community reports suggest the tool may surface only default mode values. I could not confirm that against Figma's own docs, so test it on your file before relying on the agent to choose a theme value.

The W3C Design Tokens Community Group published the first stable version of its specification, numbered 2025.10, on 28 October 2025. It defines a JSON format with $value and $type, aliases between tokens, and a separate resolver module for themes such as light and dark mode. It is a community group report, not a W3C standard.

My recommendation is to keep the canonical source of your tokens in code, in DTCG format, and treat Figma variables as a synchronised view of it. The agent will read your repository as well as your Figma file. If the two disagree, the repository is what ships, so it should be the source of truth. Figma does not appear to offer native DTCG import and export, so that sync currently runs through plugins or the Variables API.

Rules files: the written layer your design system never had

A rules file is a markdown file in your repository, such as CLAUDE.md, that agents read before they act. Figma's custom rules guidance says these should capture a codebase's unwritten rules: which layout primitives to use, where component files belong, how components are named, and what should never be hardcoded.

The suggested rules are specific. Always use components from your design system path when possible. Avoid hardcoded values and use design tokens from Figma. Follow WCAG accessibility requirements. Do not add new icon packages, because every asset should come from the Figma payload.

The most important line in that guidance tells the agent to treat Figma's React and Tailwind output as a representation of design and behaviour, not as final code style. Without it, an agent working in a Vue or SwiftUI codebase can paste Tailwind classes into a project that does not use Tailwind.

Figma also recommends a fixed tool order. Call get_design_context first, fall back to get_metadata for oversized frames, take a screenshot, download assets, translate to project conventions, then check against Figma for visual parity. Write that order into the file.

On 6 October 2026 Figma added library guidelines, markdown rules and antipatterns attached to a library that its own agent reads on every prompt. That is the same idea moving into the design file. The consequence is that your design system documentation now lives in two machine-read places, and keeping them consistent is a new job someone has to own.

Seats, plans and rate limits decide who can use the Figma MCP server

The commercial gate is easy to miss in the launch posts. Code Connect is available only on a Dev or Full seat on Organization and Enterprise plans. The MCP server itself works more widely, but Figma's rate limits page caps read tool calls by seat and plan.

View and Collab seats are capped at up to 20 calls a month on every plan. Write tools such as add_code_connect_map are exempt from these limits. Figma reserves the right to change them.

Two hundred calls a day sounds generous until you remember that one implementation task can make several calls: context, metadata, screenshot, variables and assets. A developer building a full screen in sections could plausibly spend a meaningful share of that budget in an afternoon.

The write side has its own pricing question. Figma said in March 2026 that writing to the canvas will eventually become a usage-based paid feature, free during the beta. Teams already tracking AI credits across design tools, as set out in the comparison of credit pricing in AI design tools, should add this line to the forecast now.

Connecting a design file to an agent is also a supply-chain decision. Figma says only clients in its MCP catalog can connect to the remote server, and access follows your existing file permissions. That is a sensible baseline, and the wider risks of granting agents MCP access are covered in the analysis of MCP server supply-chain risk.

Where this argument is weakest

The case above rests on less evidence than its confidence suggests.

Every number comes from the vendor

Both performance tests were published by Figma, which sells the seats Code Connect requires. The main eval has 27 cases, unstated run counts, and LLM judges rather than human reviewers. The Coinbase test is three runs on one design. Neither publishes variance or per-model results, and the two disagree on token savings by more than a factor of two.

None of that makes the numbers false. It makes them a vendor's directional claim, and the honest reading is that time savings near 20% look plausible while the token figure is not yet settled.

The gain may shrink as agents get better at reading code

Much of what Code Connect provides is an import path and a usage example. An agent can also find those in a well-organised repository with good component docs and a clear rules file. Coinbase itself kept its own agent skills for component choice and token use alongside Code Connect.

A team with a disciplined codebase on a Professional plan may get most of the benefit from rules files and naming discipline alone. That would be a cheaper path, and nothing published so far rules it out.

Two sources of truth is a liability

Mappings, variables, rules files and now library guidelines all describe the same system. Each one can drift from the code. Figma's own advice is to keep mappings up to date, which is advice that only matters because they go stale. A stale mapping may do more damage than no mapping, because the agent trusts it.

I still think the structural work is worth doing, because almost all of it, intent names, variables, auto layout and prop parity, improves the system for people too. The Figma-specific parts are the ones I would hold to a measured test.

Frequently asked questions

How to make your design system agent-ready this month

Start with a test, not a migration. Pick one real screen your team is about to build. Run it through the Figma MCP server as your library stands today, then record tokens, time and how many components the agent rebuilt instead of importing. That is your baseline.

Then fix the cheapest gaps first: code syntax on every variable, intent names on the components in that screen, and a one-page rules file. Rerun the same screen. If you are on an Organization or Enterprise plan, map the ten most-used components with Code Connect and run it a third time. The difference between the three runs is the business case, measured on your own system.

Related reading