Figma's MCP server shipped in February 2026 with a bidirectional integration with Claude Code. A month later, GitHub announced Copilot support for the same server, making it available inside VS Code. The pitch is straightforward: point your AI coding assistant at a Figma frame, get structured design data instead of screenshot guesswork, generate functional code faster. Every product team evaluating AI-assisted development is now looking at this pipeline. The speed gain is real. What nobody is examining is what the pipeline structurally removes from the design-to-code translation: the human alignment checkpoint where a developer could have asked a clarifying question but now receives auto-generated code instead.
What the MCP Server Actually Reads
The Figma MCP server reads layer hierarchy, spacing values, typography properties, component instances, Auto Layout rules, variables, and design system tokens. It exposes this as structured data that an AI assistant can parse, interpret, and convert into code. If your file uses Code Connect, the server can map Figma components to their corresponding codebase implementations, preventing the AI from generating duplicate components when your button already lives in src/components/ui/Button.tsx.
On well-structured files with mature design systems, semantic naming, and consistent Auto Layout, the output achieves roughly 85 to 90 percent visual accuracy. The remaining 10 to 15 percent requires manual refinement, particularly for responsive breakpoints, interaction states, and accessibility attributes. That accuracy figure is generous; it assumes the design file itself is immaculate.
What the MCP Server Cannot Read
The server cannot read prototype interactions. It does not know that a button should have a hover state with opacity 0.9 and a 150ms ease-in-out transition. It cannot read animation sequences, navigation flows, or conditional logic. It has no access to the conversation that produced the design: the constraints that shaped each decision, the edge cases that were debated and resolved, the component states that were explored and discarded. Annotations placed within nested component instances are invisible to the server entirely, because Figma does not expose nested instance annotations unless you are working with the original master component directly. For teams using atomic design approaches where components compose from other components, this is not a minor gap. It is a structural blind spot.
Figma's own documentation acknowledges this. Their help centre recommends using annotations and dev resources to convey design intent that is hard to capture from visuals alone, like how something should behave, align, or respond. The framing is instructive: Figma positions the intent gap as a user education problem. Annotate better. Write more thorough dev notes. The implication is that the gap is solvable with better hygiene. It is not. The gap is structural. No amount of annotation captures the full context of a design decision, because design decisions are made through conversation, iteration, and shared understanding between people.
Before and After: MCP Pipeline vs. 15-Minute Walkthrough
Consider what a developer receives through each path.
Through the MCP pipeline, the developer gets: a React component with Tailwind classes mapped from Figma spacing and typography tokens; correct visual structure for the default state; hardcoded design values where Code Connect mappings are missing; arbitrary CSS classes like leading-[22.126px] generated from raw Figma measurements; no hover, focus, disabled, loading, or error states; no responsive behaviour; no accessibility roles or ARIA attributes; no explanation of why a 16px gap exists between two elements instead of 12px; no context about which user scenario triggers which component variant.
Through a 15-minute walkthrough, the developer gets: the visual structure, yes, but also the rationale for the spacing decision (it matches the vertical rhythm established in the card component); the three states that were debated (loading skeleton vs. spinner vs. progressive disclosure) and why skeleton was chosen; the edge case where the component truncates after 120 characters because the PM confirmed that long titles break the card grid on mobile; the responsive behaviour at the 768px breakpoint that collapses the two-column layout into a single stack; the interaction pattern where clicking the secondary action opens a confirmation modal only if the user has unsaved changes.
The MCP server transmits the visual output of the design process. The walkthrough transmits the reasoning process itself. These are fundamentally different categories of information.
The Structural Cost of Removing the Translation Layer
The traditional design handoff had a human translation layer built into it. A developer would inspect a design, notice something ambiguous, and ask the designer a question. That question was an alignment checkpoint. It caught misunderstandings before they became pull requests. It surfaced implicit assumptions that neither party had articulated. It was slow, and it was often frustrating, but it was also the mechanism through which design intent transferred from one mind to another.
The MCP pipeline removes that checkpoint. Not deliberately, and not maliciously, but structurally. When a developer can generate a working component from a Figma frame in seconds, the incentive to pause and ask a clarifying question drops to near zero. The code works. It looks right. It passes a visual diff. The fact that it does not handle the error state the designer spent two hours refining is invisible, because the error state was debated in a Slack thread and resolved in a variant that the MCP server could not parse.
Builder.io's analysis of the Figma MCP server notes that generated code provides a useful starting point while still requiring manual adjustments for production use. This framing, while accurate, understates the problem. The issue is not that the code needs adjustments. The issue is that the developer receiving the code may not know which adjustments are needed, because the information that would have surfaced those requirements was never transmitted.
What Teams Should Do About It
The MCP server is a genuine productivity tool. The answer is not to abandon it. The answer is to add back the alignment steps that the pipeline removes. Three practices make the difference.
First, treat Code Connect as mandatory infrastructure, not optional enrichment. Without it, the AI agent generates a new button every time instead of using your design system. Code Connect requires Organisation or Enterprise Figma plans, which creates a cost barrier. That cost is lower than the cost of duplicated components accumulating across your codebase.
Second, build a pre-merge design review step into your pull request workflow. Before any MCP-generated component merges, the designer who created the original frame reviews the implementation against the intended behaviour, not just the visual output. This is the alignment checkpoint reintroduced as process.
Third, stop treating annotations as documentation. Start treating them as executable specifications. Every component in your design system should have its behavioural edge cases, interaction states, and responsive rules encoded in a format that a developer (or an AI agent) can parse without ambiguity. Figma's annotation system is not built for this level of rigour. Design system documentation tools and custom Code Connect configurations are closer to what is needed.
The Figma MCP server makes the code faster. It makes the intent invisible. The teams that thrive with it will be the ones that recognise the speed gain and the alignment cost are the same event.