Claude Code and Figma MCP: What Actually Changed for Me
I've been using Claude Code with Figma's MCP server for a few months now and I keep starting to write about it and stopping because I don't want to write another "here's how to set it up" post. There are plenty of those. What I haven't seen is someone being honest about what the experience is actually like, what changed and what didn't, and where the real friction lives. So that's what this is.
Fair warning: this is going to be a little all over the place because that's kind of how I process things.
Before this, Claude was basically guessing
I want to explain what "before" looked like because I think it matters for understanding why MCP feels like a big deal.
Before I had this set up, I'd reference a Figma file in Claude Code and it would do its best with what was essentially a rendered screenshot. It'd pick a shade of blue that looked pretty close to my brand color. Not the actual token, just visually close. It'd rebuild components from scratch because there was no way for it to know what already existed in my library. I'd ask it to implement a simple card and it'd give me a div with hardcoded values instead of pulling the Card component my team had built six months ago. The code worked. It looked roughly right. But it was drifting from my actual design system with every single output.
I got used to that being the deal. You'd use Claude to get 70% there and then spend time cleaning up the 30% that didn't know anything about how your team actually builds things.
MCP changes that baseline completely. It's not subtle.
What MCP actually gives Claude access to
The Model Context Protocol is an open standard Anthropic built so that AI agents can connect to external tools and data in a structured way. Figma built an MCP server on top of it. What that means in practice is that Claude Code isn't reading pixels anymore. It has access to your actual component metadata, your token values, your layout structure. When you set up Code Connect, it also knows which Figma component maps to which component in your codebase. When you add code syntax to your variables, it knows that brand-blue in Figma is color-brand-blue in your CSS.
The first time I watched it reach for the right component without me having to specify it, I actually went back and read the output a second time. It had used the correct button variant, applied the right spacing token, and the code was referencing the actual component from our library. Not a recreation. The real one.
That's the difference. And it's a big one.
The two tools you'll live in
There's use_figma, which lets Claude Code create or edit designs directly on the Figma canvas using your real components and variables. You describe what you want and the agent builds it from your actual design system. This is the one that changes how fast you can scaffold new screens.
And there's generate_figma_design, which goes the other direction. Give it HTML from a live app or website and it translates it into editable Figma layers. We had a feature that had been built in code but never fully updated in Figma, and running this gave us a starting point in about thirty seconds that would have taken a designer a couple hours to do manually. Not perfect, but genuinely useful as a starting point.
Together they close a loop that I didn't fully appreciate until I was actually using it. Code to canvas. Canvas to code. A developer spins something up, brings it back to Figma, a designer fills in missing states and edge cases with real components, it goes back to code with the design context still attached. That whole cycle is tighter now in a way that I didn't expect to matter as much as it does.
Where it breaks and why
Here's the thing Figma's documentation says pretty plainly, and they're not wrong: MCP can only work with the context it's given.
That sentence doesn't fully land until you've watched an agent confidently reproduce the worst parts of your Figma file at scale. A layer you named "Frame 1337" because you were going to rename it later. A component that was detached from the library and never reconnected. A spacing value that someone hardcoded because the token didn't exist yet and then nobody went back to fix it. The agent picks all of that up and runs with it.
Before MCP, a messy layer was a localized problem. A developer caught it during implementation and moved on. Now that an agent is generating code from your files, that same messy layer gets reproduced everywhere it shows up. It stops being a one-time fix and starts being a pattern.
I spent two days cleaning up Figma files I thought were in good shape. They weren't.
There's also a non-determinism issue that's worth being upfront about. The same prompt doesn't always give you the same output. Figma's answer to this is Skills, which are markdown files you write to constrain how the agent behaves and document the conventions it needs to follow. The foundational one is /figma-use and everything else builds on top of that. Writing useful skills is real work. It's not a twenty-minute configuration thing.
And there's a setup list that nobody front-loads enough: layer naming throughout has to be meaningful, you need real library components and not detached instances, Code Connect has to be configured so the component mappings are explicit, you need code syntax on your Figma variables so token names actually pass through correctly, auto layout has to be used consistently, and any component with non-obvious states or interactions needs annotations because the agent can't infer behavior from a static frame.
Auditing my own files against that list was not a fun afternoon.
What I'd actually tell someone considering this
The workflow is real. The wins on scaffolding new screens and syncing code with designs are legitimate. For teams that have put real investment into their design system, this is probably the highest-leverage addition you can make to your design-to-code process right now. I'm not exaggerating that.
But it's not something you drop on top of whatever state your files are in and watch it work. The messier your design system, the more this will frustrate you before it helps you. And the cleanup it forces isn't optional, it's the prerequisite.
The slightly unexpected upside is that the cleanup has value completely separate from the AI workflow. Clean naming, real components, documented conventions, those things make your files better for your designers and developers too. The AI workflow just makes the cost of skipping that maintenance immediate and visible instead of slow and deferrable.
If your design system is already in solid shape, I'd start this week. If it's not, the honest answer is that you have upstream work to do first, and no amount of clever prompting will skip that step.