Paper MCP vs Figma MCP for frontend agents

A design MCP server gives a coding agent the tools of a design program, so it can lay out a page on the canvas and read that design back as frontend code. The premise is that an agent working this way builds better frontends. The Figma MCP server is most designers' default server platform, and the Paper MCP server is a newer design tool.

Figma was built for humans clicking in a canvas, and under the hood it stores designs in its own proprietary format. So an agent designing in Figma works through a translation layer, turning its intent into Figma shapes and then exporting that back out to code, either by copying CSS out of Dev Mode or by mapping components through Code Connect, Figma's system for linking design components to the ones in your codebase. That step is imperfect by definition, because the gap between Figma's component model and your production framework has to be bridged somewhere. And the newer direction, an agent pushing design onto the canvas instead of reading it out, is still in beta.

Paper is newer, and its canvas is HTML and CSS. There's no proprietary format in the middle. The agent designs by writing the same code it will eventually ship, and when it reads the canvas back it gets the actual CSS values on each element. A card on the canvas is already a div with CSS, and Paper's get_jsx tool hands it back as component code directly.

I ran an independent eval to test which MCP server is better. Here is what I found.

Main takeaways

• Paper holds its quality across page types, while Figma drops on the complex designs. Paper barely moves from simple pages to complex ones while Figma slips further, though the two still tie on average and Figma's drop traces to a couple of designs where it collapsed outright rather than a broad weakness.
• On ordinary webpages, the design MCP doesn't matter. On visual similarity, a 0 to 1 score of how closely the recreation resembles the original (1.0 is identical), Paper averages 0.741 and Figma 0.744 across 40 pages.
• On complex, design-heavy pages, the tools tie too. Across 27 designs, Paper averages 0.716 and Figma 0.679, and the paired difference does not clear significance (p = 0.21).
• Where the tools genuinely separate is consistency and price. Figma's run-to-run variance is about 1.9 times Paper's, and it runs 42% longer while costing 32% more per point of visual quality ($3.73 vs $2.82).
• Both agents developed visual self-correction unprompted, screenshotting their own canvas to compare against the reference. But across 160 runs, the correlation between how often an agent checked and how good its page came out is effectively zero.
• The two tools write different HTML dialects. Figma produces semantic tags at over 3 times Paper's rate.

The test setup

For each run, the agent gets a screenshot of a webpage and must recreate it as a single self-contained HTML file. The prompt requires building the design in the MCP tool first, then deriving the HTML, because early smoke tests showed agents skip design tools entirely when given the choice. Each variant sees exactly one MCP server, enforced with strict MCP config.

Dataset one, simple pages: Design2Code, the academic benchmark from Stanford's SALT-NLP lab. It includes real webpages sampled from Common Crawl, each with a screenshot and ground-truth HTML. It's the standard in screenshot-to-code research (the companion repo has 586 stars, and follow-up benchmarks measure against it). However, these pages predate modern design trends. One thing to know before you look at the sample below is that Design2Code strips the real photos out and replaces them with solid blue placeholder boxes, and the agents are told to treat those boxes as placeholders. I sampled 40 pages from the benchmark with a fixed random seed, so the subset is arbitrary but reproducible.

Dataset two, complex designs: 27 pages I hand-picked for the textures that stress CSS-first workflows like glassmorphism, 3D-rendered elements, volumetric glow, dense dashboards, and display typography. The set mixes shots from dribbble and hero sections from live sites. No ground-truth HTML exists for these, so the reference screenshot doubles as the scoring target. Because 27 designs is still a small dataset, each one ran three times per tool, and every number reported below is the mean across those trials, which steadies the estimates and turns run-to-run consistency into a measurable finding of its own.

How it's scored

CLIP is a model from OpenAI that maps images into a numerical space where similar-looking images land close together. The closeness of the two image vectors becomes a 0 to 1 score. The judge runs claude-sonnet-5 at temperature 0 with both screenshots in one message. Its prompt, verbatim:

You are comparing two webpage screenshots. Image 1 is the ORIGINAL webpage. Image 2 is an attempted RECREATION. Question: would someone familiar with the original page recognize the recreation as that page? Judge on: overall layout structure, content hierarchy and placement, color scheme, and presence of the main sections and content. Ignore: font-rendering differences, minor spacing, and placeholder images standing in for real photos. Respond with JSON only: {"faithful": "yes" | "no", "reason": "<1-2 sentences>"}

