Figma's Dev Mode MCP Server: how to configure access without leaking the design system

The problem every product team knows: the design is ready in Figma, but the translation into code goes through manual inspection of spacing, colors, token names, and components. Each developer interprets the file differently, and the result drifts away from the design system. Figma's Dev Mode MCP Server tackles exactly this point by letting an AI agent read the design file directly from inside the code editor, instead of the developer translating everything by hand.

According to Figma's official documentation, the server uses the Model Context Protocol (MCP), the same standard that tools like Claude, Cursor, and VS Code have adopted to connect agents to data sources. In practice, Figma stops being an image the developer looks at in another tab and becomes a structured source that the model queries: variables, components, layout, and layer hierarchy reach the LLM's context.

What the server actually delivers

Figma's MCP Server isn't just about "generating code from a screenshot." It exposes a set of capabilities worth separating, because each one changes a different step of the workflow:

• Generate code from selected frames. You select a frame in Figma and ask the MCP client to turn it into code. It's the most direct use case for anyone building a new screen.
• Extract design context. Variables, components, and layout data enter the IDE. This is where the value for design systems lies: the agent reads the actual tokens, not hardcoded values it guessed.
• Write to the canvas. With the remote server, the agent creates and modifies native Figma content (frames, components, variables, auto layout) using the design system as the source of truth.
• Capture live UI. You can take the rendered interface of an application (production, staging, or localhost) and bring it back into Figma as editable layers.
• Pull resources from FigJam and Make files. Flows, diagrams, and prototypes become context for code generation.

Access to a specific node is link-based. The path described in the documentation is simple: select the layer in Figma, use Copy link to selection, and paste that URL into the MCP client. The agent doesn't navigate to the URL; it extracts the node ID embedded in the link, and that identifier is what tells the server which object to return. It's worth understanding this detail because it defines the grain of access: the agent sees what you point to, not the entire file by default.

Remote or desktop, and why the choice matters

There are two connection modes, and the difference has a direct impact on governance.

| Aspect | Remote server (preferred) | Desktop server | |---|---|---| | Where it runs | Figma's hosted endpoint (https://mcp.figma.com/mcp) | Locally, via Figma's desktop app | | Availability | All seats and plans | Dev or Full seat on paid plans | | Write to canvas | Yes | No | | Capture live UI | Yes | No | | Typical use | Broader set of features | Specific cases for organizations and enterprises |

The documentation recommends the remote server as the default because it has more features. But for teams with restrictive policies on external traffic, the desktop server is what keeps processing on the developer's machine, at the cost of losing canvas writing and UI capture. This is the first governance decision a Brazilian team needs to make before enabling anything: where the file's content is allowed to travel.

Another point in the official text worth noting: the feature is in beta and free for now, but Figma warns that it will move to usage-based billing. In other words, whoever designs the workflow today needs to account for the cost entering the bill later, and size who actually needs access.

Skills: reducing the agent's improvisation

The server exposes individual tools, but a loose tool doesn't guarantee a good result. That's where Skills come in, agent-level instructions that guide which tool to use, in what order, and how to apply the result. The documentation cites workflows that Skills package:

• Connecting design components to code components via Code Connect.
• Generating design system rules aligned with the codebase.
• Translating designs into production-ready code.

Skills don't add new capability or replace the MCP connection; they reduce setup and guesswork. They're available per client (Claude Code, Codex, Cursor, VS Code, among others), through the Figma Community, and through contributions to the community-resources repository on GitHub.

The piece that closes the loop on fidelity to the design system is Code Connect. Without it, the agent generates markup that looks like the component. With it, the generated code reuses the actual components from your codebase, the generated button is your , not a styled div that mimics a button. For anyone maintaining a shared library, this difference is what separates disposable code from code that gets merged into the repository.

Governance: access is part of the definition of done

The angle that matters most to product leaders in Brazil isn't the flashy demo, but who can read what. Some practical takeaways from what the documentation establishes:

Access follows Figma's permissions. The agent acts under the connected account. If a developer has access to a file with proprietary components, the agent has it too. File and project permission rules remain your first barrier, not something MCP solves on its own.

Writing to the canvas is write power. Enabling the remote server means the agent can create and change frames, variables, and components. In a shared design system, this calls for care: a poorly calibrated prompt can mess with a library that several teams consume. Restricting writing to working files, rather than to published libraries, is a sensible safeguard.

Live UI capture crosses the production/design boundary. The feature of sending the production or staging interface back to Figma is powerful for alignment, but moves real screens (possibly with data) into the design environment. It's worth defining whether localhost is the only environment allowed in this flow.

The path that makes sense for a team is to start with the remote server with access restricted to a subset of files, validate the quality of the generated code with Code Connect turned on, and only then expand. None of this is automated: the documentation provides the tools and per-client instructions, but the policy of who accesses which file is the team's decision.

What remains open

The documentation is a high-level overview and points to specific articles for instructions and prompt examples (Claude Code, Codex, Cursor, Gemini CLI, VS Code, and Xcode each have their own guides). What it doesn't resolve, and what each team needs to measure, is the actual fidelity of the generated code on complex components, behavior on large files, and the cost once the beta turns into usage-based billing.

For UX and design, the concrete gain is reducing the manual translation that always degraded consistency between design and implementation. But the same old lesson still holds: accessibility, semantic tokens, and component naming need to be correct in the file, because the agent will reproduce whatever it finds, including the mistakes. Design that was already well-argued and well-structured becomes better code; a messy file becomes messy code faster.