Figma Dev Mode MCP Server lets AI agents read specs straight from the code editor

From manual inspection to automatic context

Until recently, the path between the design file and the code was manual: the product team would open Figma's Dev Mode, copy spacing and color values from the inspection panel, take a screenshot of the component, and paste it all into a Jira card or a Slack message for the engineering team to replicate by hand. The Figma Dev Mode MCP Server, described in Figma's official Developer Docs guide, proposes a different route: the AI agent that already lives inside the code editor talks directly to the Figma file and pulls variables, components, and layout data without going through that visual intermediary.

The mechanism behind this is the Model Context Protocol (MCP), an open standard that lets an AI agent connect to external data sources in a structured way. Figma's MCP server is available to accounts on the Starter, Professional, Education, Organization, Government, and Enterprise plans, as long as the MCP client used (Cursor, Claude Code, VS Code with Copilot, Claude Desktop, Amazon Q, Gemini CLI, among others) appears on the official list of supported clients.

Two ways to connect the server: cloud or desktop

There are two ways to connect the editor to Figma, and the choice between them isn't just technical, it's also about data governance:

• Remote server (recommended by Figma itself): connects directly to the endpoint hosted at mcp.figma.com/mcp, without needing the Figma desktop app installed. It offers the broadest set of features, including writing to the canvas and generating design from the live UI of a website.
• Desktop server: runs locally through the Figma desktop app and requires a Dev or Full seat on a paid plan. It's aimed at specific organization and enterprise needs, and it's the only option for those using Figma for Government, which doesn't support the remote server.

This split matters because the remote server sends design file data out of the team's network to Figma's endpoint, while the desktop version keeps everything local. Teams with strict data policies, typical of the public sector or regulated industries, end up restricted to precisely the option with fewer features.

What the agent can pull from Figma

In practice, the flow starts in the file itself: the designer right-clicks the frame or layer and selects "Copy link to selection." That link is pasted into the conversation with the agent, which doesn't open the URL directly, but extracts the node ID from it and uses the MCP server to fetch the context for that specific object. From there, according to the documentation, the agent can:

1. Generate code from a selected frame, useful when the team is building a new flow or iterating on an existing feature.
2. Extract pure design context, variables, components, and layout data, aimed specifically at design system workflows.
3. Retrieve FigJam diagram assets, carrying flows and architecture maps from an early ideation phase into development.
4. Pull assets from Make files, serving as a bridge between prototype and production.
5. Turn the live UI of an app (in production, staging, or localhost) into editable layers back in Figma, a feature that requires the remote server and is only supported by select clients.

In short: the server doesn't deliver a single isolated feature, but a context router that shapes itself differently depending on what question the agent is trying to answer, and which side of the bridge (design to code, or code to design) the task sits on.

Writing back to the canvas: convenience with a bill coming due

The most ambitious feature on the list is letting the agent create and update native content in Figma Design, FigJam, and Figma Slides, building frames, components, variables, and auto layout using the team's design system as the source of truth. The documentation is upfront about the cost of this: writing outside your own drafts requires the remote server and a Full seat, and the feature is free only during the beta period, with the explicit caveat that it "eventually" becomes a paid, usage-based feature.

This changes the adoption calculus. A team can test it today at no extra cost and later discover that the workflow it folded into its design routine carries a variable price tag that Figma hasn't yet disclosed in numbers. It's worth treating the feature as a pilot, not as a permanent part of the process, until the final pricing is clear.

Code Connect is what keeps you from getting a generic component

An obvious risk of generating code from a frame is the agent inventing new markup instead of reusing the React, Vue, or Swift component the team already maintains. This is where Code Connect comes in: it maps Figma components to the actual components in the source code, so that code generation reuses the existing implementation instead of recreating a <div> from scratch. Without that mapping configured, the agent's output tends to be structurally similar to the design but technically out of step with the design system, which ultimately creates more review work than it saves.

Figma also offers "skills," instruction packages that combine MCP tool calls with a workflow script, covering tasks such as connecting components to Code Connect, generating design system rules aligned with the code, or translating screens into production-ready code. Skills don't add new capability to the protocol: they cut down on the trial-and-error work of figuring out which tool to call, and in what order.

The accessibility blind spot

Variables, components, and layout data answer questions about spacing, color, and visual hierarchy well, but nothing in the documentation indicates that this context covers metadata such as accessibility semantic roles, focus order, or image alt text. In practice, this suggests that an agent generating HTML from this context risks producing markup that's visually faithful but semantically poor, unless someone on the team explicitly writes that requirement into the prompt or into a dedicated skill.

Design is argument: every interface choice carries a reason that needs to survive translation into code, including the part the eye doesn't see in Figma.

The figma-spec feature, still in open beta, helps with this by letting the agent read and update the team's specs before starting to build, capturing decisions and findings back into the spec as the work progresses. Teams that already document accessibility requirements in these specs gain a channel for the agent to at least know the requirement exists; those who don't document it keep depending on manual human review after the code ships.

When it's worth turning on MCP, and when it isn't

The gain is clearest for teams that already maintain a mature design system with Code Connect configured: there, pulling context directly from Figma cuts the time spent manually copying token values and reduces drift between what the designer drew and what the engineer implemented. For small projects without a shared component library, the payoff is smaller, because the agent has nothing to reuse and ends up generating code from scratch either way, with or without MCP.

Organizations under Figma for Government are limited to the desktop server, with more restricted tooling. Teams concerned about where their design file content travels would do well to check Figma's data policy for that endpoint before turning on the remote server, since it leaves the local network by definition.