One calibration step I'd recommend to anyone building visual evals is to feed your scorers a known-perfect answer first. I scored the dataset's own ground-truth HTML against its own screenshot. It got 1.0 on everything except visual similarity, where it got 0.93. Even a pixel-perfect recreation can't hit 1.0 on CLIP, because re-rendering produces slightly different pixels. So 0.93 is the real ceiling, and an agent at 0.85 is closer to perfect than it looks.

How the harness works

Each eval row spawns a fresh Claude Code session as a headless subprocess with exactly one design MCP attached. The whole comparison comes down to a few flags. --strict-mcp-config guarantees the agent sees only its assigned server, and the tool allowlist is identical for both variants.

cmd = [
    "claude", "-p", prompt,
    "--model", "claude-sonnet-5",
    "--mcp-config", f"{variant}.mcp.json",   # exactly one design MCP
    "--strict-mcp-config",
    "--allowedTools", f"Read,Write,Edit,Bash,mcp__{variant}",
    "--permission-mode", "acceptEdits",
    "--output-format", "stream-json", "--verbose",
    "--settings", "trace.settings.json",     # tracing config, below
]
proc = subprocess.run(cmd, cwd=workdir, env=scrubbed_env, timeout=1500)

Tracing happens at two levels. The Eval() run logs each row to a Braintrust experiment with its scores, the rendered screenshot next to the reference, and tool-usage counts. For the agent's internals, the trace-claude-code plugin hooks every turn and tool call inside the subprocess and streams them to Braintrust, so you can open any run and read each MCP call with its inputs and outputs. One caveat is that the plugin writes to the project's logs, not into the experiment itself, so the harness stitches the two together by putting a permalink to the agent's full internal trace in each experiment row's metadata.

span.log(metadata={
    "tools_used": tools,
    "mcp_tool_calls": mcp_calls,
    # plugin traces land in Logs, not the experiment,
    # so link each row to its agent's internal trace
    "agent_trace_url": f"{APP_URL}/logs?r={session_id}",
})

Every claim in this post about what agents did mid-run (from the self-check loops to what happened during failed runs) comes from reading those traces.

Results on simple pages

Remember all scores run 0 to 1, higher is better, and that the visual similarity's practical ceiling is 0.93. Though the results ended in a tie, the traces were more interesting than the scores. Two behaviors stood out.

Both variants developed visual self-correction. Unprompted, agents screenshot their own canvas and compare against the reference. Paper agents did this 3.4 times per session, Figma agents 2.4 times. The agents treat the design tool as a feedback loop, not only an output surface.

The tools produce different HTML dialects. Figma's pipeline writes semantic HTML5. Paper's iterative canvas approach produces layouts built almost entirely from generic <div>s.

<!-- figma -->
<header class="topbar">
  <p>Stage One contract acts as…</p>
  <div class="brand"><span class="icon"><svg …>

<!-- paper -->
<div class="top-bar">
  <p>Stage One contract acts as…</p>
  <div class="brand-mark"><svg class="house-icon" …>

Across the 248 HTML files the agents produced over the course of the eval, including retried runs, Figma uses semantic tags at over 3 times Paper's rate. Paper's output is 46% <div>s to Figma's 35%. Both render identically well.

