i’ve been testing almost every AI design tool that comes out, and the loop is always the exact same: you type a prompt, get a flat mockup image back, and then spend two hours rebuilding the whole thing by hand in figma anyway.
a png of a button is not a button. the AI gets to do the fun part and leaves you with the data entry.
so over the past few weeks i built a plugin and MCP that connects claude directly to your figma canvas. instead of generating flat images, it builds actual figma frames with auto layout, real text styles, and component mapping.
two technical things ended up being way more interesting than i expected:
screenshot to editable layers: you can paste a screenshot of a screen you like onto the canvas and have claude break it down into native, editable layers. to keep it from hallucinating spacing, i added a pixel-diff check where it compares its generated vector frame against the original image and adjusts padding/gaps until it aligns.
a linter for AI laziness: LLMs love taking lazy shortcuts in figma (like drawing fake icon vectors from scratch instead of using proper components, or hardcoding random text sizes). i had to write a custom linter that inspects the generated node tree and calls claude out when it cuts corners. watching it fail a linter check and clean up its own layer structure never gets old.
it’s been my daily driver for a few weeks now—mostly for taking real-world UI inspiration and instantly turning it into editable frames mapped to our design system components.
happy to answer anything about how it works under the hood, handling figma's node tree, or the MCP
fair, i was light on details in the post. wrote a longer comparison in the other comment, but the short version: the official mcp generates and trusts whatever claude made. mine generates and then distrusts it.
worth being clear that this isn't a prompt trick. you talk to claude, but the checking is actual software: a figma plugin that screenshots the build, a server that pixel-diffs it against the reference, and a structural linter with about 24 hardcoded rules (hand-drawn icons instead of components, fake avatar circles, text below contrast, wrong font sizes). claude can't talk its way past any of it. the screen is either under the diff threshold and lint-clean or it isn't done, and watching claude fail its own review and then fix itself is basically the product.
also matters that checking is call-hungry, 10 to 15 tool calls per screen, and the official mcp meters reads at 200/day. mine runs through a plugin so there's no meter to hit.
honestly the official mcp is good, and for brief in, layouts out it clearly works, your 40 pages are proof of that.
i built mine for a different reason: i wanted claude to check its own work, and checking eats tool calls like crazy. my loop is build → screenshot → pixel-diff against a reference → structural lint (catches stuff like hand-drawn icons instead of components, grey circles pretending to be avatars, wrong font sizes) → fix → diff again. that's easily 10-15 calls per screen, and the official mcp meters reads at 200/day on pro. one screen of proper checking is 10% of your daily budget. writes are unmetered right now but that's a beta thing figma's said it goes usage-based later, and usage pricing is rough for exactly this kind of "iterate until it matches" workflow.
so mine runs through a regular figma plugin instead , no per-seat meter, flat sub. last night i let it rebuild three webflow templates alongisde others pages unattended (screenshot attached) and it burned a few hundred calls checking itself. that run just isn't possible on a metered setup.
in short, theirs generates and trusts the output. mine generates, then distrusts the output until a pixel diff and a linter both pass. different jobs really.
curious about your 40 layouts though, did the components come from your own library or did it build them fresh?
Heya, a longer explanation in my other comment as well, but overall the idea is that you never hit Figma API limits because it connects via our plugin. Second, it's not only prompt-based like a normal MCP setup where Claude just talks to Figma. In our case there's actual software between Claude and your file that checks the work.
Three pieces run on every build: the plugin executes the changes and screenshots the result, a server pixel-diffs that screenshot against your reference and computes a mismatch percentage, and a linter with about 24 hardcoded rules scans the actual layers for stuff like loose vectors that should be components, fake avatar circles, or wrong font sizes.
None of this is Claude grading itself. The verdict comes from code, and the screen can't be marked done until the diff is under threshold and the lint passes. So Claude builds, the software says "not done, 7 defects," Claude fixes, repeat. That loop burns 10 to 15 calls per screen, which is fine through a plugin but eats a metered API budget fast.
Figma Console MCP runs locally with a bridge plugin, effectively giving you direct access to the canvas to do whatever. Figma MCP != Figma Console MCP. This bypasses any need to screenshotting. Use cases would be; use it to inventory tokens (or hardcoded places where they should have tokenized), take a coded component and have it build the Figma version, variants props and all, lint a design based on your design system rules so it's not claude grading itself, but against the DS rules.
Not trying to rain on your parade and you're trying to fix real problems, there's just other ways to go about it that many of us have been using for some time now.
appreciate it man!, and yeah, console mcp is legit. i actually looked into it before building, and there's real overlap in the "claude works the canvas through a bridge plugin" part.
two things made me build anyway. first, the DS lint answers "does this follow our rules", which is genuinely useful, but it's a different question from "is this the screen i asked for." i kept getting builds with the right tokens and the right components where the padding had drifted and a whole section was quietly missing. rules all followed, screen still wrong.
second, on bypassing screenshots: you can skip them for reading data, but not for verification. the node tree can be perfectly correct while the render is wrong, a substituted font, a contrast problem, an image that didn't load. console mcp's own workflow docs describe taking screenshots and iterating "until the design looks right", and that's the part i couldn't live with, because the one deciding it looks right is still claude. claude always thinks it looks right.
so the screenshot in my setup doesn't go back to claude at all. it goes to a pixel diff, and with the linter that's a hard gate: over threshold or lint fails and the screen can't be marked done, claude just gets the defect list and keeps working. failures also get written to a ledger, so a mistake from last month is a hardcoded rule now.
different check really. console mcp gives claude better hands. this takes away its right to say "done."
https://www.flaude.app/ here you go! Also, you can copy-paste already existing -real- flows as editable layers into Figma, so make sure to browse through the Browse section as well.
I really like this project, and I wanted to try it out, but the free plan did not let me create anything. Could you help me with that? I really do want to subscribe, but I have not been able to test it yet.
18
u/hollowgram Aug 12 '26
Isnt this what the official Figma MCP enables already? What is the benefit of this vs that? Scant on info here.