Figma Dev Mode MCP Server teaches AI agents to read design variables and components

Figma published a consolidated guide in its Help Center about the Dev Mode MCP Server, the Model Context Protocol implementation that connects design files directly to AI clients such as Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, and Codex. The central proposition, according to the guide itself, is simple to state and hard to ignore: instead of an agent generating an interface from a text description or a screenshot pasted into the prompt, it reads variables, components, auto layout, and layout specs directly from the source of truth that the design team already maintains.

This solves a familiar problem for anyone working at the bridge between design and engineering: AI-generated code that "looks like" the design but uses arbitrary spacing, off-token color, or reinvents a component that already exists in the design system. The MCP server tackles this by giving the agent structured access to the Figma file, not just a visual one.

Remote or desktop: two gateways to the same protocol

Figma's guide details two ways to connect the server. The remote option, Figma's own preference, points to the endpoint hosted at https://mcp.figma.com/mcp and is available on any seat and plan, including the free one. The desktop option, which runs locally through the Figma app, requires a Dev or Full seat on paid plans and is recommended mainly for specific cases involving organizations and enterprises; for the broadest set of features, the guide itself recommends using the remote option.

The difference isn't just about access: some features, such as writing directly to the Figma Design and FigJam canvas or capturing the live UI of an app running in production, staging, or localhost and turning it into editable layers, only work through the remote server, and even then only in selected clients. Figma also makes it explicit that both capabilities are still in free beta and are expected to become a pay-per-use feature in the future.

What the agent can actually do

With the server connected, the MCP client gains a set of tools that go beyond just "looking" at the design:

• Extract design context: variables, components, and layout data straight into the code editor, something the guide points out as especially useful for design-system and component-based workflows.
• Generate code from a selected frame, useful when a product team is iterating on a specific flow rather than the entire file.
• Pull resources from FigJam, incorporating flows, architecture maps, and early-stage ideas into the development process.
• Pull resources from Figma Make files, helping with the transition from prototype to production application.
• Maintain consistency with Code Connect, reusing real components from the codebase instead of having the agent reinvent a button or input that already exists in the base.
• Use fonts loaded into the account, both through the MCP server and through Figma Agent.

The compatibility table published in the guide shows who supports what: Cursor, Claude Code, Claude Desktop, VS Code, Codex, Kiro, Xcode (beta), Copilot CLI, Warp, Augment Code, Factory, and Firebender all show support for the remote server and canvas writing; Amazon Q, Android Studio, Gemini CLI, and Openhands have more limited support, without canvas writing; Replit only supports the remote server. It's a matrix worth checking before deciding where to invest configuration time, because the experience changes considerably between a client with "write to canvas" and one that only reads context.

Skills: the script that keeps the agent from "guessing" the right tool

One point the guide handles carefully is the difference between the MCP server exposing individual tools and the agent knowing how to use them in the right order. That's what Skills are for: instruction packages that guide the agent on which tool call to use, in what sequence, and how to apply the result. The guide cites three skill-guided flows as examples: connecting design components to code components via Code Connect, generating design-system rules aligned with the codebase, and translating designs into production-ready code.

The important detail, which Figma itself makes a point of clarifying, is that skills don't add new capability to the MCP or replace the connection: they only reduce configuration work and the agent's "guesswork." There are also community-contributed skills, available on Figma Community and in the community-resources repository on GitHub.

Two practical flows described in the guide

The first is link-based. To get design context, the flow is: select the layer in Figma Design, right-click and choose "Copy link to selection," paste that URL into the MCP client, and ask it to implement the design. The guide is explicit about a technical detail that avoids confusion: the client doesn't actually navigate to the selected URL, it extracts the node ID contained in the link, which is the identifier the MCP server uses to know which object in the file to return information about.

The second flow is the reverse: sending the app's live UI to Figma. It works through conversation with the MCP client, currently available only via the remote server and in specific clients. The user asks for something like "start a local server for my app and capture the UI in a new Figma file," follows the steps the client offers (which opens a browser window or provides a link), uses the capture bar to record the app's pages, elements, and states, and at the end receives from the client itself a link to the generated Figma file with those editable layers.

Where human UX review remains mandatory

Figma's guide is honest about its scope: it describes context extraction, code generation, and component synchronization, not usability evaluation. An agent that reads variables and layout specs faithfully reproduces what's drawn, including an accessibility problem that was already in the file, such as insufficient contrast, a confusing focus order, or a missing label on an interactive state. Nothing in the MCP server validates whether that frame passes a WCAG criterion, whether the flow makes sense to a screen reader, or whether the component reused via Code Connect is still the right choice for that use context.

In other words: the server shortens the distance between design and code, but doesn't replace the judgment of those who understand the reasoning behind each interface decision. It's a tool for implementation fidelity, not experience quality: UX review, especially around accessibility and edge cases not drawn in the selected frame, remains human work.