A <div> is a generic box that says nothing about its contents, whereas semantic tags like <header>, <nav>, and <main> declare what the content is. They look identical on screen, but machines read them differently. Screen readers use semantic tags as landmarks, so someone relying on one can jump straight to the main content instead of stepping through every box on the page (class names like top-bar don't help, because assistive tech ignores them). A developer opening the file months later gets the page's architecture easily instead of reverse-engineering it from class names.

So essentially, Figma's generated code is the more accessible and more maintainable of the two in this eval, even though both sets of pages render the same.

Results on complex pages

Here are the numbers across all 27 designs at three trials each.

On visual similarity, this is a tie as well, just a more textured one. Paper's average visual similarity sits a few hundredths above Figma's, and the paired test across the 27 designs puts the gap at +0.038 with p = 0.21, meaning a difference this size would show up about 21% of the time even if the tools were genuinely equal. That is nowhere near the conventional 5% significance bar, so the defensible claim is that the tools are statistically indistinguishable on average visual quality here. The average alone misses the shape of the distribution. The two largest per-design margins in the entire eval both belong to designs where Figma collapsed outright, the 3D robots (aiaf) and the flat illustration (park), while everywhere else the margins are small and go in both directions. Figma has occasional collapse modes on specific design types rather than a general weakness on complex pages, and the two tools otherwise tie.

Since those two collapses drive the shape of the whole comparison, I read all six of those Figma traces to see what happened. On park, all three trials collapsed the same way (0.09, 0.20, and 0.04). The agent built the full illustration correctly (the bridge, the sunburst, the court, the lettering) then created an HTML page where that artwork renders as a small badge floating in an empty canvas. The agent got the content right and the scale wrong. This is because a Figma composition has a fixed frame size and nothing forces it to fill a browser viewport when it becomes HTML. Two of those trials self-checked six and eight times and still shipped the miniature, which makes sense once you notice that the checks screenshot the Figma canvas, where the composition genuinely looks right. On aiaf, the story is variance rather than repeatable failure. Two trials landed around 0.44 with the robots flattened but the page structure intact, and one went down to 0.09 by rendering the whole page as a narrow column surrounded by empty space. Paper, whose canvas is already a viewport-shaped HTML page, never produced either failure mode.

Where the tools genuinely separate is consistency and price. Figma's output varies about 1.9 times as much from one run to the next as Paper's. Given the same design and the same prompt, Paper produces roughly the same page each trial, while Figma's quality swings more between draws. Figma also runs 42% longer and costs 32% more per point of visual quality. Also, while CLIP reads the tools as a tie, the judge preferred Paper's recreations (0.728 to 0.654). The paired faithfulness gap is +0.080 at p = 0.17, so it isn't significant either, but it leans consistently toward Paper.

Digging deeper

The self-correction behavior turned out not to help on the complex designs either. Across the 160 complex-design runs where the harness captured self-check counts (a few runs lost that telemetry to logging failures), the correlation between how many times an agent checked its own canvas and its final visual similarity score is r = +0.01 for Paper and r = −0.19 for Figma, and neither is statistically meaningful. So the self-checking does not translate into a better page. If anything, the Figma agents that check the most tend to be the ones struggling with the hardest designs, which is why that relationship, to the extent there is one at all, leans slightly negative.

Breaking the results down design by design shows where each tool wins, and the size of each margin matters as much as its direction. On most of the 27 designs the two tools finish close together, with small wins scattered in both directions. The two huge margins are the 3D robots (aiaf) and the flat illustration (park), where Figma broke down. On the park illustration in particular, Figma's three trials averaged 0.11, which means its recreations barely resembled the target at all. No other design comes close to either collapse, in either direction.

On the park illustration, Figma reproduced the artwork but shrank it into a small thumbnail stranded in empty space, while Paper rebuilt the whole poster at full scale. That single difference accounts for most of the 0.58 gap on this row.

park, flat illustration. Paper 0.69, Figma 0.11.

Understanding the limits of CSS

The lowest-scoring designs in the whole eval were not failures of either tool. They mark the limit of what the output medium itself can express. One dribbble page features three 3D-rendered robot heads with brushed metal, chamfered edges, and eyes emitting pink light that reflects off nearby surfaces.

Art like that is never made in a design tool in the first place. The real workflow runs through a 3D program (Blender, Cinema 4D, Spline), where a designer models the objects, assigns materials, lights the scene, and renders the result to an image. On the actual shipped site, those robots are a flat PNG dropped into the page, not code at all. Real design work divides the labor this way, using CSS for structure and layout and pre-rendered images for the parts that need photographic richness.

CSS is a procedural medium, meaning it draws its effects from rules rather than from stored pixels. It is good at frosted glass (backdrop-filter plus layered translucent shadows), glow (stacked radial gradients with blend modes), grain, and even refraction through SVG filters. What it cannot do is express photorealistic lighting, metallic reflection, or anything else that a renderer produces by simulating how light actually behaves. When the agents rendered the robots as flat gray shapes, they were running into the boundary of what HTML and CSS can express. It was not a shortfall in their own ability, and a stronger model or more attempts would not have changed the outcome, because the medium cannot produce that image.

I did chase one path that could raise this CSS ceiling. Figma has real shader support in open beta, with WebGPU shader fills for these materials (liquid glass, chrome, aurora), a first-party gallery, and a complete plugin API that an agent could use to list, import, and apply them. So the whole pipeline exists from end to end. I still couldn't use it in this eval because the beta wasn't enabled on my account, and even with it enabled, shader IDs are scoped to a specific file, so an agent starting from a fresh file has no way to reach them. The capability is close, but it is not yet usable by an agent. Paper, for its part, exposes no material system through its MCP at all. Its canvas is CSS under the hood, so its texture ceiling is the CSS ceiling.

What this means in practice

Paper is more consistent run to run and about 30% faster, while Figma costs about 32% more per point of visual quality. The faithfulness judge leaned toward Paper throughout. Figma writes more semantic, more accessible markup, and its worst failures in this eval were collapse modes on specific design types (a flat illustration, 3D character art) rather than a general quality problem.

Diagnosing those collapse modes is the part Braintrust made easy. Every agent subprocess streamed its full internal trace through the trace-claude-code plugin, so each experiment row links to every MCP call the agent made, with its inputs and outputs. And because the rendered output and the reference screenshot sit side by side as images in each row, answering questions took a few minutes of opening rows and looking.

If you're building an eval like this one, Braintrust is the AI observability platform that connects evals and observability in one workflow, from the experiment scores down to each agent's individual tool calls. Get started →

Appendix

Below is the full gallery. Each entry shows one of the 27 complex designs, with the reference next to each tool's best recreation out of its three trials. The scores under each design name are the mean visual similarity across trials, the same numbers used throughout the post, while the images show each tool's single best attempt.

agentcard, dark hero for an AI-agent debit card. Paper 0.78, Figma 0.82.

aiaf, dark landing page with three 3D robot heads. Paper 0.70, Figma 0.32.

amanah, tilted CRM dashboard. Paper 0.88, Figma 0.84.

bronn, light fintech accounting hero. Paper 0.82, Figma 0.87.

canton, blue enterprise page with a radial network graph. Paper 0.66, Figma 0.59.

chenard, dark editorial page with book spines. Paper 0.74, Figma 0.72.

defi, dark glassmorphism DeFi hero. Paper 0.84, Figma 0.85.

drone, dark drone fire-monitoring dashboard. Paper 0.68, Figma 0.61.

food, orange food app on three phones. Paper 0.75, Figma 0.57.

games, puzzle games card grid. Paper 0.84, Figma 0.86.

grocer, flat illustration of grocery bags. Paper 0.87, Figma 0.86.

horsecare, phone mockup on a wooden rail. Paper 0.70, Figma 0.64.

inspirux, black and lime editorial hero. Paper 0.69, Figma 0.69.

kaiko, blue gradient healthcare hero. Paper 0.84, Figma 0.88.

liquid, glassmorphism swap widget over a grassy field. Paper 0.84, Figma 0.86.

lydia, blue halftone portfolio hero. Paper 0.62, Figma 0.76.

med, dark typographic page with a small athlete figure. Paper 0.70, Figma 0.64.

medium, bold stacked type cards. Paper 0.72, Figma 0.72.

nirnor, minimal Japanese page with a particle field. Paper 0.74, Figma 0.63.

park, green and yellow flat illustration poster. Paper 0.69, Figma 0.11.

radial, radial topic graph visualization. Paper 0.85, Figma 0.82.

sondaven, ASCII halftone artwork of stacked sheep. Paper 0.71, Figma 0.53.

spatial, black and white warped type poster. Paper 0.54, Figma 0.66.

stageone, editorial split-screen interior page. Paper 0.54, Figma 0.61.

supari, orange illustrated studio hero with cartoon characters. Paper 0.40, Figma 0.47.

units, colorful student housing hero. Paper 0.62, Figma 0.70.

worldbuild, editorial services table with icons. Paper 0.58, Figma 0.68.