Figma's Dev Mode MCP Server turns design files into a contract for coding agents

What the Dev Mode MCP Server is

The Dev Mode MCP Server is Figma's official way to expose design files to AI agents through the Model Context Protocol (MCP), the standard that gives structured context to LLMs. The Figma Developers documentation describes two ways to run the server: a remote one, hosted at https://mcp.figma.com/mcp, and a desktop one, run locally through the Figma app itself. Today the feature is in beta and available at no cost, but the documentation itself warns that it will become a pay-per-use feature.

Code clients like VS Code, Cursor, Windsurf, Claude Code, and Codex by OpenAI (the latter via Codex Skills) already connect to the server, each with its own installation steps. The logic is the same across all of them: the agent starts to see the Figma file as a source of context before generating or changing any code, instead of relying only on a screenshot or a text description.

Remote or desktop: the choice changes what you can do

The documentation is explicit about the access differences between the two modes, and that matters for whoever has to decide which seat and which workflow the team needs:

In practice, anyone who wants the full set of tools, including writing directly to the canvas, needs the remote server. The desktop version is reserved for more closed corporate scenarios.

From a selection in Figma to code in the editor

The most common flow starts with a simple selection: you choose a frame or layer in Figma, click "Copy link to selection," and paste the URL into the MCP client. The agent doesn't navigate to the URL, it extracts the node ID the server needs to identify which object to return. From there, a set of tools becomes available:

• Generate code from selected frames: turns the chosen frame into code, designed for product teams building or iterating on a flow.
• Extract design context: brings variables, components, and layout data straight into the editor, especially useful in design-system-based workflows.
• Retrieve FigJam resources: pulls content from FigJam diagrams (flows, architecture maps) as context for code generation.
• Retrieve Make resources: retrieves code resources from Figma Make files, the bridge between prototype and production application.

The design file has become the contract the agent reads

Here's the shift that matters to product designers, not just to developers. The agent doesn't read a Figma frame the way a designer reads a visual reference: it reads structure. Layer name, component name, design variables (color, spacing, and typography tokens), and the link that Code Connect creates between a Figma component and its real equivalent in the repository. A frame called "Frame 847" with a layer called "Rectangle 12" delivers no context at all to an LLM; a frame called "Product card" using the variable color/surface/primary does.

This redefines what a "well-made file" means inside a product team. Consistent naming, variables organized as real tokens, and components reused instead of loose copies scattered across disconnected layers used to be just good practice for visual organization; now they're the difference between the agent generating something usable or hallucinating a component that doesn't exist in the system. The quality of the design system has, in practice, become the quality of the data fed to AI.

The official Dev Mode MCP Server documentation doesn't list accessibility annotations as an explicitly extracted data type, today the server exposes variables, components, and layout. But the same structural logic applies: accessibility information that lives only in a standalone comment, outside a variable or a named component, never reaches the agent. My reading is that teams who already document contrast, alt text, and focus state as part of the file's structure, rather than as a parallel annotation, come out ahead once code starts coming straight out of Figma.

Code Connect: keeping AI from reinventing the component

Code Connect is the piece that links a component designed in Figma to the real component in code. Without that link, the agent tries to infer how to implement a button or a card from visual appearance alone, and the result tends to diverge from what the engineering team already maintains. With Code Connect set up, the Dev Mode MCP Server uses that reference to generate code consistent with the existing codebase instead of creating a parallel version of the same component.

Two-way street: the agent also writes back to Figma

The canvas-writing feature, available only on the remote server, lets the agent create and modify frames, components, variables, and auto layout directly in a Figma file, using the design system as the source of truth. Another tool, still restricted to select clients, captures the live UI of an app in production, staging, or on localhost and turns entire pages, elements, or flows into editable layers in Figma Design. It's the reverse of the usual flow: instead of design becoming code, rendered code becomes design material for review and alignment.

Who should test it and what's still unresolved

It's worth testing the Dev Mode MCP Server right now on a team that has a mature design system, consistently named variables, and Code Connect set up: that's the scenario where the agent has enough of a contract to generate something useful. It's worth less on a file thrown together at the last minute, with unnamed layers and no tokens, because the agent will inherit exactly that disorganization.

Three caveats weigh on the decision: the feature is in beta, with expected instability; free access has a shelf life, since Figma warns it will start charging per use; and writing back to the canvas, today, only works through the remote server, which pushes organizations that prefer the desktop version toward a smaller set of tools. For product and UX teams, the practical takeaway is this: the next step in design quality is no longer just visual, it's the structure of the file the agent is going to read.