Blog · · 8 min

The MCP servers worth installing for frontend work

Four are worth the config line. Chrome DevTools MCP so the agent looks at the rendered page instead of the code, Playwright MCP when the flow has to be driven repeatably, Figma Dev Mode MCP only if a Figma file already exists, and shadcn MCP as a transport to any component registry. Everything else on the shelf is an index.

By

Four. Not twenty.

Chrome DevTools MCP is the one that changes the most, because it lets the agent look at the page it just built rather than at the code it just wrote. Playwright MCP overlaps with it and earns its place for a different job: driving a flow the same way twice. Figma Dev Mode MCP is the highest-quality source of truth an agent can be handed, and only if a Figma file already exists. shadcn MCP is not a component library, it is a pipe to whichever registries you declare.

Below, what each one refuses to do, which is the part the directories leave out.

What does each one actually change?

ServerInstallWhat it makes possibleWhat it will not do
Chrome DevTools MCPnpx -y chrome-devtools-mcp@latestThe agent navigates, screenshots, reads the console and network, records a performance traceHave an opinion about what it sees
Playwright MCPnpx @playwright/mcp@latestA buying path clicked end to end, repeatably, headless, in CIPerformance traces or DevTools-grade network detail
Figma Dev Mode MCPStarted from the Figma desktop appReal spacing, real tokens, real component names instead of the model's defaultsExist without a designed file and a paid seat
shadcn MCPpnpm dlx shadcn@latest mcp init --client claudeSearch and install from any registry declared in components.jsonContain any components of its own

Why is Chrome DevTools MCP the first one?

Because without it the agent is writing blind. It edits a stylesheet, reasons about what that stylesheet ought to produce, and reports success. The gap between ought to and does is where most of the wasted turns live.

With it, the loop closes. The agent navigates to your dev server, takes a snapshot, reads the console, sees the 404 on the font file, fixes the path.

claude mcp add --transport stdio chrome-devtools -- npx -y chrome-devtools-mcp@latest

Or, in a project-level .mcp.json you commit so the whole team gets it:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

It needs a current stable Chrome and a Node LTS on the machine, and its official support is limited to Google Chrome and Chrome for Testing. The tool surface is wide — well past fifty tools, grouped into input automation, navigation, emulation, performance, network, debugging, memory, extensions and PWA handling. The three you will actually use most are take_snapshot, list_console_messages and the performance_start_trace / performance_stop_trace pair.

What it does not do: judge. It hands back a screenshot and a trace. Whether the hierarchy is legible, whether the price is competing with the button, whether the page looks generated — none of that is in the tool output. The measurement got solved. The taste did not, and that is a separate problem with a separate answer.

![A cast-iron workbench in hard side light, four steel tools laid in a row on dark slate, each tied with a brass tag stamped LOOK, TOKENS, INSTALL and CLICK, with a fifth blank tag hanging on an empty hook.](/blog/etabli-quatre-etiquettes.webp "Four tools, four tags, and one hook with nothing on it. The empty tag is the selling mechanics: no server on the shelf carries them.")

If I have Chrome DevTools MCP, why Playwright MCP?

Different jobs that look alike from a distance.

Chrome DevTools MCP is an inspector. You point it at a page and ask what is happening: console, requests, layout, a real performance trace with insights attached. It is the tool for why is this wrong.

Playwright MCP is a driver. It works from the accessibility tree rather than from pixels, which makes its actions describable, stable and cheap to repeat. It is the tool for does this still work — the add to cart, the variant change, the coupon field, the payment redirect, run the same way on every commit.

Install both or install neither, but do not install Playwright expecting a profiler, and do not install DevTools expecting a test suite you can run in CI.

What Playwright MCP does not do: tell you the page is slow, or why. No trace, no CrUX field data, no heap snapshot.

Is the Figma MCP worth it?

Only under one condition, and it is a hard one: a real Figma file has to exist, with variables and components in it, and someone has to hold a paid seat with Dev Mode access. If your design lives in your head and three screenshots, this server has nothing to read.

