Playwright MCP vs Stagehand: two shapes of agentic browser control.

What each project actually is

Playwright MCP is an open-source MCP server published by Microsoft (github.com/microsoft/playwright-mcp) that exposes Playwright's browser automation primitives as MCP tools. A model with MCP support (Claude Code, Cursor, Zed, and a growing number of clients) discovers the available tools at runtime and calls them to navigate, click, type, take screenshots, and inspect the DOM. The semantics are Playwright's semantics: the model has access to the same primitives a human Playwright author would use, expressed as discoverable tool calls.

Stagehand is an open-source framework from Browserbase (github.com/browserbase/stagehand) that wraps Playwright with three primary verbs: act (perform a natural-language action), extract (return structured data), and observe (return candidate actions on a page). The model interprets these high-level verbs and Stagehand resolves them into Playwright actions. The runtime can target a local browser or, more commonly, the managed Browserbase cloud.

The architectural difference: MCP is a protocol that hands a model the tools it needs to control a browser; Stagehand is a framework that hides the browser control behind a smaller verb set the model interacts with directly. The first is closer to a low-level tool surface; the second is closer to a domain-specific language for browser agents.

When you would reach for MCP

MCP is the right surface when the consumer is an LLM-driven IDE or coding agent that already speaks MCP. A developer using Claude Code who wants to spin up a test scenario, or an agent that needs to validate a UI as part of a broader code-change workflow, gets the full Playwright surface area through a protocol the agent already understands. No bespoke wrapper required.

MCP is also the right surface when the consumer wants Playwright's exact semantics. A test author who knows that page.getByRole('button', { name: 'Submit' }) is the locator they want has direct access to that locator. There is no abstraction layer to fight when the abstraction would not help.

When you would reach for Stagehand

Stagehand is the right surface when the agent is more autonomous and operates at a higher level of intent. An agent that needs to "log in, navigate to billing, extract the invoice total, then archive the invoice" benefits from a verb set that handles ambiguity (the model decides what "log in" means on this page) without needing to enumerate Playwright primitives.

Stagehand is also the right surface when the team wants the managed-browser runtime that Browserbase offers. Local Playwright runtimes require browser binaries, headful or headless containers, and resource budgeting. Browserbase managed runtimes hide that; the per-session pricing makes the tradeoff explicit.

Language and ecosystem

Playwright MCP is implemented in TypeScript and exposes the standard Playwright API surface. Stagehand is also TypeScript-native and reuses Playwright. Both projects are open source under permissive licences and are receiving active contributions in 2026.

For Python users, neither project is a first-class fit. Browser Use is the more common Python-ecosystem choice for agentic browser control. The three projects (MCP, Stagehand, Browser Use) occupy adjacent niches with different language home turfs.

Cost model

Playwright MCP itself is free open source. The dominant runtime cost is LLM tokens (the model must read the tool descriptions and propose calls) plus the browser runner cost (a Playwright session running somewhere). For an organisation that already runs its own Playwright infrastructure, MCP layers cleanly without new infrastructure costs.

Stagehand is also free open source. Browserbase, the managed runtime, is paid per browser session. For high-volume agentic workloads, the managed runtime is operationally simpler at a real per-session cost. For low-volume workloads or proof-of-concept work, a local Stagehand runtime is free. Buyers should price the per-session economics against expected volume before committing.

Reliability and determinism

Both projects are tools for agentic browser use, not regression-test runners. Determinism is best-effort and depends on the underlying model, the prompt, and the page state. Neither should be used for a CI regression suite where the same input must produce the same outcome every time; that is the job of hand-authored Playwright code or a platform like QA Wolf or testRigor that handles maintenance for you.

Both projects are appropriate for exploratory testing, agent-driven scraping, accessibility audits, screenshot generation, and any task where the value is the action being performed once or in low volume rather than the action being asserted thousands of times. The category page on LLM and agentic E2E test automation goes into the boundary in more detail.

How to choose

Choose MCP if your consumer is already MCP-aware (Claude Code, Cursor, internal coding agents you have built around MCP) and you want Playwright's exact API surface available to the model. Choose Stagehand if you are building a higher-level agent that needs natural-language verbs and you want the option of a managed browser runtime to reduce operational overhead.

Many teams will end up using both for different parts of the same system: MCP for IDE-side agentic work where the developer is in the loop, Stagehand for autonomous agents in production. The two are not mutually exclusive and the ecosystems are converging on shared infrastructure (Playwright itself, Chromium, the major LLM APIs).

Frequently asked questions

What is MCP and why does Playwright have one?

MCP is the Model Context Protocol, an Anthropic-originated open standard for exposing tools to large language models. Microsoft's Playwright MCP server exposes Playwright's browser-automation primitives as MCP tools, so a model with MCP support (Claude Code, Cursor, and others) can drive a browser without bespoke glue code.

Is Stagehand a Playwright wrapper?

Stagehand is built on top of Playwright and reuses Playwright's browser-driver infrastructure. The additions are an LLM-driven action layer (steps expressed as natural-language intent that the framework resolves to browser actions) and managed browser infrastructure through Browserbase when used in the cloud.

Can either one replace a traditional Playwright suite?

Neither is positioned as a wholesale replacement for hand-authored Playwright tests in CI. Both are tools for agentic browser use: research, scraping, exploratory testing, agent-driven workflows. A regression suite still benefits from explicit, repeatable, version-controlled Playwright tests; an agent loop benefits from the looser action model these two offer.

Which one is cheaper to run at scale?

Playwright MCP itself is open source; cost is in the LLM tokens and the browser-runner infrastructure you provision. Stagehand is also open source but the managed Browserbase runtime is paid. For an organisation that already runs its own browser farm, MCP plus self-hosted Playwright runners can be cheaper. For an organisation that wants the runtime managed, the Browserbase model removes operational overhead at a per-session cost.

Where does Browser Use fit in?

Browser Use is another open-source agentic browser controller in the same broad category. The distinction is that Browser Use sits at the Python ecosystem layer with a strong focus on autonomous agent loops, while Stagehand is TypeScript/JavaScript native and Playwright-aligned. All three (MCP, Stagehand, Browser Use) overlap on the use cases but have different host ecosystems.