I spent Monday evening doing something I’d been meaning to try for weeks: installing my first MCP server. Specifically, the Playwright MCP — which gives Claude Code the ability to control a web browser.
The catalyst was a YouTube video by Patrick Ellis: Turn Claude Code into Your Own INCREDIBLE UI Designer. Ellis is the CTO of an AI-native startup whose clients include Google, Coca-Cola, and Disney, so when he calls something “the single biggest frontend unlock” his team has found, it’s worth an evening.
Here’s what I learned — and what I’ve already changed about how I work on this site.
What Is MCP?
Model Context Protocol (MCP) is an open standard, originally developed by Anthropic, that lets AI models connect to external tools and data sources. Think of it as a plugin system for AI. Instead of the model being limited to reading files and running terminal commands, MCP servers give it access to things like browsers, databases, APIs, documentation systems, and more.
The protocol works through a client-server architecture. Claude Code is the client. Each MCP server exposes a set of tools — structured capabilities that the model can invoke when it determines they’d be useful. You can install multiple MCP servers, and the model decides which tools to use based on the task at hand.
Common MCP use cases include:
- Browser automation (Playwright) — navigate pages, take screenshots, fill forms, read console logs
- Documentation lookup (Context7) — pull in library documentation on the fly
- Web scraping (Firecrawl) — extract structured data from websites
- Database access — query and manipulate data directly
- File system tools — extended file operations beyond what’s built in
- Git and GitHub integration — deeper repository interaction
The list keeps growing. The MCP ecosystem is expanding quickly, and both first-party and community-built servers are available.
What Playwright MCP Does
Playwright is Microsoft’s open-source framework for browser automation and end-to-end testing. It has over 76,000 stars on GitHub and supports Chromium, Firefox, and WebKit. The Playwright MCP server wraps this framework and exposes it as a set of tools that Claude Code can call.
With Playwright MCP installed, Claude Code can:
- Navigate to any URL and render the page in a real browser
- Take screenshots of what it built — and actually see the result
- Read browser console logs to catch JavaScript errors or warnings
- Click buttons, fill forms, and interact with the page just like a user would
- Resize the viewport to test different screen sizes
- Capture accessibility snapshots of page structure
That last point deserves emphasis. Without Playwright MCP, Claude Code is designing blind. It writes HTML and CSS, but it never sees the rendered output. It’s working entirely from the code side of its training — which is substantial — but it can’t tap into the visual reasoning it’s also trained on. Screenshots change that equation.
Where It Lives
Playwright MCP runs locally on your machine. When you install it, you’re adding a server process that Claude Code starts when needed. No cloud service, no external dependency, no additional cost. It spins up a browser instance on your PC, does its work, and shuts down.
Installation is a single command:
claude mcp add playwright – npx @playwright/mcp@latest
You can scope it to a single project, share it across a team via a config file committed to version control, or install it at user scope so it’s available everywhere. I installed mine at user scope — I want it in every project.
After installation, type /mcp inside Claude Code to verify it’s running. You’ll see the full list of tools it exposes: roughly 30, covering navigation, screenshots, form interaction, console access, tab management, and more.
What This Means for a Blog Like This
This blog runs on Hugo, a static site generator. I write posts in Markdown, and Hugo compiles them into HTML using the Broadsheet theme. When I make frontend changes — adjusting layouts, tweaking CSS, modifying templates — I’ve been relying on Claude Code to write the code and then manually checking the result in a browser.
That manual verification step is where things get slow. I make a change, rebuild the site, switch to the browser, refresh, evaluate, switch back to the terminal, describe what’s wrong, wait for Claude to fix it, rebuild, check again. It’s a loop, but I’m the bottleneck at every step.
With Playwright MCP, Claude Code can close that loop on its own. It makes a change, navigates to the page, takes a screenshot, evaluates whether the result matches the design principles and style guide I’ve documented in this project, and iterates until it’s right — or flags what it can’t resolve.
I’ve already added instructions to this project’s CLAUDE.md configuration file that tell Claude Code to do exactly this after any frontend change:
- Navigate to all pages impacted by the changes
- Take a screenshot at desktop viewport (1920x1080)
- Compare the rendered output against the design principles and style guide
- Check for console errors
- If discrepancies are found, fix them and re-verify
This is the “iterative agentic loop” that Ellis describes in his video, and it’s the core value proposition. Instead of a single prompt-and-pray cycle, the model writes code, sees the result, identifies problems, fixes them, and verifies again. Autonomously.
The Design Reviewer Subagent
Taking this further, I set up a design reviewer subagent — a specialized Claude Code agent defined in a Markdown file under .claude/agents/. When invoked, it runs a comprehensive review of the site: takes screenshots at desktop, tablet, and mobile viewports, checks accessibility, reads console logs, and produces a structured report with a letter grade, strengths, high-priority issues, and actionable recommendations.
This is the kind of thing that either gets done inconsistently or not at all during a one-person blog operation. Automated design review isn’t going to replace a skilled designer’s eye, but it catches the obvious things — broken responsive layouts, contrast issues, console errors, missing alt text — without me having to remember to check.
Setting It Up on This Project
For anyone curious about the specific implementation, here’s what I did. First, I created a standalone reference repository with all the configuration files: the CLAUDE.md visual development section, design principles, style guide, the design reviewer subagent, and a slash command to invoke it. That repository serves as a template I can copy from when adding Playwright MCP to any project. Then I ported the relevant pieces to this blog’s project.
The key files:
| File | Purpose |
|---|---|
CLAUDE.md | Visual development instructions for Claude Code |
context/design-principles.md | Broadsheet aesthetic guidelines |
context/style-guide.md | Design tokens: colors, typography, spacing |
.claude/agents/design-reviewer.md | Comprehensive design review subagent |
.claude/commands/design-review.md | Slash command for quick reviews |
The design principles and style guide already existed for this project. The new additions were the CLAUDE.md visual development section and the subagent configuration.
A Note on Longevity
There’s an interesting caveat. The Playwright MCP repository itself now includes a note suggesting that the MCP approach may not be the long-term path for coding agents:
CLI: Modern coding agents increasingly favor CLI-based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands. This makes CLI + SKILLs better suited for high-throughput coding agents that must balance browser automation with large codebases, tests, and reasoning within limited context windows.
In other words, the MCP approach loads a lot of tool definitions and page structure into the model’s context window, consuming tokens that could otherwise go toward reasoning about your code. A CLI-based approach would let the model issue concise commands instead of navigating verbose tool schemas.
This tracks with what I’ve observed. When Playwright MCP is active, Claude Code has access to roughly 30 additional tools, each with its own schema. That’s context window space that isn’t free. For a blog where I’m asking Claude to reason about a Hugo template, some CSS, and a Markdown file, it’s manageable. For a large application with thousands of files, test suites, and complex build processes, the overhead might matter more.
For now, MCP is the way to do this in Claude Code. The SKILLS-based approach is newer and still maturing. But it’s worth knowing that the tooling is moving fast, and today’s workflow may simplify tomorrow.
Was It Worth It?
The setup took about 15 minutes. I pointed Claude Code at Ellis’s video transcript and told it to build out the configuration files. It did the work — the CLAUDE.md section, the design principles, the subagent, all of it. The Playwright MCP installation itself was one command. And the first time I watched Claude Code open a browser, navigate to my local Hugo site, take a screenshot, identify a spacing issue I hadn’t noticed, fix it, and verify the fix — all without me doing anything — the value was obvious.
If you’re using Claude Code for any frontend work, this is worth your time.