Playwright MCP

What it is

Playwright is Microsoft's popular tool for automating web browsers, mostly used to test websites. Playwright MCP gives your coding agent that same ability. MCP (Model Context Protocol) is the standard way to plug extra tools into agents like Claude Code, Cursor and Codex.

Once it's installed, your agent can open a browser, go to a page, click, type, fill forms, upload files, switch tabs and take screenshots. Instead of looking at pictures of the page, it mostly reads the page's accessibility tree: a structured text list of buttons, links and fields, the same thing screen readers use. That makes clicks more precise than guessing from a screenshot.

It's free, Apache-licensed and maintained by the Playwright team. It's still on version 0.0.83, but it's widely used and updated every few weeks. The repo shows zero open issues because the team closes them quickly, and the core code now lives in the main Playwright repo.

Playwright MCP or Chrome DevTools MCP? Playwright MCP is for driving a browser: walking through flows, filling forms, checking that pages behave, and testing in Firefox or WebKit (the engine behind Safari) as well as Chrome. Chrome DevTools MCP is for debugging one: slow pages, memory leaks, network errors and console messages, in Chrome only. That's the split Steve Kinney draws too. If you only install one and your problem is "it doesn't work when I click it", either will do. If it's "it's slow" or "why does this request fail", pick Chrome DevTools MCP.

What actually happens when you use it

1. You ask for something that needs a browser. For example, "sign up with a test account and check the welcome email link works". The first time, you may need to say "use the Playwright MCP", or Claude might write its own Playwright script instead.
2. A browser window opens. By default it's a visible Chrome window you can watch, with its own profile. Logins in that profile are saved between sessions.
3. The agent reads and acts. It loads the page, reads the structured snapshot, clicks and types, and gets a fresh snapshot after each step.
4. It reports what happened. Each action also comes with the Playwright code that did it, so you can ask the agent to save the steps as a real test file.
5. It fixes and checks again. The agent edits your code, reloads, and repeats the flow.

You can switch on extra tool groups with --caps, such as network mocking, cookies and storage, PDF export, some DevTools features, or clicking by screen position for pages the text snapshot can't describe.

What people like

• It lets the agent check its own work. An early user puts an instruction in CLAUDE.md to validate changes with Playwright and reported great success with Claude Code.
• You can sign in for it. Because the browser is visible, Simon Willison signs in by hand, then tells Claude what to do next.
• More than just Chrome. It can run Firefox, WebKit and Edge, which Steve Kinney calls one of the few official ways to test Safari's engine from an agent.
• Good for longer, complex sessions. One Reddit user finds the CLI simpler for everyday checks, but says the MCP gives better debugging and log visibility on complex workflows.
• It sees the console in older projects. One Hacker News user asked how else Claude would see console output from the browser, and felt the MCP was worth the extra context there.

What people run into

• It eats tokens. The most common complaint. One user said it fills the context window on almost every call. It sends a page snapshot after every action and old ones pile up. Stagehand, a competing tool, measured it using about three times more tokens than its own product, on a small test it ran itself.
• Microsoft itself steers coding agents elsewhere. The README says coding agents may do better with the Playwright CLI and skills, because it skips the big tool list and page dumps. A user asking for a slim mode like Chrome DevTools MCP's was told there's no such preset yet.
• Plain scripts sometimes work better. One user couldn't get a full-page screenshot through the MCP, but Claude wrote a Playwright script that worked first try.
• It can get stuck. Another user gets death spirals where the agent can't find the browser window or the right element. Others find browser tools slow and clunky, partly because the agent thinks between every step.
• "Browser is already in use." If two agents or windows share the same project, they fight over one browser profile. This long thread is full of people stuck on it. The fix is the --isolated flag.

Before you install

• Watch for files in your project. It can save console logs and page snapshots in a .playwright-mcp folder inside your project. These can hold private URLs and page content. A maintainer said to treat that folder like a .env file, so add it to your .gitignore.
• Logins stick around. The default profile keeps cookies and logins on disk. Use --isolated for a fresh browser each time, and don't sign it in to accounts you care about.
• It's not a security wall. The README says plainly that it isn't a security boundary. A web page could contain hidden instructions aimed at your agent, so keep it to your own app and sites you trust.
• Save tokens. Turn the server off when you aren't doing browser work, try --snapshot-mode none to stop the automatic page dumps, or try the Playwright CLI instead.
• No usage statistics mentioned. Unlike Chrome DevTools MCP, the README doesn't mention collecting any.

The short version

Playwright MCP is the most established way to give your agent hands in a browser, and it's backed by the team that makes Playwright. Use it when you want the agent to walk through your app like a user, across browsers, and maybe turn that into tests. It costs a lot of context, and Microsoft now nudges coding agents toward its lighter CLI, so compare the two on your own project. For performance and network debugging, Chrome DevTools MCP is the better pick.