Figma's Dev Mode MCP Server Only Generates Faithful Code When the Design System Is Ready

O problema que o Dev Mode MCP Server tenta resolver não é a IA escrever código: é a IA escrever o código ERRADO porque nunca viu o design system de verdade.

The problem the Dev Mode MCP Server tries to solve isn't AI writing code: it's AI writing the WRONG code because it never saw the real design system. Until now, an AI agent only saw what someone pasted into a prompt: a screenshot, a description, a loose link. The official Figma Help Center guide for the Dev Mode MCP Server describes a different path, one in which the agent reads the design file directly, with real variables, components, and metadata.

What the MCP server actually connects

MCP stands for Model Context Protocol, a standard that lets AI agents talk to external data sources without custom integration for each tool. In Figma's case, this means a client like Claude Code, Cursor, Copilot CLI, or VS Code can call Figma's MCP server and get back structured data from the design file, not a screenshot.

The usage flow described in the documentation is link-based, not upload-based: in Figma Design, you right-click the desired frame or layer, select Copy link to selection, and paste that link into the MCP client. The client doesn't open the link; it extracts the node ID the server needs to identify the object and return context about it. It's this ID, not the full URL, that becomes the bridge between Figma and the code editor.

Remote or desktop: the choice changes what you get

Figma maintains two ways to connect the MCP server, with different requirements and scope. The table summarizes what the documentation details:

For Figma for Government accounts, the remote endpoint changes to https://mcp.figma-gov.com/mcp, and the commercial one-click automatic integration flows don't configure these accounts; the documentation points to a separate setup guide for this case.

Generating code is just one of the pieces

The server's list of capabilities goes beyond "turning a frame into code." The agent can extract variables, components, and layout data into the editor (useful for design systems and component-based workflows), pull content from FigJam diagrams to give flow and architecture context to the code it's about to generate, and retrieve assets from Make files when migrating from prototype to production.

There's also the reverse function, writing: with the server's remote version and a Full seat outside of personal drafts, the agent can create and update frames, components, variables, and auto layout directly in Figma. The documentation is explicit about this feature's stage: it's in beta, free for now, and will become a pay-per-use feature. It's worth treating it as a maturing feature, not as a stable production capability.

Where the design needs to be ready before the agent comes in

The angle that matters most to whoever designs components is this: the MCP server doesn't make up for a disorganized design system, it exposes exactly what that design system already is. Two features mentioned in the guide decide whether the generated code will look like your codebase or like a generic AI reinvention.

The first is Code Connect, which maps Figma components to real code components. When this mapping exists, the agent reuses the project's actual components instead of recreating markup from scratch based on visual appearance, which is the difference between code that's consistent with the rest of the app and code that looks like it came from another project.

The second is Figma Specs, currently in open beta, accessed through the figma-spec skill. It lets the agent read, create, and update the team's specs before starting to build, and record decisions and findings back into the spec while it works. Writing to a spec requires the remote server and edit access to the file, but it's this text, not the design itself, that carries requirements, edge cases, and business rules that no pixel communicates on its own.

Accessibility annotation is part of the context, not an optional detail

No component, no matter how well named, tells the agent which ARIA role a div should take on, what the expected focus order is in a form, or what alt text a decorative image can skip. Those decisions live in the designer's head, and if they aren't recorded as an annotation or a spec, the agent will infer them from visual appearance, which is exactly the kind of inference that produces semantically wrong HTML even when the CSS matches Figma pixel for pixel.

Treating accessibility as part of the context the AI agent receives, rather than as a later review of the generated code, is how you keep the definition of done intact in a workflow that is otherwise being sped up. That means annotating focus states, heading hierarchy, field labels, and expected screen reader behavior right in the Figma file itself, alongside the specs and components, before asking the agent to implement.

The friction points that still exist

Not every MCP client supports every function: the compatibility table in the Figma MCP catalog lists clients such as Cursor, Claude Code, VS Code, Android Studio, and Amazon Q with different levels of support for the desktop server, the remote server, canvas writing, and skills, and the documentation itself recommends checking the catalog for the most current list before promising a specific workflow to the team.

Seat costs also factor in: canvas writing outside of drafts requires a Full seat, and the desktop server requires a Dev or Full seat on a specific paid plan. Figma classifies canvas writing and code generation from the canvas as "continuously improved" features, which in practice is a warning that workflow bugs still show up, reportable through the Fig support chatbot or by email for paid accounts.