Figma Dev Mode MCP Server: how to plug Copilot, Claude, and Cursor into your design file

It's an old problem that any dev who has ever taken a finished Figma screen and turned it into a component knows well: design lives in one place and code lives in another. Along the way come the screenshot pasted into the AI chat, the "what's the hex code for that blue again?" and the eternal guess about which spacing token the designer used. The result is usually a component that looks right in the screenshot but ignores the design system that already exists in the file.

Figma's Dev Mode MCP Server tackles exactly this gap. According to the official guide on the Help Center, it exposes the content of Figma Design, FigJam, and Make files to AI agents through the Model Context Protocol (MCP), the standard that has become the common interface for LLMs to talk to external data sources. Instead of describing the screen to the model, the dev lets the agent itself read variables, components, and layout data straight from the source.

What MCP changes in practice

MCP is an open protocol: the AI agent (the client) talks to a server that knows how to answer questions about a data source. In this case, the server is Figma, and the source is your design file. The difference compared to pasting a screenshot is qualitative, not just a matter of convenience.

When the model reads a frame via MCP, it doesn't get an image to interpret, but the structured data behind it: the name of the color variable, the auto layout spacing token, which design system component is being instantiated. It's the difference between the AI guessing padding: 16px by looking at pixels and it knowing that this is spacing/md defined in the library.

The guide lists what the server delivers today:

• Generate code from selected frames, useful for teams building new flows.
• Extract design context (variables, components, layout data) directly in the IDE.
• Retrieve FigJam resources, bringing flow diagrams and architecture maps into the generation process.
• Pull resources from Make files as context when migrating from prototype to application.
• Write to the canvas: create and modify frames, components, variables, and auto layout inside Figma from the MCP client.
• Generate design from live UI, capturing the interface rendered by your code (production, staging, or localhost) and turning it into editable layers in Figma.

Remote or desktop: which server to use

There are two connection modes, and the choice matters. The remote server (recommended by Figma itself) connects directly to the endpoint hosted at https://mcp.figma.com/mcp and offers the broadest set of features, including canvas writing and live UI capture. It's available across all seats and plans. The desktop server runs locally through the Figma app and is described as geared toward specific organization and enterprise use cases; it requires a Dev or Full seat on paid plans.

| Aspect | Remote server | Desktop server | |---|---|---| | Endpoint | https://mcp.figma.com/mcp | Local, via desktop app | | Availability | All plans and seats | Dev/Full seat, paid plans | | Canvas writing | ✓ | No | | Live UI capture | ✓ | No | | Target audience | General recommendation | Org/enterprise cases |

One detail the Brazilian team needs to register before jumping in: the guide warns that "this will eventually be a paid, usage-based feature, but it is available for free during the beta period." In other words, it's possible to adopt it into the flow now, but tomorrow's bill still doesn't have a fixed price, and planning the team's dependency on something that will change its pricing model is an architecture decision, not just a tooling one.

Supported clients

The ecosystem is already broad. The guide includes a compatibility table covering everything from Copilot CLI, Claude Code, Claude Desktop, Cursor, and VS Code to OpenAI's Codex, Gemini CLI, Kiro, Warp, Xcode (beta), Android Studio, Amazon Q, and Replit. Canvas writing, however, is exclusive to the remote server, and not every client supports it, so it's worth checking the column before promising the feature to the team.

For Claude Code, Cursor, VS Code, Copilot CLI, and Xcode there's also support for a Figma plugin. And this is where the concept of Skills comes in: agent-level instructions that guide how to use the MCP tools. As the guide explains, the server exposes individual tools, but Skills help the agent understand which tool to call, in what order, and how to apply the result. They guide flows such as connecting design components to code components via Code Connect, generating design system rules aligned with the codebase, and translating designs into production-ready code. Skills don't add new capability to MCP, but they reduce setup friction and guesswork.

A concrete example of a flow

The most straightforward case in the guide is getting design context, which is link-based:

1. In Figma Design, select the desired layer.
2. Right-click the frame or layer and choose Copy link to selection.
3. In the MCP client, paste the URL and ask the agent to implement the design.

The interesting technical detail: the client doesn't navigate to the URL. It extracts the node ID contained in the link, which is the identifier the MCP server uses to know which object to return information about. It's this ID that turns "implement that screen" into a structured query.

The reverse path, sending live UI to Figma, happens through conversation. A prompt like "spin up a local server for my app and capture the UI into a new Figma file" makes the client open a browser window with a capture toolbar, letting you send pages, elements, and states into Figma Design as editable layers. It's useful for alignment and for documenting in design what previously only existed in code.

Where MCP fits accessibility, and where it falls short

A gain that doesn't make the headline: when the agent reads real variables and components instead of an image, it increases the chance that the generated code reuses components that were already designed with accessibility in mind, with defined focus states, contrast, and semantics. Code Connect, mentioned in the guide as a way to keep generated components consistent with the codebase, is the piece that closes this loop: reusing the real component instead of letting the AI reinvent a button without an aria-label every time.

But MCP is no silver bullet, and the feature's own scope makes that clear. It translates design structure into code; it doesn't validate whether the source design was accessible, whether the tab order makes sense, or whether the contrast passes WCAG. Agent-generated code still needs to meet the definition of done with human review, keyboard testing, and a screen reader pass on top. Where the design system is immature, with inconsistent variables and loose components, the server will just propagate that mess faster, which reinforces that the tool rewards those who have already done their design system homework.

There's also the cost warning already mentioned: for a Brazilian agency or squad on a tight budget, basing an entire flow on a beta feature that will turn into usage-based billing calls for a plan B. And, being beta, the guide repeats at several points that the features are "under continuous improvement" and suggests reporting issues through the Fig chatbot or by email to paid support, which is the polite way of saying instability is part of the package for now.

For those already living inside Copilot, Claude Code, or Cursor, the invitation is still clear: start with the cheapest, safest flow, Copy link to selection feeding context extraction, measure whether the generated component really respects the library's tokens, and only then move on to canvas writing and UI capture.