Stop Feeding Figma Screenshots to AI: Wire Codex to Figma's MCP and Hit 95% Fidelity

AI fails to replicate Figma designs? Don't rush to make it write code.

I've noticed many people trying to get AI to replicate a Figma design start by taking a screenshot, or export the design as an image, then hand that to the AI to write the page. Others just paste a Figma link and say "replicate this" and wait for the result.

If Figma isn't actually connected, the Agent might just open a webpage, look at a screenshot, and guess the layout from the image. It never checks what it actually read, so details like sizes, spacing, and fonts tend to be off.

Today I'll share my own workflow. I use Codex to read Figma directly through MCP, analyze the design first, list requirements, wait for my confirmation, and finally open the page to compare and verify.

After completing this workflow on my own project, the overall visual fidelity reached an estimated 95% or higher, with the remaining bits being small tweaks. The integration method and four prompt snippets are all below—you can try them directly.

1. Connecting Figma to Codex via MCP

The connection uses Figma's official remote MCP. You can think of MCP as a bridge that lets AI call Figma's tools. In Codex, I installed the official Figma plugin, which comes with MCP configuration and related Skills.

Among them, the figma-design-to-code Skill acts like an instruction manual, guiding the AI to read the design and then implement it within your existing project.

Connecting takes just these steps:

1. In Codex's Plugins section, find Figma, install it, and authorize the account.
2. Return to Codex and confirm Figma shows as connected.
3. In Figma, select the target frame or layer, right-click Copy link to selection, and send that node link to Codex.

The "node" here refers to a frame, layer, or element in the design file. Copying its link lets the AI locate the exact part you want to work on. Figma official integration tutorial

Check the supported list first

For this official remote MCP method, the client must be on Figma's supported list. As of November 5, 2026, the official docs list the following:

• Coding tools include Codex, Claude Code, Cursor, VS Code, Copilot CLI, Gemini CLI, OpenCode, Kiro, Warp, Augment Code, Factory, Replit, Android Studio, Firebender, Xcode (Beta).
• Other clients include Claude Desktop, Dia, Linear, Meta Muse.

The list will be updated later—check the official page for the latest. Figma official supported list

If your client isn't on the official list, you know what I mean. I've tried it for you—this path won't work, so don't waste your effort.

Rate limits also matter

Figma MCP has limits on how often you can read designs, depending on your account plan and seat type. Under current official rules, Starter plans or View/Collab seats get up to 20 reads per month; the Education plan gets up to 200 per day and 10 per minute, matching the limits for Professional Full/Dev seats. Official quota info

My own hack is to buy a Figma education discount on a second-hand marketplace, copy the frame you have permission to access into your own education team project, then let the Agent read that file. The steps: select the frame, Ctrl+C, Ctrl+V to copy it into a new file (use Command on Mac).

After copying, use the new node link. Also confirm the file's team plan and the seat type of the MCP logged-in account; you can have the Agent check with whoami. Actual quotas are calculated based on the active plan and seat.

The education plan requires student or teacher verification; eligible people can apply for free. Education plan details

2. After connecting, first verify it actually read the design

In short, most of the visual details a frontend needs to turn a design into a webpage can be read directly by the AI, such as button sizes, spacing between sections, font and text colors, and icon positions—provided those details are defined in the design file.

Expanding that, the main categories are:

• Layout: width, height, position, margins, spacing, alignment, and Auto Layout rules.
• Styles: text, font, size, weight, line height, color, border radius, borders, and shadows.
• Structure: layer hierarchy, components and states, plus shared design variables like colors and spacing.
• Assets: icons, illustrations, images, and node screenshots. Figma official tool docs

I check whether the tool call succeeded and if the returned data matches the design. Here's a comparison table to help:

What to check	Common pitfall	Correct approach
Access	Tool reports unauthorized or node not found, yet still says read successful	Check authorization, file permissions, and node link first
Target	Given a detail page, but another frame was read	Verify node ID, name, and screenshot
Structure	Just downloads the whole design image, then guesses layout from the picture	Read node structure and properties, then compare with screenshots
Completeness	Page too large, only reads half before writing code	Continue reading by area to gather all needed info for this round
Parameters	Sizes and spacing are all 'approximate'	Return actual values read, so you can verify item by item
Assets	Icon not read, so draws a similar-looking replacement	Read the actual asset in real-time, verify shape, size, and position

