Ever since Figma launched its MCP Server, many existing design-to-code workflows have started to feel outdated.
Until now, most workflows relied on screenshots or written descriptions to give models a rough sense of a UI. This approach was always limited, often resulting in code that drifted away from the actual design.
With Figma MCP, LLMs can finally access the real structure, styles, and content of your file. This removes the guesswork and produces output that is far more consistent with your original design.
In this blog, we’ll look at:
- What Figma MCP actually is
- How to set it up
- How to use it effectively,
- Where it still falls short, and
- What might be a better alternative if you’re aiming for clean, production-ready code?
Let’s get started.
What is MCP?
MCP stands for Model Context Protocol. It is an open-source standard for connecting AI models to external systems so that they can access data beyond their training.
Before MCP, if you wanted to connect an AI to a new data source, you had to build a custom integration from scratch. Now, you can simply expose your data through an MCP Server, and AI applications like ChatGPT, Claude, or Cursor can instantly use it.
Below is a visualization of this MCP Workflow:
(Source: https://modelcontextprotocol.io/)
Now, let's talk about how Figma uses this.
Figma adopted this standard to build their own MCP server, which brings the design context of your Figma Files directly to your model.
By design context, we mean the server actually shares structured information with your IDE, including:
- Your node structure
- Layout information
- Styles and variables
- Text content and assets, etc.
As a result, agentic coding tools like Cursor and Claude can generate code that is more accurate and aligned with your design.
Figma MCP basically aims to minimize the design-to-code gap that appears when models rely on images alone.
With direct access to your file’s structure and metadata, the model can now have a semantic understanding of your design, which means you’ll get much better alignment between your design and the generated code.
Below is a visualisation of the Figma MCP workflow:
Why use the Figma MCP Server
Before we jump into the setup, let’s take a moment to understand why use Figma MCP at all.
When teams turn Figma designs into code, developers usually end up doing one of a few things:
- manually translate the design into code (slow and repetitive)
- use an LLM and hope it understands the design from a screenshot
- rely on plugins like Builder, Anima, etc., which help but still miss details and drift from the real design
These methods work, but they all share the same issue: the AI doesn’t actually understand your design.
It only sees an image — not the layers, spacing, variables, tokens, or components behind it.
This is where Figma MCP becomes useful.
Instead of guessing from a screenshot, MCP gives your editor the actual structure of your design. So when your model generates code, it’s working with the same information you see inside Figma.
To demonstrate this, let’s take a simple card component and generate it twice:
- Once using just Cursor, and
- Once using Figma MCP + Cursor.
Here’s the prompt I used in Cursor:
Here’s the output Cursor(Auto Mode) produced:
Now let’s try the same thing using Figma MCP+Cursor(Auto):
As you can see, it pulled the exact image and styles, resulting in a card that is almost identical to the original.
How to set up Figma MCP Server
There are two ways you can connect the Figma MCP Server to your AI Editor:
- Desktop MCP Server — Runs locally inside the Figma Desktop app
- Remote MCP Server — Connects to Figma’s hosted MCP endpoint
Setting up Desktop MCP Server
We will do it in two parts. In the first part, we will enable the MCP server in the Figma Desktop App, and in the second part, we will connect our editor to the desktop server.
Part 1: Enable MCP in Figma Desktop
- Open the Figma Desktop App
- Open your Design file
- Switch to Dev Mode (bottom toolbar)
- In the right panel, click Enable desktop MCP server
You will now see an Enabled indicator confirming that the server is running locally.
Part 2: Connect Desktop Server to Editor (Cursor Example)
Go to Cursor:
- Open Settings → Cursor Settings
- Go to Tools & MCP
- Click Add Custom MCP
- Paste the following config:
{
"mcpServers": {
"figma-desktop": {
"url": "http://127.0.0.1:3845/mcp"
}
}
}Save it and restart your editor.
You should now see figma-desktop listed under Installed MCP Servers, as shown below.
Setting up Remote MCP Server
The Remote MCP Server uses Figma’s cloud API to fetch design context, so your model can work with files without needing the desktop app running.
Here’s how you enable it in Cursor:
- Go to Cursor’s MCP documentation
- Select Figma MCP and open its configuration in Cursor
- Click Install
- Click Connect to authenticate
After authentication, you should see Figma under Installed MCP Servers.
Desktop MCP vs Remote MCP — what’s the real difference?
As we have just seen, Figma gives you two ways to send design context to your editor: Desktop MCP and Remote MCP. Let's try to understand how they differ from each other.
Desktop MCP Server
The Desktop MCP Server works only inside the Figma Desktop app.
When you select a frame or layer, that selection becomes the context your editor receives. It is selection-based, so whatever you click in Figma is exactly what your editor gets to know about.
It’s useful if you:
- Work mostly in the desktop app
- Prefer selecting things directly instead of copying links
- Need access to additional tools that the Remote MCP Server doesn’t support
Remote MCP Server
The Remote MCP Server is Figma’s hosted MCP endpoint. Your editor connects to it by authenticating with your Figma account, and the server fetches design context using Figma’s cloud APIs.
The Remote MCP Server is link-based. You copy a file or layer URL, paste it into your editor, and the MCP server fetches the design context from your Figma account.
It’s handy if you:
- Prefer using Figma in the browser
- Can’t install the desktop app
- Don’t mind using links to share context
- Don’t need the tools that are only available on the desktop server.
So what really changes?
Both servers give your editor the same types of design data — structure, layout, text, styles, assets, etc. — but the workflow is different:
- Desktop MCP → uses your selection in the desktop app
- Remote MCP → uses links to your cloud file
How to use Figma MCP
Now, let’s move to the fun part of actually using Figma MCP in a design.
Below is the design we are going to use. Feel free to grab a design of your own.
Now, switch to Cursor and give your prompt. Here’s the one I used: “Implement the selected Figma frame using plain HTML and CSS.”
And here’s the result:
The result is almost the same as the original design. It didn’t match the likes, comments, or bookmark section perfectly, but for the overall component, it did a good job.
You can see how much better the output gets once the model has the actual design context instead of guessing from an image.
If you want to explore more of what MCP can do, Figma’s official MCP docs also list all the available tools and how they work. You can check it out here.
As you use Figma MCP more, you’ll get a clearer sense of where it helps and where it still falls short. In the next section, we’ll look at some of these limitations and also see what might work better if you’re aiming for production-ready front-end code.
Current Limitations of Figma MCP
Figma MCP is a huge leap forward for design-to-code workflows. It makes the gruntwork of converting designs to code much more efficient and easier.
But when you move from simple experiments to real-world applications and production-ready code, there are a lot of significant limitations that you’ll come across.
Let’s look at some of them:
Design Structure Dependency
Figma MCP’s output depends heavily on the quality of your Figma file. If you are working with a well-structured design with clearly defined variables, components, auto layouts, and structure, the output it produces will be much better aligned. If not, the output might not be consistent or as accurate.
Design structure dependency essentially means good file structure = good output and vice versa.
Lack of scalable structure
By scalable structure, we mean a project structure that a team can build onto easily, that needs less cleanup, and that is closer to how production applications are structured in the real world.
Figma MCP’s output lacks that kind of structuring.
To demonstrate this, I tried converting the below design into a React app using Figma MCP in Cursor. The design has multiple pieces, like the Sidebar, Header, Order page, and then details of the order page, such as filtering orders by their status and pagination.
Here’s the component structure Figma MCP+Cursor(Auto) provided:
From a broader look, it may seem fine. Cursor splits up the major components, but if you take a closer look at it, you’ll notice that there’s no hierarchy or internal organization.
All components sit at a single level with no grouping or substructure. The page has a lot of icons, so instead of icons remaining inline, a good project structure would extract them into their own separate folder.
For example, this can be considered a better structure for the same React app:
Low Fidelity in Complex Designs
Figma MCP has good fidelity when it comes to converting simple, direct elements to code. But when we talk about pages with real-world complexity and detailing, it doesn’t really hit the mark.
For example, let’s take the same design above and try converting it into a React app.
Here’s the prompt I used:
“Build a React dashboard from this Figma file. Use Vite + React 19 and Tailwind CSS. Produce a runnable project without any errors. Include: sidebar, header, filter bar (search + status), paginated orders table, a modal form to create a new order, and a toast for new entries.”
And here’s the output:
It is not even close to my original design. Although the functionality and high-level details are the same, the fidelity is way off.
Why Kombai is the better solution
Kombai solves the problems you just saw with Figma MCP. Where MCP struggles to interpret complex layouts reliably, Kombai’s frontend-focused engine performs better.
Kombai is built specifically for frontend engineering, which makes a fundamental difference in how it reads layouts, breaks them into components, and converts those into clean, production-ready code.
It accepts design inputs from Figma, images, or even text and generates clean, structured, maintainable code that follows framework-specific best practices and is much closer to how real-world applications are built.
If you want something that not only helps in generating simple UIs but also delivers clean, production-ready code even for complex applications, that’s exactly what Kombai is built for.
Enough of the talking, let’s put it to the same above test and see how it performs:
Component Structure and Scalability
Again, below is our original design:
Here’s the same prompt that I used: “Build a React dashboard from this Figma file. Use Vite + React 19 and Tailwind CSS. Produce a runnable project without any errors. Include: sidebar, header, filter bar (search + status), paginated orders table, a modal form to create a new order, and a toast for new entries”.
This is the structure Kombai produced:
If you compare it side by side with Figma MCP+Cursor’s structure, you can spot the differences better.
(Figma MCP’s Structure on the left Vs Kombai’s on the right)
As you can see, Kombai produced a clean, well-layered component structure. Every meaningful piece of the UI — the sidebar, header, filter bar, table, pagination, badges, service indicators — lives in its own file.
Icons are grouped in a dedicated folder, and all of this mimics very closely how production-ready applications are structured.
High Fidelity
Kombai matches the fidelity to my original design and has a better fidelity than what Figma MCP provided using the same prompt, same stack, same ask.
Here’s the preview result from Kombai:
The sidebar, header, and main layout follow the same structure. It pulled in the exact icons, kept the original color palette, and even replicated the logo.
Small details in the sidebar, like the user profile and the spacing between sections, are preserved almost exactly.
The only thing that didn’t match was the pagination style at the bottom, which is slightly different from the design. But I can refine that very easily if I want.
Overall, the UI looks like a replica of the Figma design I gave.
Framework Specific Best Practices
One of the biggest differences you’ll notice with Kombai is that it doesn’t rely on generic patterns when generating front-end code. Instead, Kombai uses human-tested, framework-specific RAGs to understand how real React, Vue, Tailwind, and other modern stacks are actually structured in production.
This means the code it generates isn’t just correct at a surface level — it aligns with how engineers build real applications and applies framework-specific best practices. Because of this, setup issues are almost rare when working with Kombai.
For example, when I tried running the same above React app after generating it from Kombai, it ran smoothly without a single error related to any library. But the same code generation with Figma MCP and Cursor resulted in setup errors like below:
Figma MCP Best Practices
There are many things you can do inside your Figma file to improve code generation, but if you don’t want to touch the design at all, here are a few simple practices you can follow directly in your IDE to get better results with Figma MCP:
Write clear, specific prompts
Figma MCP works best when the model knows exactly what you want.
The MCP server only provides the structure of the selected layer — it has no awareness of your codebase, folder layout, naming rules, or how your team uses components.
So being specific about the framework, file structure, or expected behavior helps the model generate code that aligns better with your project.
Trigger the right tools when needed
Figma MCP offers tools like get_design_context (structured layout info) and get_variable_defs (tokens, colors, spacing).
Sometimes the assistant doesn’t trigger them on its own, so asking for them directly – especially when you need variable names or detailed styling gives the model the exact information it needs to generate cleaner, more accurate code.
Keep small markdown files for guidance
Cursor works much better when it has a stable written context.
For that, you can create short markdown files even if they’re AI-generated and add things like preferred folder structure, common component examples, or naming conventions.
Cursor uses these as a stable context, so the output becomes more consistent and aligns better with how your project is organized.
Use Figma Code Connect for Component Mapping
If you have an existing component library or design system, Figma’s Code Connect feature can make the MCP workflow smoother.
Code Connect lets you map a Figma component to the real code component in your repository using the Code Connect CLI. You can define which design component corresponds to which code component, what props it supports, and include usage examples.
Once this mapping is in place, Dev Mode shows these details when someone selects the component, and the MCP server includes this metadata in its response.
This gives the model a clearer idea of which component to use and how it should be imported, which is especially helpful for teams that want the MCP output to follow their actual component library rather than generating brand-new components each time.
Additional Tips for Using Figma MCP
Before we wrap up, here are a few extra MCP features that can make your workflow smoother.
These aren’t mandatory for day-to-day usage, but they’re helpful when you want to understand what the MCP server is sending or when you need more control over the Figma file.
Inspect MCP responses
Figma provides an MCP Inspector you can launch with pnpm inspect. It opens a small web UI where you can see available tools, trigger them manually, and check the raw responses coming from the MCP server.
Use get_file for file-level info
The get_file tool lets you fetch details about a Figma file using its fileKey, with an optional depth parameter if you want more or less of the document tree.
Use get_node for specific layers
The get_node tool returns information for a specific node inside the file using its fileKey and nodeId. This lets you directly inspect the same data the MCP server shares when you select a layer in Dev Mode.
These tools aren’t required to generate code with MCP, but they give you a clearer picture of what the server sees. And when you’re trying to debug or just understand how MCP works under the hood, they’re extremely handy.
Conclusion
Figma MCP is a solid step forward for design-to-code. By giving AI access to the real structure and styles of your Figma file, it removes much of the guesswork that comes from relying on screenshots. For smaller components and quick UI tasks, this alone makes a noticeable difference.
But Figma MCP’s job is to expose design context — it doesn’t know your codebase or know how to apply framework-specific patterns. As soon as you start working with larger interfaces or aim for production-ready code, these limits start to show up quickly.
That’s where frontend-specialist tools like Kombai come in. Kombai takes the design context and combines it with a deeper understanding of modern frontend frameworks and best practices, producing code that not only aligns with the design but also aligns with how modern applications are actually built.