Figma's Dev Mode MCP Server: what AI sees in your file (and what it misses)
Figma's official guide details which nodes, variables, and components the Dev Mode MCP Server exposes to AI agents. The list also shows, by omission, what a poorly organized file will never deliver.
Figma's official guide details which nodes, variables, and components the Dev Mode MCP Server exposes to AI agents. The list also shows, by omission, what a poorly organized file will never deliver.
Figma's Dev Mode MCP Server is in open beta, free to use while this phase lasts (it will become a pay-per-use feature later on, according to the Figma Help Center). It connects tools like VS Code, Cursor, Windsurf, Claude Code, and Codex directly to a Figma file via the Model Context Protocol. The promise is simple to state and hard to guarantee: the agent reads the design and writes code that matches what was drawn.
The problem is that "reading the design" isn't a magic operation. The server exposes a specific, documented set of data, node by node. Whoever organizes the file thinking only about how it looks on screen, without thinking about what this protocol can extract, will get generic code back, no matter how expensive the AI model on the other end is.
How the agent reaches your design
Context extraction is link-based, not a free search across the entire file. The flow documented by Figma is this:
- Select the desired layer or frame in Figma Design;
- Right-click and choose Copy link to selection;
- Paste that URL into the MCP client (the code editor) and ask it to implement.
The client doesn't open the URL like a browser would. It extracts the node ID embedded in the link, and that ID is what the server uses to identify exactly which object to return. In practice, this means the agent never "looks at the whole file": it sees the selected node and whatever is structurally linked to it.
What goes into the response: variables, components, auto layout
The guide explicitly lists what the design context extraction tool brings into the editor: variables, components, and layout data. That's the phrase the Figma Help Center itself uses to describe this function: especially useful for design systems and component-based workflows.
In short: the agent doesn't infer semantics from pixels, it reads metadata. Figma's documentation confirms that variables, components, and layout data are extracted directly into the editor; there's no public detail on how each variable type is named or referenced in the final generated code. In practice, this suggests that keeping a well-named variable system gives the agent more structured context than fixed color or spacing values, even without documented guarantees of how that context translates into the delivered code.
The same goes for auto layout: Figma's documentation confirms that layout data is extracted along with variables and components. A frame with auto layout configured carries structural information (spacing, direction, distribution) that, in theory, gives the agent more context; a manually positioned frame, without auto layout, carries less structural information, just absolute coordinates.
Code Connect decides whether AI recognizes or reinvents the component
There's a gap between "the AI saw a button" and "the AI knows that button is the Button that already exists in the team's design system". That's exactly where Code Connect comes in, cited in the guide as part of the toolset: according to the Figma Help Center, it exists to "improve generation quality by reusing your real components", keeping the generated code consistent with the team's codebase, instead of recreating a button from scratch with loose CSS classes.
Without this reuse, the server still extracts properties from the Figma component, but the agent has no guarantee that the generated code will match the actual component in the repository. The result in these cases tends to be structurally correct, yet disconnected from the real source code: plausible HTML and CSS, unrelated to what the team already maintains.
Remote or desktop: the choice changes what's available
Figma offers two ways to connect the server, and they aren't equivalent in features or in who can use them.
| Feature | Remote server | Desktop server |
|---|---|---|
| Endpoint | https://mcp.figma.com/mcp | Runs locally, via the Figma desktop app |
| Who can use it | All seats and plans | Dev or Full seat, on paid plans |
| Write to canvas | Supported | Not supported |
| Capture live UI (browser) | Supported (select clients) | Not supported |
| Figma's recommendation | Preferred, broader feature set | Specific cases for organizations and enterprises |
The most relevant difference for handoff is writing to canvas: only the remote server lets the agent create or modify frames, components, variables, and auto layout directly in the Figma file, using the design system as the source of truth. It's a two-way feature that changes the traditional handoff flow: code can also feed back into the design, not just the other way around.
What the guide doesn't list, and why it matters for accessibility
Going through the list of features documented by Figma (write to canvas, generate design from live UI, generate code from selected frames, extract design context, FigJam features, Make features, Code Connect), there's no mention of alt text, ARIA roles, or screen reader reading order as extracted data.
This doesn't mean the feature doesn't exist or won't exist: it's a reading of what's documented today, not a limitation confirmed by the maker. But for those who treat accessibility as part of their definition of done, it's worth treating this as a gap until Figma says otherwise: naming layers descriptively and documenting interactive states remains manual work, because there's no evidence the server infers this on its own from the frame's visual structure.
A practical checklist for organizing the file with the agent in mind
Based on what the guide confirms about what gets extracted, it's possible to put together an objective checklist before pointing an agent at a Figma file:
- Replace fixed color, spacing, and typography values with named variables, whenever the design system allows it;
- Apply auto layout to frames that represent real interface components, not just presentation artboards;
- Connect Figma components to code components via Code Connect, especially the most reused ones in the design system;
- Name layers by the role they play in the interface (
button/primary/large), not by visual description (blue rectangle); - Use Copy link to selection on the most specific node possible, instead of pointing to the whole page, to reduce ambiguity in the agent's response.
None of these items is new in terms of design system best practices. What changes is the consequence of ignoring them: before, a poorly organized file cost human rework at handoff. Now, according to Figma itself, it also produces worse code, because the protocol simply has nothing to extract beyond what's structured.
For whom it's not worth it yet
The desktop server requires a Dev or Full seat on paid plans, but that doesn't limit write-to-canvas: that feature depends on the remote server, which the Figma Help Center describes as available across all seats and plans. The real access limitation falls on specific organization cases that need the desktop server, not on writing to canvas itself. And legacy files, full of fixed values and layers without consistent naming, don't become AI-ready just because someone installed the MCP server: reorganizing the file remains a prerequisite, not a consequence of the tool.
Source: Guide to the Dev Mode MCP Server, Figma Help Center (https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Dev-Mode-MCP-Server).
Translated from the Brazilian Portuguese original · Read the original
Figma's Dev Mode MCP Server becomes a direct bridge between design and code, no screenshots or redlines needed
With Figma's MCP server, AI agents read variables, components, and layout directly from the design file, without needing screenshots, redlines, or manual specs. But this only works if the design system is named with discipline.