Screenshots are fine for comparing effect; the key is whether you also read the node structure and concrete parameters. The official flow also uses design context and screenshots together. Figma official replication flow

The first prompt already includes this check. After getting results, pick one or two elements and compare against Figma.

3. Now replicate the design in four steps

Step 1: Read the design and project

Open Codex in the project directory. I usually only give it the Figma node link and the module to work on. It reads the code itself to confirm the tech stack, existing components, and page entry points.

I have a habit: after stating the requirement, I add a note—"First understand my requirement, then repeat it back; I'll confirm before you proceed."

Check what it plans to do next and whether that matches your thinking. Adjust if there's a discrepancy. Especially for large-scale changes, I strongly recommend this step—it saves a lot of rework later.

When reading the project, also confirm whether this module has an API that provides real data.

• If no API: use Mock (temporary simulated data) and replicate the page 1:1 from Figma. Manage this data centrally so it's easy to replace later.
• If an API exists: first check what fields it actually returns (like name, count, status), then apply those values to the UI styles. If the design shows content the API doesn't have, list it separately for confirmation.

Don't let the AI invent fields that don't exist in the business just to fill the screen, or you'll have to rework it when connecting real data.

Please use the Figma tool to read [node link] in real-time, locate [module name] in the current project.

First return the names, IDs, and dimensions of two child nodes, plus the font size and color of one text element and a node screenshot, so I can verify the read result.

Read the project's tech stack, component library, styles, and APIs, and confirm available fields. Combining the design, restate what's to be done, what can be reused, and what needs my confirmation. Read related states too; if there's too much, read in batches by child nodes.

This round is analysis only—don't change code, wait for my confirmation. Only report what was actually read; if it can't be read, say so.

Step 2: List out the differences item by item

Next, my usual line—"List them one by one, separate styles from text, categorize clearly."

Compare Figma, the current page, and the code; list everything that needs to change.

Categorize by text, style/layout, and interaction rules. Use a table with
Number | Location | Current state | Design requirement | Proposed fix

Use concrete values for sizes, spacing, and font sizes; also check icons and images.

If an API exists, check real fields; list missing content separately. If no API, indicate Mock usage.

For new features, field meaning, or impact on other pages, note them separately. Wait for my confirmation of the list before making changes.

For example, a list I received before had these items:

Number	Current page	Figma requirement
W05	Representative patents	Core patents
S07	Four cards, 2×2 layout	Five cards, first row three, second row two
R01	Four category lists, 3, 3, 6, 8 items per page	5 items per page per category

Step 3: Confirm the list, then let it start coding

I usually reply by number; if all are fine, I say "all". If something should be kept, I add that too—like one time I added, "Don't change the graph style."

Confirmed. Process the items [numbers or all] in the list, and replicate Figma within that scope.

Reuse existing components and styles. For modules without an API, use Mock data to replicate the UI; keep Mock centrally managed for easy replacement.

For modules with an API, use real fields and values, preserving business logic. List missing content as pending confirmation items; don't invent fields or mix in Mock.

For icons and images, use the assets read from Figma in real-time as the source; position, size, and ratio all follow the design.

If there are business-rule questions, ask them; continue working on the confirmed parts. After finishing, explain which list items were handled and which files were changed.

Step 4: Open the page and compare again

After the page is built, I have it use browser tools or Playwright to actually operate the page. Switching tabs, paginating, opening modals, entering details and going back—all need to be clicked through. It should verify the page entry and display size itself.

Open the actual page, set the viewport to Figma's design size, and check items against the list one by one.

Check layout, text, and styles; actually operate tabs, pagination, modals, and entry/return from details. Also check narrow screens, long text, and empty states as the project requires.

Verify that icons and images load correctly, and that position, size, and ratio match.

Fix discrepancies found this round, then repeat the relevant operations, and run related code checks.

Finally, attach key screenshots, list passed items, remaining differences, and unverified items, and state whether each module uses real API or Mock data.

Once, I scaled the page to a phone size of 390×844 and discovered both inner and outer layers were scrolling, pushing an action button off-screen. Another time, switching tabs back and forth revealed a state element was missing 16px of left padding.

After fixing both, I had it run the original operations again to confirm the button was clickable and the tab-switch position was correct.