ego (lite) is just a browser, ego is your personal agent across devices.
Join waitlist
Browser UsePlaywright MCPAI agentsMCP serversBrowser automation

Browser Use vs Playwright MCP: Agent Framework vs Protocol Tool

Aug 16, 20268 min read
Browser Use vs Playwright MCP: agent framework versus protocol tool

The fastest way to answer "Browser Use vs Playwright MCP" is to look at what's already installed on your machine, because these two don't compete for the same slot in a stack.

Playwright MCP is a protocol tool: it gives browser hands to an agent you already have. Browser Use is an agent framework: it is the agent, and you build around it in Python.

That framing settles most cases in one pass. The rest of this article is the evidence: integration cost, failure modes, and a decision tree keyed to your existing setup, with the numbers from measured sessions where they exist.

What kind of thing is each one?

Playwright MCP (Microsoft, Apache-2.0) is a server that exposes browser primitives over the Model Context Protocol. It has no intelligence of its own: your MCP client (Claude Code, Cursor, VS Code, Codex) reads each accessibility snapshot and decides every action. No new bill, no new runtime; it rides the agent and model you already pay for.

The microsoft/playwright-mcp GitHub repository, 36.1k stars, Apache-2.0, maintained by the Playwright team
The protocol tool: microsoft/playwright-mcp, 36.1k stars. Note what's absent from the description: no agent, no model, no loop. It waits for a client to think for it.

Browser Use (MIT, ~109K stars) is a complete autonomous system: Agent(task=..., llm=...).run() perceives pages, plans, acts, and retries in its own loop, now over direct CDP rather than Playwright underneath. It ships a CLI and skill for coding agents, hosted models, and a cloud tier, but the center of gravity is Python code you write and operate.

The browser-use GitHub repository, 109k stars, MIT license
The agent framework: browser-use at 109k stars, MIT. The whole loop lives here: perception, planning, action, retries. You bring a task string and an LLM key.

One is a peripheral; the other is a machine. You don't compare them so much as check which one your desk is missing.

Their context footprints tell the same story: Playwright MCP loads two dozen-plus tool schemas (~4,200 tokens) into your agent's window and returns page snapshots per action, while Browser Use keeps its reasoning in its own process and hands your code a finished result object. The MCP spends your agent's context; the framework spends its own API budget.

Here's a finished result object, for real: a live browser-use 0.13.7 agent, run today against a real page with an actual OpenAI model paying for the tokens.

# Browser Use 0.13.7, real Agent run, gpt-4.1-mini via OPENAI_API_KEY
agent = Agent(
    task="Go to https://news.ycombinator.com/ and tell me the exact title text of the #1 story on the front page, plus its points count.",
    llm=ChatOpenAI(model="gpt-4.1-mini"),
)
history = await agent.run(max_steps=8)

# Real output (trimmed to the meaningful lines):
INFO     [Agent] Starting a browser-use agent with version 0.13.7, with provider=openai and model=gpt-4.1-mini
INFO     [Agent]   โ–ถ๏ธ   navigate: url: https://news.ycombinator.com/, new_tab: False
INFO     [tools] ๐Ÿ”— Navigated to https://news.ycombinator.com/
INFO     [Agent]
INFO     [Agent] ๐Ÿ“ Step 1:
INFO     [Agent]   ๐Ÿ‘ Eval: Successfully located the #1 story title and its points count on the Hacker News front page.
INFO     [Agent]   ๐Ÿง  Memory: Located the top story on Hacker News with title 'Qwen 3.8 27B' and points count '415 points'.
INFO     [Agent]   ๐ŸŽฏ Next goal: Report the exact title text and points count of the #1 story to the user.
INFO     [Agent]   โ–ถ๏ธ   done: text: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points., success: True, files_to_display: None
INFO     [Agent]
๐Ÿ“„  Final Result:
The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.

INFO     [Agent] โœ… Task completed successfully
FINAL RESULT: The #1 story on Hacker News front page is titled "Qwen 3.8 27B" with 415 points.

What does zero-to-first-task cost in each?

Count the steps from nothing to a completed first task, assuming a developer laptop with Node and Python available.

StepPlaywright MCPBrowser Use
1claude mcp add playwright npx @playwright/mcp@latestpip install browser-use (Python 3.11+)
2Ask your agent: "use playwright mcp to open the site and read X"Put an LLM API key in .env (or a Browser Use key for hosted models)
3Done; a browser window opens and worksWrite the Agent(task, llm) script, run it, iterate on the prompt

Playwright MCP wins this race by design: for someone with an MCP client installed, integration cost is one command and one sentence. Browser Use's setup isn't heavy either, but it's real development: environment, keys, a script, and prompt iteration before the first reliable run.

The asymmetry flips for someone with no coding agent at all, where MCP has nothing to plug into and Browser Use's script is the shortest path that exists. Integration cost, in other words, is relative to your starting point, which is the whole thesis of this comparison.

How does each one break?

Both break in production; they break in opposite directions, and you should pick the failure you'd rather debug.