When the condition holds, it is the single strongest input you can give an agent, because it replaces invented values with declared ones. The model stops choosing 16px because 16px is common and starts using the spacing scale the file defines. That is the difference between a page that resembles your brand and a page that is your brand.

It runs locally, started from the Figma desktop app, and the agent connects over HTTP to a port on localhost. Read that port and path out of Figma's own panel rather than copying it from an article — it has changed at least once, and a stale endpoint fails silently as server not found rather than as anything informative.

What it does not do: design. It transports decisions that a human already made. Point it at an empty file and it transports nothing.

What is shadcn MCP for, exactly?

For reaching registries, not for holding components. That distinction is the whole value.

pnpm dlx shadcn@latest mcp init --client claude

Then any registry you declare becomes reachable in conversation:

{
  "registries": {
    "@acme": "https://acme.com/r/{name}.json"
  }
}

Browse, search, install, in plain language, across the default registry, third-party ones and a private company library behind an @internal namespace. If your team maintains its own set of blocks, this is how you put them in front of the agent without asking it to guess file paths.

What it does not do: stock the shelves. It gives you what the registries contain, and what the general-purpose registries contain runs out at the SaaS pricing table. We went through that inventory in shadcn ecommerce blocks: what exists and what is missing.

How do you check a server before trusting a list?

Ask it. Any stdio MCP will list its tools over three lines of JSON-RPC, no client required — the exact command is in the piece on Shopify's MCP servers, where that check turned up a server exposing a single gated tool rather than the dozen its documentation implies.

Do this before adding anything from a directory. A published README and a running tools/list disagree more often than they should.

What none of the four knows

The mechanics of selling.

Every server above operates on the page as a technical artefact. Does it render, does it load fast, does the click work, does the token match, is the component installed. All necessary. None of them contains a single opinion about whether the page takes money.

None of them will tell an agent that the multi-pack should be preselected, that the amount remaining before free shipping belongs in currency rather than as a percentage, that the complement is offered after the add-to-cart and not before, or that the sticky bar on a phone has to carry the price as well as the button. Those are not rendering facts. They are decisions, and no directory on the MCP shelf catalogues them.

That gap is what we are building uxgen for: an MCP that hands a coding agent 168 commerce components as HTML the merchant owns, from $19 a month. No paying customers yet, and the site says so. The four cart mechanics are MIT and readable without installing anything: github.com/kinerette/uxgen-commerce-kit.

FAQ

What is the best MCP server for frontend development?

Chrome DevTools MCP, installed with npx -y chrome-devtools-mcp@latest. It is the one that changes how the agent works rather than what it can fetch: instead of reasoning about what its CSS ought to produce, it navigates to the running page, takes a snapshot, reads the console and network, and records a performance trace. It needs a current stable Chrome and a Node LTS on the machine.

Do I need both Chrome DevTools MCP and Playwright MCP?

They solve different problems. Chrome DevTools MCP is an inspector for diagnosing a page that is wrong: console, network, performance traces. Playwright MCP is a driver for repeating a flow the same way twice from the accessibility tree, which is what you want in CI. Installing both is reasonable; substituting one for the other is not.

Is the Figma Dev Mode MCP worth installing?

Only if a real Figma file exists with variables and components defined, and someone holds a paid seat with Dev Mode access. Under that condition it is the strongest input an agent can get, because it replaces invented spacing and colour values with the ones the file declares. Without a designed file it has nothing to transport.

Does shadcn MCP give me ecommerce components?

It gives you whatever the registries you declare contain, which is the point: it is a transport, not a library. The general-purpose registries stop at SaaS building blocks, so a quantity tier selector, a free-shipping threshold bar, a post-add-to-cart complement or a sticky mobile add-to-cart are not in them. Point it at a commerce registry and the same pipe delivers those.

uxgen is a service of UXGen AI, LLC — 131 Continental Dr, Suite 305, Newark, DE 19713, United States.

© 2026 UXGen AI, LLC. All rights reserved.