Figma's Dev Mode MCP Server exposes tokens and components to agents like Claude and Cursor

Figma's official Help Center guide for the Dev Mode MCP Server formalizes something that changes the logic of the handoff between design and code: instead of the developer opening Figma, looking at the frame, and manually translating it into components, an AI agent (Claude, Cursor, Copilot CLI, among others) reads the variables, tokens, and structure of the design file directly.

The protocol behind this is the Model Context Protocol (MCP), an open standard for connecting AI agents to data sources. Figma has implemented its own MCP server to expose the content of Figma Design, FigJam, and Figma Slides files to any compatible MCP client.

In practice, context extraction is link-based. The flow described in the guide is simple: the designer right-clicks the frame or layer, chooses "Copy link to selection," and pastes that link into the MCP client (the code editor or the agent). The client doesn't open the link; it extracts the node ID that the MCP server uses to identify which object to return. From there, the agent receives variables, components, and layout data ready to become a code-generation prompt.

Two connection paths, with different seats

Figma offers two ways to connect the MCP server to an editor, and the choice isn't just technical: it changes who on the team can use what.

The guide is direct in recommending the remote option for most cases, reserving the desktop option for specific organization or enterprise needs. One relevant exception: Figma for Government only supports the desktop server, which limits access to the newest features for those on that plan.

The handoff becomes a two-way street

Up to this point, the agent reading the file would already be significant news for anyone who suffers with outdated design documentation. But the Dev Mode MCP Server also allows the reverse path: the agent writes directly to the Figma canvas. With the right skills, it can create and update frames, components, variables, and auto layout using the existing design system as the source of truth, instead of drawing from scratch.

This write feature requires the remote server and a Full seat to write outside of personal drafts. It's in beta, free for now, and the guide itself warns that it will become a pay-per-use feature. For design system teams, this means planning governance now: who has a seat to let an agent touch published components, and how to review what it produced before propagating it to all of the library's consumers.

Another documented writing direction is live UI capture. The flow works like this:

1. The user asks the MCP client to start a local server for the application and capture the UI in a new Figma file.
2. The client opens a browser window or provides a link to follow the steps.
3. A capture toolbar allows recording pages, elements, and states of the application (production, staging, or localhost).
4. After being told it's done, the client returns the link to the new Figma file with editable layers.

This is useful for visually auditing an interface already in production, something that historically required screenshots, a ruler, and patience.

Code Connect and Figma Specs: what keeps the agent from hallucinating components

Two features mentioned in the guide address a legitimate fear for anyone who maintains a design system: that the agent generates code that looks good but is inconsistent with what already exists in the repository. Code Connect solves this by linking Figma components to the actual components in the code, so that generation reuses what's already implemented instead of reinventing a button that's similar but different.

Figma Specs, accessed through the figma-spec skill, tackles another point of friction: product context before the agent starts coding. In open beta, it lets the agent read, create, and update the team's specs, so that requirements are shared before implementation and decisions made during the work are captured back into the spec. Writing to a spec also requires the remote server and edit access to the file.

What this changes for design systems and accessibility

Here's the point that matters more to whoever designs than to whoever just codes: if the agent reads variables and tokens from Figma to generate code, the design system stops being reference documentation and becomes a direct production input. In my reading, this raises the bar on how variables are named and organized, because an ambiguous token name doesn't just confuse a designer who's new to the team, it also confuses the agent that will translate that token into CSS or component props.

The same reasoning applies to accessibility. If a button's color pair isn't modeled as a semantic variable (something like color/text/on-primary instead of a loose hex value), the agent has no way of knowing that contrast needs to comply with WCAG. Spacing tokens, focus state, and icon alt text only make it into the generated code if they're already encoded as part of the design system, not as a tacit convention living in the designer's head. The MCP Server doesn't create this discipline; it just makes the cost of not having it visible, quickly.

Where it still isn't worth it

For teams without a mature design system, with inconsistent variables or duplicated components, context extraction tends to hand that exact mess back to the agent, which will generate code just as inconsistent as the source file. The canvas-writing feature, free today, has a set date to become pay-per-use, which could weigh down the adoption calculus for large teams before they even measure any productivity gain. And organizations on Figma for Government remain limited to the desktop server, without access to the broader set of remote-server features described in the guide.