Playwright MCP breaks by context explosion. Every action returns a page snapshot into the conversation: measured test runs cost 89K-114K tokens (Microsoft's CLI-launch figures and an independent Medium measurement), single dashboard snapshots hit 12K, and by step 12-15 sessions carry 60-90K tokens of stale state and start referencing elements that no longer exist. The r/ClaudeCode symptom report: one or two browser tests and the chat compacts. The failure is loud and visible in your bill.

We measured a snapshot directly today, not from a benchmark harness: one live MCP session (chrome-devtools-mcp, the same protocol family) against a single ordinary page, one take_snapshot call, real character count.

# Chrome DevTools MCP, chrome-devtools-mcp@latest, real stdio session (mcp Python SDK)
nav = await session.call_tool("navigate_page", {"url": "https://news.ycombinator.com/"})
snap = await session.call_tool("take_snapshot", {})
print("take_snapshot chars:", len(snap_text))

# Real output:
navigate_page chars: 123
take_snapshot chars: 38285
## Latest page snapshot
uid=1_0 RootWebArea "Hacker News" url="https://news.ycombinator.com/"
  uid=1_1 link url="https://news.ycombinator.com/"
  uid=1_2 link "Hacker News" url="https://news.ycombinator.com/news"
    uid=1_3 StaticText "Hacker News"
  uid=1_4 link "new" url="https://news.ycombinator.com/newest"
    uid=1_5 StaticText "new"
  uid=1_6 StaticText " | "
  uid=1_7 link "past" url="https://news.ycombinator.com/front"
    uid=1_8 StaticText "past"
  uid=1_9 StaticText " | "
  uid=1_10 link "comments" url="https://news.ycombinator.com/newcomments"
    uid=1_11 StaticText "comments"
  uid=1_12 StaticText " | "
  uid=1_13 link "ask" url="https://news.ycombinator.com/ask"
...

Browser Use breaks by wandering. The LLM loop can stall (users report agents stuck at Step 1), spiral on tab switches, or worst, fabricate plausible data when it can't find the real thing, with no error raised. Analyses of the framework recommend validating its output like untrusted user input. The failure is quiet and visible only when someone checks the data.

Pick your poison: a bill you can see, or data you must audit.

Two thirty-second war stories to make the shapes memorable. MCP shape: an engineer asks Claude Code to verify a five-page signup flow; by page four, the accumulated snapshots crowd out the conversation, the session compacts, and the agent re-asks a question it answered twenty minutes earlier.

Framework shape: a Browser Use job pulling supplier prices completes cheerfully, and a week later someone notices three of the forty rows contain prices from the wrong product tier, with no error logged anywhere. Neither story is rare; both are documented patterns.

Which should you pick, by what you already have?

Four branches cover nearly everyone. Take the first that matches.

You have a Python stack and no coding agent: Browser Use. It's the complete system, your team already speaks its language, and there's no agent for MCP to serve anyway.

You write test scripts and run CI/CD pipelines: Playwright MCP, next to your existing Playwright suite: same engine, cross-browser coverage, headless CI support, and the agent becomes an interactive layer over infrastructure you trust.

You have a coding agent, want zero added cost, and your tasks touch logins: ego (lite). It's a free browser built for sharing your logged-in browser state with AI agents like Claude Code and Codex: any agent that can run a shell command drives it through the ego-browser skill, whole workflows run outside the model's context, and it works in its own Space without grabbing your window.

It combines the two columns' strengths deliberately: the MCP route's use-your-own-agent model, the framework's keep-work-out-of-your-context execution, and the logins neither has. On complex tasks it finishes up to 3.45x faster than agent-browser, on fewer tokens.

You have all three needs at once: Split by workflow, which is what mature setups do anyway: MCP or direct Playwright for testing, Browser Use where sites are unknown, ego (lite) for the daily logged-in tasks.

See ego (lite) vs Browser Use in full, or download ego (lite) for Mac, free.

FAQ

What's the best Browser Use MCP setup?

Browser Use ships MCP integration, so an MCP client can call it as a tool server. Note what that inverts: run this way, your agent decides and Browser Use executes, which is Playwright MCP's shape with Browser Use's machinery. Most teams wanting that shape run Playwright MCP directly; Browser Use's MCP mode makes sense when you specifically want its extraction and navigation machinery available as tools.

Which costs more to run?

They spend differently: Playwright MCP consumes your existing agent subscription's tokens (heavily, on snapshot-rich sessions), while Browser Use adds its own per-step model calls, with field reports around 50K tokens per step on DOM-heavy pages and a $0.05/step cloud option. For long tasks, both bills climb; out-of-process script execution is the route that keeps page data off the meter entirely.

Can Browser Use work with Claude Code like an MCP does?

Yes, two ways: its CLI-and-skill route (browser-use skill install) for one-off tasks driven by the agent, or its MCP mode. Its own docs draw the line as one-off tasks through an agent via CLI, repeatable automation in code via the Python library.

Which is better for web scraping?

For known sites at volume, neither: script it directly (Playwright the library, not the MCP) and skip per-step model costs entirely. Browser Use earns scraping work when the sites are unknown or constantly redesigned; Playwright MCP suits interactive extraction sessions where you're steering. Logged-in sources on your own accounts point at a shared-state browser instead.

Do either work behind login walls?

Not natively: Playwright MCP starts a fresh profile, and Browser Use's real-Chrome connection has documented reliability problems, with the founder acknowledging instability. Inheriting a real browser's sessions, ego (lite)'s model, is the clean answer for tasks on your own accounts.