Skip to main content
MCP

Design with Claude Code + Playwright MCP: full workflow

Step-by-step workflow to visually validate a Claude Code component with Playwright MCP: multi-viewport screenshots, critique, iteration, a11y check.

  • Tutorial
  • Tooling
Published

Actionable TL;DR

  • The pivot: no design skill ships correct visuals 100% of the time. Playwright MCP closes the loop by showing Claude the real render.
  • The minimum: browser_navigate to your local preview, then browser_take_screenshot. Claude critiques, you iterate.
  • The full version: add multi-viewport (browser_resize), an a11y check via browser_evaluate, and a before/after screenshot for the PR.
  • Setup: Playwright MCP ships in the standard "dev" profile. Check with /mcp inside Claude Code.
  • Pair it with: Impeccable, Taste Skill or UI UX Pro Max for generation.

Why Playwright belongs in the design loop

A design skill dresses up a component, but it works blind: it never sees what the browser actually renders. Playwright MCP is the mirror you hand Claude after it has styled a component. Without the mirror, Claude guesses. With it, Claude sees exactly what the browser shows on mobile and desktop, and fixes things before you open the page yourself.

The pipeline is a handful of steps repeated in a loop:

Brief

Describe the component you want

Generate

The design skill writes the code

Capture

Playwright multi-viewport screenshot

Critique

Claude reads the render and finds flaws

Iterate

Targeted regeneration

Done

Ready for the PR

Setup

Playwright MCP ships in the standard "dev" profile of Claude Code. To confirm it responds, type /mcp inside Claude Code: you should see playwright in the list of active servers.

From a clean machine, the ad hoc route:

npx @playwright/mcp@latest

On the design side, install the skill that fits your need before you start:

npx skills add pbakaus/impeccable

The workflow, two levels

The full workflow is nine steps, but you don't always need all of them. The quick version is enough for a 10-minute visual check. The full version adds multi-viewport, a11y and the commit, for a component headed to production.

Quick version (10 min)

1

Generate the component

Short design brief, then generate via your skill: /impeccable craft "minimal product card with hover". Claude writes the component into your project.

2

Run the preview and navigate

Start the server (npm run dev), then ask Claude to open the page with the browser_navigate tool on the local URL (for example http://localhost:3000/preview).

3

Capture and critique

Claude takes a screenshot with browser_take_screenshot, reads it, and lists the visible flaws (contrast, alignment, hierarchy). You iterate by re-running a skill command (/polish for instance). Two passes are often enough.

Full version (9 steps)

1

Check the MCP

/mcp inside Claude Code: confirm playwright is active. Install the chosen design skill if you haven't already.

2

Write the brief

Describe the component, its constraints, and a visual reference if you have one (a local image read via the MCP filesystem tool).

3

Generate

Invoke the skill: /impeccable craft "..." or the Taste / UI UX Pro Max equivalent. Claude produces the component.

4

Capture multi-viewport

Server running, Claude uses browser_navigate on the route, then browser_resize to 375x800 (mobile) and browser_take_screenshot, then browser_resize to 1440x900 (desktop) and a second screenshot.

5

Visual critique

Claude reads both captures and names the flaws: low contrast, broken alignment on mobile, weak type hierarchy, uneven spacing.

6

Iterate

/impeccable polish or /taste critique with the identified diff. Claude regenerates the component. Back to step 4. Two to four loops are typical.

7

Accessibility check

Claude runs axe-core in the page via browser_evaluate (inject then axe.run()), and verifies zero WCAG 2.1 AA violation on the component.

8

Before/after capture

Keep the first screenshot and the last. The visual diff is the proof in the PR.

9

Commit

Component ready for PR, with the before/after captures in the comment.

The MCP tools used

All these tools come from the @playwright/mcp server. Claude calls them for you; you describe the intent, it runs them.

ToolRole in the loop
browser_navigateOpen the local preview route
browser_resizeSet the viewport (mobile, tablet, desktop)
browser_take_screenshotCapture the render for critique
browser_snapshotFetch the accessibility tree (text alternative to the screenshot)
browser_evaluateRun JS in the page, including axe-core for a11y
browser_console_messagesRead console errors that skew the render

For details on each MCP and its configuration, see the MCP section and building your first MCP workflow.

Advanced use cases

Systematic multi-viewport. A card that looks fine on desktop often overflows at 375px. Always capture both. Mobile reveals type hierarchies that are too tight and paddings that stop breathing.

Runtime a11y check. The screenshot doesn't tell you everything: a borderline contrast passes the eye but fails axe-core. Running axe.run() via browser_evaluate catches those violations before the PR. It's a complement, not a replacement for visual critique.

Regression captures. On The Claude Codex project, Playwright captures also feed visual regression (low tolerance threshold). So the same tool serves to design and to lock the render over time.

Limitations

  • The screenshot is not the user's browser. System fonts, display scaling, extensions: Playwright captures a controlled environment, not a real visitor's machine.
  • Automated a11y catches only part of the problems. axe-core judges neither the relevance of an alt text nor keyboard navigation logic. Human critique stays necessary.
  • MCP attack surface. Handing an agent a drivable browser has security implications. Before using it on sensitive or authenticated pages, read MCP security.
  • Moving versions. The MCP API evolves fast (v0.0.75 as of 2026-06-03). A tool name may change between two versions; check the up-to-date list on the official repo.

Next steps