Learn Claude Code: Tool Integrations Playwright: Giving Claude a Browser

Playwright: Giving Claude a Browser

Intermediate 🕐 12 min Lesson 10 of 11
What you'll learn
  • Add the Playwright MCP server as a local stdio process and verify Claude can open a browser and navigate pages
  • Use Playwright to give Claude visibility into your running application for QA, bug reproduction, and visual verification
  • Understand the boundaries of what Playwright MCP can and cannot do so you can scope tasks appropriately

Testing a page change by manually reloading a browser tab

After making a frontend change, the verification step is almost always the same: open a browser, navigate to the affected page, and look at it. If something is wrong, you inspect the element, note the problem, switch back to your editor, describe what you saw to Claude, and iterate. The browser and Claude never see the same thing at the same time.

The Playwright MCP server gives Claude a browser it can operate directly. Claude can navigate to a page, read its content, interact with elements, and take screenshots — all as part of the same session where it is making code changes. The verification loop collapses from several manual steps to a single tool call.

Adding the Playwright server

Playwright MCP is maintained by Microsoft and runs as a local stdio server via npx. It requires Node.js 18 or later. It uses the Chrome browser already installed on your machine by default.

Add the server:

claude mcp add playwright -- npx -y @playwright/mcp@latest

The -- separator is required — it tells Claude Code that everything after it is the command to run, not additional Claude Code flags. Without it, Claude Code tries to parse npx as a server name and -y as a transport flag.

Check the connection:

claude mcp list

The first check may show ✗ Failed to connect while npx downloads the package. Wait a moment and run claude mcp list again. Once the download completes, the server shows as ✓ Connected.

To use Firefox or WebKit instead of Chrome, append --browser firefox or --browser webkit after @playwright/mcp@latest.

Basic verification: does the page work?

The most common use is verifying that a page renders correctly after a code change:

Use Playwright to open http://localhost:3000 and tell me what the page title is and whether any console errors appear.

A browser window opens (you can watch it work), and Claude reports what it finds. For a more specific check:

Open http://localhost:3000/dashboard and verify that the user list renders with at least one row. Take a screenshot if it does not look right.

Claude navigates to the page, reads the DOM content, checks for the expected element, and screenshots the page if the condition fails — giving you visual evidence of the problem.

Walking through a bug report

Bug reports often describe a sequence of steps. Playwright can follow them exactly:

The user reported that clicking "Save" on the settings page shows a success message but the changes are not saved when you refresh. Use Playwright to reproduce: go to /settings, change the display name, click Save, refresh the page, and check if the name persisted.

Claude executes each step, observes the result, and confirms whether it can reproduce the bug. If it can, it reports exactly what it observed at each step. If it cannot reproduce it, it describes what happened instead — both outcomes are useful.

Pointing at your local development server

Playwright is particularly useful for verifying changes to your local development server before committing. Because the server runs on your machine, Claude can reach http://localhost:PORT directly without any network configuration.

A practical workflow: make a code change, ask Claude to open the relevant page on your dev server, verify it visually, and confirm the behavior. If something is wrong, Claude is already in the same session where the code lives and can fix it immediately.

For staging environments, replace the localhost URL with the staging URL. Playwright can reach any URL your machine can access.

What Playwright MCP can and cannot do

Knowing the boundaries helps you scope tasks appropriately:

  • Can do: Navigate URLs, click elements, fill text inputs, select dropdowns, read page content, take screenshots, wait for elements to appear
  • Cannot do: Download files to disk (the download dialog is outside the browser's page), interact with browser extensions, handle system dialogs (OS-level file pickers), log in through SSO that opens a new OAuth window in a separate browser profile

For pages that require authentication, the most reliable approach is to have Claude navigate to the login page and fill in credentials as part of the task, rather than trying to pass cookies or session tokens separately.

Playwright opens a visible browser window by default, so you can watch Claude's actions in real time. This is helpful for debugging when a task is not working as expected.

Key takeaways
  • The Playwright MCP server gives Claude a browser it can navigate, click, and read — collapsing the manual verify-switch-describe loop into a tool call within the same session.
  • The <code>--</code> separator between <code>claude mcp add</code> and the server command is required for stdio servers — without it, Claude Code misparses the server arguments.
  • Playwright is most powerful for verifying local development server changes: Claude makes a code edit and then navigates to <code>http://localhost:PORT</code> to confirm the result in the same session.
  • Walking through bug report reproduction steps is a reliable Playwright use case — Claude follows the exact steps and reports what it observed at each one.
  • Playwright cannot download files, interact with browser extensions, or handle OS-level dialogs — scope tasks to what happens inside the browser page itself.