Figma details what the Dev Mode MCP Server extracts on its own and what still requires manual annotation

Figma updated the Guide to the Dev Mode MCP Server, a document that serves as the official reference for anyone who has already plugged Cursor, Claude Code, VS Code, Codex, or Gemini CLI into Figma via Model Context Protocol. The update doesn't announce a new product version, but it reorganizes and details something that changes the day-to-day routine of design and engineering squads: exactly which data from a Figma file an agent can pull on its own, and at what point the handoff still depends on a human annotating or configuring something beforehand.

This matters because the MCP Server has, in practice, become the main point of friction (or speed gain) between those who design and those who implement. A poorly configured agent generates components that look similar but are technically disconnected from the design system; an agent well fed with design context produces code that is already born using the team's real tokens and components.

Remote by default, desktop for specific cases

The documentation makes clear that there are two ways to run the server, and they're not equivalent. The remote MCP server, hosted at https://mcp.figma.com/mcp, is the option recommended by Figma itself and is available on any seat, on any paid or free plan. It's this version that enables the most recent features, such as writing back to the Figma canvas from the code editor.

The desktop MCP server runs locally through the Figma app and requires a Dev or Full seat on a paid plan. According to the guide, it is "mainly for specific use cases at organizations and companies," meaning it's the route for those with network restrictions, requirements that data not leave the machine, or corporate security policies that prevent calling a remote endpoint. For the broadest set of features, the documentation itself recommends the remote option.

The difference isn't cosmetic: the compatibility table published in the guide shows that features like "write to canvas" (the agent creates or edits frames, components, and variables directly in the Figma file) only work with the remote server, and only for a specific list of clients: Claude Code, Claude Desktop, Codex, Cursor, VS Code, Kiro, Warp, and Xcode (beta), among others. Amazon Q and Android Studio, for example, appear in the table without support for this function.

What the agent extracts without human intervention

The most basic flow described in the guide, "Get design context," is purely link-based: the designer selects a layer or frame in Figma, clicks "Copy link to selection," and pastes that URL into the MCP client (Cursor, Claude Code, etc.). The agent doesn't navigate to the URL itself; it extracts the node ID embedded in the link, which is the identifier the MCP Server uses to locate the object and return the data.

From there, what comes back to the agent includes:

• Design variables (colors, spacing, typography defined as tokens)
• Components and their structure
• Layout data, including auto layout
• FigJam resources, allowing flowcharts and architecture maps made during the ideation phase to be brought directly into the code generation context
• Figma Make file resources, useful for those migrating an AI-generated prototype to a production application

The guide also explicitly mentions that the server and the Figma Agent can use fonts loaded into the user's account, which prevents generated code from falling back to default system fonts when the design's typography is customized.

Code Connect: the piece that still depends on manual configuration

Here's the point that separates automatic extraction from team work. The guide is explicit: "Boost output quality by reusing your actual components. Code Connect keeps your generated code consistent with your codebase." Without Code Connect configured, that is, without someone from the engineering team having previously mapped each Figma component to its equivalent component in the code repository, the MCP Server can still extract variables and layout structure, but the agent will generate a visual approximation of the component, not a real instance of the production component.

In other words, extracting "design context" (colors, spacing, hierarchy) is automatic. Ensuring that the generated code uses the design system's actual Button, with its real props and variants, instead of reinventing a similar-looking button, remains a setup task carried out through Code Connect, done by someone with access to the design system and the component repository.

Skills: sequencing guidance, not new capability

Another new piece in the documentation is the concept of Skills, available via plugin or native integration in clients like Claude Code, Codex, Copilot CLI, Cursor, Gemini CLI, Kiro, and Xcode. Figma's text is direct about what Skills does and doesn't do: "Skills don't replace MCP connections or add new MCP capabilities. They reduce setup and guesswork by packaging recommended workflows into reusable instructions."

In practice, Skills works as a script that tells the agent in what order to call the MCP tools and how to interpret the results, for example, guiding a flow of "connecting Figma components to code components via Code Connect" or "translating designs into production-ready code." It's a productivity aid, not a new technical capability: the agent remains limited to the same MCP Server tools, just with less trial and error along the way.

What's still in beta and why it matters for the team's budget

The guide is transparent about a point that squads evaluating adoption at scale need to consider: features like writing directly to the canvas and capturing live UI from the browser (production, staging, or localhost) to turn into editable layers in Figma are described as "currently available for free during the beta period," with an explicit warning that "this will eventually be a usage-based paid feature." In other words, the billing model for these two specific features isn't settled yet, and the text doesn't hide that, which is different from treating the entire MCP Server as an already stabilized tool with predictable cost.

This changes the calculation for anyone deciding whether it's worth integrating now or waiting: the context-reading flows (extracting variables, components, layout) and Code Connect are today's most stable foundation; the writing flows (canvas and live UI capture) still carry uncertainty about future pricing, even though they're technically available.

Where this leaves handoff in practice

For those who already use MCP day to day, the documentation update works less as an announcement of a new feature and more as a more precise map of responsibilities: extracting raw design data is the MCP Server's job and doesn't require recurring extra work; ensuring generated code reflects the design system's real components is Code Connect's job, which requires ongoing maintenance from whoever maintains the design system; and guiding the agent to correctly execute complex workflows is Skills's role, which packages institutional knowledge into reusable instructions but doesn't replace either of the two previous pieces.

The practical lesson for squads that combine UX and engineering is that the speed gain promised by the MCP Server is only fully realized when Code Connect is kept up to date: without that, the agent still delivers an approximation, not the production component, and the product team still has to manually review whether what came out of the prompt matches what was designed.