Playwright MCP Server
Microsoft’s official MCP server for structured control of real browsers through Playwright. It gives AI agents deterministic element targeting through accessibility snapshots, plus navigation, forms, console/network inspection, file uploads, screenshots and persistent browser state.
Should you use Playwright MCP?
Exploratory browser automation, web-app debugging, authenticated UI testing, self-healing test workflows, and agents that need persistent browser state.
You only need simple browser checks, have a context-constrained coding session, or would expose sensitive authenticated sessions without strong isolation.
Mature Playwright browser automation exposed through structured, model-friendly tools with persistent browser state and rich inspection.
Webpage content enters the model context while the same agent can perform powerful browser actions, creating security and context-cost trade-offs.
Playwright MCP is strongest when persistent browser state, repeated page inspection, debugging, testing, or long-running browser interaction materially improve the workflow. It is a weaker fit when a few discrete browser checks are enough.
What is Playwright MCP?
Playwright MCP is an MCP server maintained by Microsoft that exposes Playwright browser automation to AI agents.
Instead of requiring an AI model to understand a webpage mainly from screenshots and pixel coordinates, Playwright MCP can represent much of the page through structured accessibility snapshots. The agent can then identify page elements and perform deterministic browser actions against them.
The server acts as a bridge between an MCP client and Playwright:
AI agent → MCP client → Playwright MCP → Playwright → browser
The browser result is then returned to the agent so it can decide its next action.
This makes Playwright MCP useful for workflows where an agent needs to inspect and interact with a real website repeatedly rather than perform a single browser command.
How Playwright MCP works in a real browser session
The important mechanism is the accessibility snapshot. Instead of forcing the model to guess screen coordinates, the server can return named interface elements with roles and reference IDs. The model acts on those refs, then reads the next browser state.
What one login loop actually looks like
browser_navigate → https://app.example.com/login browser_snapshot → textbox "Email" [ref=e12] · textbox "Password" [ref=e13] · button "Sign in" [ref=e14] browser_type → ref e12, "you@example.com" browser_type → ref e13, "********" browser_click → ref e14 browser_snapshot → heading "Dashboard" [ref=e3]
This is why Playwright MCP is different from a screenshot-only browser agent: the model can target a named element, take an action and verify the result from structured browser state. Screenshots remain useful for human verification and visual cases, but they are not the only interaction mechanism.
What does Playwright MCP actually expose?
The official server exposes more than 20 browser operations across navigation, interaction, observation and debugging, with additional capabilities for uploads, dialogs, JavaScript evaluation, drag/hover interactions and tab control.
| Tool family | Representative tools | What the agent can do |
|---|---|---|
| Navigation | browser_navigate, browser_tabs | Open URLs, move through history and switch tabs. |
| Interaction | browser_click, browser_type, browser_fill_form | Click, type, select and submit against element references. |
| Observation | browser_snapshot, browser_take_screenshot | Read structured page state and capture pixels when needed. |
| Debugging | browser_console_messages, browser_network_requests | Inspect client-side errors, requests and browser behavior. |
What this produces in practice
Agentic test generation. An agent can explore a checkout or signup flow, then turn that exploration into a runnable Playwright test.
Verify-after-edit loops. A coding agent can change a component, open the local app, interact with it and verify that the change works.
JavaScript-heavy extraction. Because a real browser executes the application, the agent can inspect data that does not exist in raw HTML.
Exploratory debugging. A prompt such as “open the dashboard and tell me why this chart is empty” can combine navigation with console and network inspection instead of guessing from source code alone.
The value is not merely “browser access.” The stronger use case is a repeated loop of inspect → act → verify while browser state persists across steps.
Who should use Playwright MCP?
Playwright MCP is most useful when persistent browser interaction provides meaningful value.
Playwright MCP is a strong fit for
Web-app debugging. An agent can modify an application, open it in a browser, inspect the resulting interface, check console or network problems, and continue debugging.
UI testing. Structured element targeting makes Playwright MCP useful for generating, running, and repairing interactive browser flows.
Exploratory browser automation. Agents can move through an application while retaining browser state and deciding their next action from the current page.
Authenticated workflows. Playwright MCP can work with browser state that contains authenticated sessions, making it useful for testing dashboards and applications that require login.
Long-running browser agents. Persistent state and repeated introspection can be valuable when an agent must perform many browser actions during one workflow.
Playwright MCP is a weaker fit for
Simple coding-agent browser checks. Opening a page, checking one result, and closing it may not justify the MCP tool and context overhead.
Context-constrained workflows. Tool definitions and accessibility snapshots can consume meaningful model context.
Unsupervised interaction with untrusted websites. Webpage content itself can influence the model while the model controls powerful browser actions.
Sensitive authenticated sessions without isolation. Connecting an agent to a browser containing valuable accounts greatly increases the consequences of an incorrect or manipulated action.
Which Playwright MCP session mode should you use?
The session mode changes both convenience and risk because it decides where cookies, local storage and authenticated state live.
| Mode | Flag | State behavior | Best fit | Guidance |
|---|---|---|---|---|
| Persistent | Default | Cookies, logins and local storage survive in a project-specific profile. | Repeated development work against apps you control. | Useful default for trusted workflows; remember that retained sessions increase authority. |
| Isolated | --isolated | Starts clean and removes the session on close; storage state can seed initial cookies. | Testing, parallel runs and untrusted/sensitive browsing. | Prefer this when you do not need durable login state. |
| Browser extension | --extension | Connects to tabs in an existing logged-in browser. | Flows that intentionally require an already authenticated tab. | Highest-consequence mode. Use only when handing that existing session to the agent is deliberate. |
Persistent profiles are separated by workspace
The default profile pattern is ms-playwright/mcp-{channel}-{workspace-hash}. The workspace hash helps keep project browser state separate. --user-data-dir can override the profile location.
The extension mode changes the blast radius
Extension mode is convenient because it can use a browser tab that is already logged in. That same convenience is the risk: the model can act with the cookies and permissions already present in that tab. Do not treat it as equivalent to an isolated test profile.
Is Playwright MCP safe?
Playwright MCP can be used safely in controlled workflows, but the server itself is not a security boundary.
The core risk is structural: webpage content enters the model’s context while the same model may have authority to click, submit, upload, navigate, execute browser code and interact with authenticated applications.
Prompt injection matters more when the browser is privileged
A hostile page can place instructions in content that the model reads through the accessibility snapshot. The approximate path is:
webpage → accessibility snapshot → model → browser action
The consequence depends on browser authority. An isolated disposable session is very different from an extension-controlled tab that is already authenticated to a valuable account.
Three controls materially reduce exposure
- Match session mode to trust. Prefer
--isolatedfor untrusted browsing and test workflows. - Fence navigation. Use
--allowed-originsand--blocked-originsto constrain where the browser may go. - Keep approval and OS/network isolation proportional to the task. MCP configuration reduces exposure but does not replace container, account, filesystem or network boundaries for high-risk automation.
Untrusted webpages + a persistent or extension-controlled authenticated session + broad filesystem/network access is the configuration that deserves the most scrutiny.
How much context does Playwright MCP use?
Playwright MCP has three different context costs, and mixing them together produces misleading token claims.
| Context layer | Reference | What it represents |
|---|---|---|
| Tool/schema load | ~14.4K–15.2K historical reference | Older measurements of Playwright MCP tool definitions in a Claude Code configuration. Useful as a reference, not a universal current count. |
| Dense page snapshot | ~15K–30K live-page reference | A dense-page reference estimate for one full accessibility snapshot. Actual size varies substantially with page complexity. |
| Repeated browser session | Variable; potentially much larger | Tool schemas + snapshots + console/network output + conversation history + source code + model output across many steps. |
The same schema can tokenize differently across model families, and browser-result payloads vary by page. The honest number is model-specific schema measurement plus task-specific browser output.
What the schema and snapshot references mean on 15 current models
The table uses documented context-window sizes and asks a narrower question: if the payload were 14.4K, 15.2K or 30K tokens on that model, how much of its context window would that occupy? It does not claim those models tokenize the current Playwright schema identically.
| Current model | Documented context | 14.4K schema ref | 15.2K schema ref | 30K snapshot ref |
|---|---|---|---|---|
| GPT-6 Astra OpenAI | 1,050,000 | 1.37% | 1.45% | 2.86% |
| GPT-6 Sol OpenAI | 1,050,000 | 1.37% | 1.45% | 2.86% |
| GPT-6 Luna OpenAI | 1,050,000 | 1.37% | 1.45% | 2.86% |
| Claude Fable 5.1 Anthropic | 1,000,000 | 1.44% | 1.52% | 3.00% |
| Claude Opus 5.5 Anthropic | 1,000,000 | 1.44% | 1.52% | 3.00% |
| Claude Sonnet 5 Anthropic | 1,000,000 | 1.44% | 1.52% | 3.00% |
| Claude Haiku 4.5 Anthropic | 200,000 | 7.20% | 7.60% | 15.00% |
| Gemini 3.8 Flash | 1,048,576 | 1.37% | 1.45% | 2.86% |
| Grok 4.7 xAI | 500,000 | 2.88% | 3.04% | 6.00% |
| Grok 4.3 xAI | 1,000,000 | 1.44% | 1.52% | 3.00% |
| DeepSeek V4 Pro DeepSeek | 1,000,000 | 1.44% | 1.52% | 3.00% |
| DeepSeek V4.1 Flash DeepSeek | 1,000,000 | 1.44% | 1.52% | 3.00% |
| Mistral Medium 3.5 Mistral | 256,000 | 5.62% | 5.94% | 11.72% |
| Mistral Small 4 Mistral | 256,000 | 5.62% | 5.94% | 11.72% |
| Llama 4 Scout Meta | 10,000,000 | 0.14% | 0.15% | 0.30% |
Model context sources verified Sep 26, 2026: OpenAI model pages; Anthropic model overview; Google Gemini 3.8 Flash documentation; xAI Grok model pages; DeepSeek pricing/model documentation; Mistral model/limitations documentation; Meta Llama documentation. Model availability and limits can change, so this table is date-stamped rather than presented as timeless.
The practical cost is repeated snapshots, not only tool registration
If the model snapshots a dense page after every click, the browser state can dominate context use. Reuse element refs while the page state is unchanged; take another snapshot after navigation or a meaningful state change.
External 2026 benchmarks have reported materially lower token use for CLI-based Playwright workflows than for MCP in some coding-agent tasks. Treat those as reported benchmark evidence, not a universal 4× or 32× guarantee. The architectural point is stronger than the exact multiplier: terse CLI output can be cheaper than persistent tool schemas plus repeated accessibility snapshots.
Is Playwright MCP free?
Yes. Playwright MCP itself is free and open source, and it does not require a paid Playwright API.
The more important cost is often model usage.
| CostPlaywright MCP | |
|---|---|
| MCP software | Free |
| Playwright API | No paid API required |
| Browser binaries | Free, but consume storage |
| Model tokens | Variable |
| Compute | Depends on where the browser runs |
| Security isolation | May add infrastructure/operational cost |
A browser workflow can therefore cost more than expected even though the MCP server itself is free.
The largest variable is typically the amount of model context consumed by tool schemas and browser state.
When should you use Playwright MCP instead of the alternatives?
There are two separate decisions: which browser automation interface to use, and which browser MCP server to use.
Playwright MCP vs Playwright CLI + Skills
| Attribute | Playwright MCP | CLI + Skills |
|---|---|---|
| Interaction model | MCP tools | CLI commands + skill instructions |
| Persistent browser state | Strong | More task-oriented |
| Repeated page introspection | Strong | Leaner |
| Schema/context overhead | Higher | Lower |
| Best fit | Exploratory, stateful browser loops | Discrete coding-agent browser checks |
Decision: choose MCP when the agent benefits from persistent browser state and repeated structured introspection. Compare CLI + Skills when the browser task is a short check inside a coding workflow and context efficiency matters more.
Playwright MCP vs Puppeteer MCP
The current Microsoft Playwright server is the stronger maintained baseline for a new browser-MCP deployment because it is actively maintained and supports multiple browser engines. An older or existing Puppeteer-based workflow can still justify Puppeteer, but the decision should be driven by an actual dependency rather than familiarity with an archived reference server.
This comparison preserves the useful live-page entity relationship while avoiding a blanket claim that one technology is universally better for every existing codebase.
How do you set up Playwright MCP correctly?
The basic server command is:
npx @playwright/mcp@latest
The package and the browser binaries are separate. Missing browser binaries are a common reason navigation fails after the server starts, so install them before debugging the MCP connection:
npx playwright install
Base MCP configuration
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}Flags that change the risk profile
--isolated— start with a clean browser session.--allowed-origins— restrict navigation to trusted origins.--blocked-origins— fence specific origins off.--user-data-dir— choose a persistent profile location.--extension— hand an existing browser tab/session to the server.--port— switch from local stdio to an HTTP-style server deployment.
Browser and deployment reality
The server can control Chromium/Chrome, Firefox, WebKit and Edge-related configurations. Stdio is the common local transport; server/HTTP deployment is available for remote or containerized operation. Microsoft also publishes an official container image for Playwright MCP.
Verify the connection before doing real work
Confirm that the browser tools appear in the MCP client, then run a minimal prompt such as “open example.com and tell me the page title.” This separates connection problems from application-specific failures.
How do major AI clients connect to Playwright MCP?
| Client | Setup pattern | Important detail |
|---|---|---|
| Claude Code | claude mcp add playwright npx @playwright/mcp@latest | Useful when coding changes need repeated browser verification. |
| Cursor | Project MCP config using the same npx command. | Project-scoped configuration pairs naturally with project-specific browser state. |
| VS Code / Copilot | Native MCP server configuration. | VS Code uses its own configuration structure; do not blindly paste every other client’s JSON shape. |
| Claude Desktop | Desktop MCP config + full app restart. | Closing only the window may not reload server configuration. |
| Codex CLI | Register the same npx server command in Codex config. | Good fit when the agent needs browser control from a coding environment. |
| Gemini CLI / Windsurf / OpenCode / Cline | Use each client’s MCP configuration with the same server command. | The server is the same; file location and config syntax vary by host. |
The compatibility question is usually not whether a client supports Playwright MCP, but how that client registers, approves and restarts an MCP server. The underlying Playwright MCP package remains the same while configuration syntax and file locations vary by client.
Why is Playwright MCP not working?
These four failure patterns help distinguish common configuration problems from deeper browser or session issues.
| Symptom | Likely cause | What to check |
|---|---|---|
| Server starts, navigation fails | Browser binaries were never installed. | Run npx playwright install and retry. |
| Browser never opens on a remote/container system | A headed browser has no display or the deployment mode is wrong. | Use an appropriate display/headless/container setup or run the server through its remote/HTTP mode. |
| Tool names do not match the documentation | The config may point to a similarly named Playwright MCP project. | Confirm the package is Microsoft’s @playwright/mcp. |
| One browser call consumes most of the context | A dense full-page accessibility snapshot is large. | Reuse refs while page state is unchanged and snapshot again only when the page meaningfully changes. |
Do not confuse three different Playwright MCP projects
@playwright/mcp is Microsoft’s general browser-control MCP and the subject of this profile. @executeautomation/playwright-mcp-server is a separate community server. Playwright Test MCP is a different Microsoft project focused on test generation/execution rather than general browsing.
Entity confusion matters because old tutorials can show different tool names, flags and installation steps while still using the words “Playwright MCP.”
What are the limitations of Playwright MCP?
Playwright MCP is strongest exactly where its costs are highest: persistent browser state, repeated page introspection and powerful authenticated actions. Evaluate those together rather than scoring capability in isolation.
Playwright MCP's main limitations come from the same capabilities that make it useful.
Context consumption can be high
Browser accessibility trees, tool definitions, and repeated browser states consume substantially more model context than many API-oriented MCP servers.
Webpage prompt injection is difficult to eliminate
The model must process information supplied by the webpage in order to understand it.
That creates an inherent boundary problem when the same model also controls privileged browser actions.
Browser workflows can fail in ways normal APIs do not
Browsers can disconnect, crash, lock profiles, encounter rendering differences, or expose inconsistent page state.
The recent evidence corpus contains reported issues involving browser lifecycle, profile collisions, cross-client page-state exposure, version mismatches, and browser disconnect recovery.
Safe deployment requires more than MCP configuration
Origin restrictions, filesystem limits, and isolated contexts help.
High-risk deployments may additionally require:
- containers;
- network restrictions;
- separate test accounts;
- disposable credentials;
- isolated browser profiles;
- restricted filesystem access.
MCP is not automatically the best Playwright interface
For coding agents that need a few browser checks rather than persistent browser exploration, Playwright CLI + Skills can provide a more context-efficient architecture.
That significantly changes the decision compared with evaluating Playwright MCP in isolation.
MCPVerdict assessment
Playwright MCP is a highly capable browser-automation MCP built on a mature and widely used automation framework.
Its effectiveness is not the main concern.
The more important question is whether the workflow actually benefits from giving an LLM persistent, richly introspectable control over a browser.
Playwright MCP performs particularly well when an agent needs to:
- inspect page state repeatedly;
- retain browser sessions;
- explore an unfamiliar web application;
- debug frontend behavior;
- work through long multi-step UI flows;
- or recover and adapt during browser automation.
Its trade-offs become more significant when those capabilities are unnecessary.
The same browser authority that enables sophisticated automation also increases the consequences of prompt injection, unsafe authenticated sessions, filesystem access, and unintended browser actions.
Its accessibility-based interaction model also creates meaningful context overhead during repeated use.
That combination explains the Conditional verdict.
Why Playwright MCP scores well
- strong browser automation;
- mature Playwright foundation;
- deterministic element interaction;
- broad browser compatibility;
- active Microsoft maintenance;
- low basic setup friction;
- persistent state and rich inspection capabilities.
Why it does not score higher
- webpage content can influence the controlling model;
- browser actions can have real side effects;
- authenticated sessions increase exposure;
- context consumption can be substantial;
- isolation requires deliberate configuration;
- Playwright CLI + Skills provides a leaner alternative for some coding-agent workflows.
The current MCPVerdict evaluation scores effectiveness at 89, maintainability at 95, and setup friction at 87, while context efficiency scores 42 and prompt-injection containment 43.
Bottom line
Use Playwright MCP when persistent browser state, repeated page introspection, and long-running browser interaction materially improve the agent's workflow.
For routine coding-agent browser checks, compare it directly with Playwright CLI + Skills before making MCP part of every session.
Playwright MCP technical details
Show the full technical profile
| AttributeValue | |
|---|---|
| Publisher | Microsoft |
| Repository | microsoft/playwright-mcp |
| Type | MCP server |
| Runtime | Node.js |
| Minimum Node version in evaluated package | Node 18+ |
| License | Apache-2.0 |
| Browser support | Chromium/Chrome, Firefox, WebKit, Edge configurations |
| Default transport | stdio |
| Server deployment | Supported |
| Docker | Supported |
| API key required | No |
| Persistent browser state | Supported |
| Isolated sessions | Supported |
| Existing browser integration | Supported |
| Scan grade | C |
The evaluated release was version 0.0.82, updated September 18, 2026.
Recent Playwright MCP evidence
Recent evidence in the supplied evaluation shows both active development and the complexity of operating an agent-controlled browser safely. These are reported findings, not claims that every historical issue remains exploitable in the evaluated release.
Show the recent evidence findings
Recent evidence shows both active development and the complexity of operating an agent-controlled browser safely.
Notable findings include:
- a reported
browser_run_codeescape path; - unrestricted-navigation/SSRF concerns;
- accessibility snapshots containing misleading off-screen structure;
- requests for stronger destructive-action policies;
- default profile-lock collisions;
- browser lifecycle regressions;
- cross-client browser-state leakage;
- HTTP session-management problems;
- very large accessibility snapshots;
- browser disconnect recovery problems;
- browser-version mismatches;
- and subsequent security hardening including a symlink-escape fix.
These findings should not be interpreted as meaning every historical issue remains exploitable in the current release.
They show why Playwright MCP should be evaluated as a privileged browser automation system, rather than as a harmless read-only MCP.
Frequently asked questions
Can Playwright MCP take screenshots?
Yes. Screenshots are available for visual verification, but structured accessibility snapshots are a central model-facing interaction mechanism.
What is the difference between Playwright and Playwright MCP?
Playwright is the underlying browser-automation library developers call from code. Playwright MCP exposes browser operations as MCP tools so an AI agent can choose and execute those actions through an MCP client.
Is Playwright MCP maintained by Microsoft?
Yes. This profile evaluates Microsoft’s official microsoft/playwright-mcp project, not a similarly named community wrapper.
Does Playwright MCP require an API key?
No. Playwright MCP does not require a dedicated paid Playwright API key.
Does Playwright MCP use screenshots?
It can take screenshots, but its normal model-facing browser understanding relies heavily on structured accessibility snapshots rather than requiring screenshot-only interaction.
Can Playwright MCP use logged-in websites?
Yes. Persistent browser profiles, storage state, and existing-browser configurations can allow agents to interact with authenticated applications.
Use isolated test accounts and profiles when possible.
Does Playwright MCP support Docker?
Yes. Docker-based operation is supported and can also form part of a stronger isolation strategy.
Can Playwright MCP run remotely?
Yes. Playwright MCP is not limited to local stdio operation, although exposing browser-control infrastructure remotely changes the security requirements.
Does Playwright MCP replace Playwright?
No. Playwright MCP is an interface that exposes Playwright browser capabilities to MCP-compatible agents. Playwright itself remains the underlying browser-automation technology.
Is Playwright MCP better than Playwright CLI?
Neither is universally better.
Playwright MCP is better suited to persistent, introspective and exploratory browser-agent workflows. Playwright CLI + Skills can be more efficient for coding agents that mainly need discrete browser operations.
MCPVerdict: Conditional · 71/100 · Confidence: Moderate
Evaluating this for a team?
Check the choice against your workflow, clients, permissions, deployment, and alternatives.