the best MCP servers for designers and frontend engineers

Most roundups of design MCP servers are the same three tools with the ranking shuffled. That hides the interesting part: these servers do genuinely different jobs, and a designer or frontend engineer usually wants two or three that cover different gaps, not a single top pick. This is an honest tour of what each does and where each leaves you stuck.

what an MCP server does for design work

The Model Context Protocol is a standard way for an AI coding agent (Claude Code, Cursor, Codex) to call tools mid-task instead of working from whatever you pasted into the chat. An MCP server is a small program that exposes those tools. When your agent hits a wall it cannot answer from training data, a stale hex value, the real structure of a Figma frame, the live DOM of a running app, it calls a server and gets grounded data back.

For design and frontend work the failure mode is specific. Ask a raw model to build UI and it reaches for the same defaults every model ships: centered hero, violet gradient, three feature cards, rounded-2xl on everything. It is not that the model has no taste. It has no context. MCP servers feed it that missing context, from your Figma file, a component library, a live browser, or a page you admire on the open web.

the roundup at a glance

Three is the sweet spot. Past five, the token overhead of all those tool definitions costs you more than it gives. Pick by the gap you actually have.

Figma MCP: your design system as the source of truth

Figma's official Dev Mode MCP server exposes the live structure of whatever you have selected in Figma: the node tree, variants, auto-layout rules, text styles, spacing tokens, and component references. As Builder.io's writeup puts it, your agent generates code against the real design instead of guessing from a screenshot, reading what a picture cannot carry: layout constraints, variable bindings, the difference between a component and a one-off.

If your team's source of truth is Figma, this is the first server to install. The honest limit is in the premise: it only helps when the design already lives in Figma as clean layers. It does nothing for the reference you found on the open web, the competitor's pricing page, or the site whose motion you want to understand. For that you point at a live URL, not a Figma file.

uiscanner: give the agent taste from any live page

This is the gap the standard lists miss. Figma MCP grounds the agent in a design you already built; uiscanner grounds it in one you admire but do not own. Paste any public URL and it returns a full teardown: tokens (colors, fonts, type scale, radii, spacing, shadows, motion), a section-by-section structure, and a build prompt written to recreate the look in your own stack.

It beats a screenshot-to-code pass because of how it reads the page: the rendered page (vision) and the DOM together, so it catches what a code scraper misses, the real primary button rather than the first one in the source, whether the hero is centered or split, and which imagery is decorative (with prompts to recreate it as originals). It is transformative by design: it describes and tokenizes a page and never copies or re-hosts the original site's asset bytes, so your agent receives a system to build with, not a mirror of someone else's site.

Install it in Claude Code with one line:

claude mcp add uiscanner -- npx -y uiscanner-mcp@latest

It is a stdio server, so there is nothing to host and no remote URL to paste. The same one-liner works for Cursor and Codex, on the setup page. You get five tools: ui_teardown(url, target?) runs a scan, ui_probe(url) is a cheap preflight that spends no scan, get_teardown(id) re-fetches a finished one, retarget_teardown(id, target) re-aims the build prompt at a different archetype (landing, dashboard, marketing, ecommerce, portfolio, mobile, general) without re-scanning, and whoami() reports your plan. Only ui_teardown spends a scan. There is also a CLI:

npx -y uiscanner-mcp@latest scan stripe.com --target landing

Every scan returns an id and a shareable uiscanner.com/t/<id> link. Scans are metered per plan on a rolling 30-day window, unified across the web app, MCP, and CLI: Free 5, Indie ($12/mo) 100, Studio ($39/mo) 400. Browse example teardowns for the output shape, including the Stripe and Cursor breakdowns.

Playwright MCP: drive a real browser

Playwright MCP is Microsoft's official browser-automation server and one of the most popular in the ecosystem. It lets your agent open a page, click, type, and assert against a structured accessibility tree instead of slow screenshots: visit localhost:3000, log in as a test user, confirm the dashboard renders.

This is the testing and verification layer. It is not a design tool: it acts on a page, it does not tell you what a page's design system is. Pair it with a design-context server and you have both halves, the agent knows what to build and can then check that it built it.

Chrome DevTools MCP: debug the running app

Chrome DevTools MCP connects your agent to a live Chrome session over the DevTools Protocol: it reads the DOM, inspects console errors, watches network requests, and pulls performance data. When the built page looks wrong (a slow Largest Contentful Paint, a layout that breaks at a breakpoint), this gives the agent eyes on the runtime. It is the debugging counterpart to design context: uiscanner tells the agent what the target should look like, this tells it what the build is doing. The catch is that your app has to be running.

shadcn MCP: move fast inside one system

The shadcn MCP server gives your agent direct access to the shadcn/ui registry: browse, search, and install components and blocks, pulling real source and docs rather than hallucinating props. It is deliberately scoped: it knows shadcn and the registries you point it at, not design in general. It pairs well with a design-context server: use uiscanner or Figma MCP to decide what the thing should look like, then shadcn MCP to assemble it.

Context7 MCP: stop shipping stale patterns

Context7 pulls current, version-specific documentation into the agent's context so it stops writing API calls from year-old memory. It is not a design server, but half of "the AI wrote broken code" is really "the AI used a deprecated pattern." For fast-moving frameworks it is a cheap reliability win.

how to actually assemble a stack

Do not install all six. Pick by the gap. If your designs live in Figma, start with Figma MCP. If you learn from sites across the open web, start with uiscanner. Add Playwright or Chrome DevTools MCP to verify or debug the result, shadcn MCP if that is your component system, and Context7 to keep the code current. Two or three, chosen for different jobs, beats a pile of overlapping servers.

None of these are magic. They each hand your agent one kind of grounded context it did not have. The design-taste gap, the one that makes AI UI look generic, is the one most stacks leave open, because Figma MCP only covers designs you already own. That is the gap uiscanner fills: any live page, tokenized and structured, handed to your agent to build from honestly. For the comparison against inspector tools, see uiscanner vs Snable; the teardown gallery shows the output first.