Browser Use vs Playwright MCP: Two Ways to Let an LLM Drive a Browser (2026)

Introduction

Browser automation used to mean a test suite: selectors, waits, and assertions written by a person who had looked at the page. LLM-driven browsing flips that. You describe a goal such as "find the cheapest refundable fare and put it in the cart," and a model decides which element to click next from whatever the page looks like right now. That removes the selector maintenance and adds a new class of problems: nondeterministic runs, token bills that scale with page size, prompt injection from page content, and agents that confidently report success after clicking the wrong button.

Two open-source approaches dominate developer discussion. Browser Use is a Python library that runs an agent loop: it reads page state, asks a model for the next action, executes it through Playwright, and repeats until a task is done. Microsoft's Playwright MCP is a Model Context Protocol server that exposes browser actions as tools, so an MCP client such as Cursor or Claude Code owns the agent loop and the server only provides hands and eyes. They solve overlapping problems with different control surfaces, and picking the wrong one produces either a rigid script wrapped in an agent or an agent with no guardrails.

This article compares how each reads a page, who controls the loop, what they cost to run, and where they fail. It includes a working MCP configuration, a Browser Use script, and a hardening checklist. We have not benchmarked either tool here, so no success rates or token counts appear. Test on your own target sites, because anti-bot systems, login flows, and page weight dominate results far more than the choice of library.

Architectural Breakdown & Core Mechanics

Playwright MCP: tools over the accessibility tree

Playwright MCP starts a Playwright-controlled browser and registers tools with an MCP client. The central tool is a snapshot: instead of sending a screenshot to a vision model, the server returns a structured text representation of the page derived from the accessibility tree, in which interactive elements carry short reference IDs. The model then calls tools such as browser_click or browser_type with those references. Other tools cover navigation, tab management, file upload, screenshots, and JavaScript evaluation, with optional capability groups enabled by flags.

Two consequences follow. First, the snapshot is text, so a standard language model can drive it without vision support, and the token cost scales with the number of accessible elements on the page. Second, the loop belongs to the client. The MCP server has no notion of a goal, a step limit, or a success check. Those come from your editor, agent framework, or prompt. For the protocol background our separate Playwright MCP server guide on this site covers it from an end-to-end testing angle.

Browser Use: an agent loop with a pluggable model

Browser Use bundles the loop. An Agent object takes a task string and an LLM client, launches a browser session, and iterates: extract a simplified DOM with indexed interactive elements (and optionally a screenshot for vision models), prompt the model for structured actions such as click, input text, scroll, open tab, or extract content, run them, and feed the outcome back. It keeps a message history, can retry on action errors, supports custom actions you register as Python functions, and returns a history object containing visited URLs, actions, and a final result.

The loop being inside the library gives you step limits, custom tools, and Python-native control flow, at the price of a library whose API moves quickly. Treat the version you test as a pin.

Who owns what

Comparative Benchmarks & Evaluation Matrix

The table contrasts design properties. It deliberately has no success-rate column: published agent-browsing benchmarks use task suites and models that may not resemble your sites, so run a small evaluation of your own (the recipe below suggests how).

Who should not use either: if the flow is the same every day (download a report, submit a form), write a normal Playwright script and call an LLM only for the parts that actually vary. LLM browsing is for exploration, long-tail sites, and flows that change. For tasks that need a general autonomous coding agent rather than just a browser, OpenHands is a different tool category worth comparing.

Step-by-Step Implementation Recipe

Part 1: Playwright MCP in Cursor or Claude Code

Add the server to your MCP configuration. In Cursor this is .cursor/mcp.json in the project or the global file; Claude Code and other clients take the same command and args shape. Verify flag names with npx @playwright/mcp@latest --help, since options change between releases.

{

"mcpServers": {

"playwright": {

"command": "npx",

"args": [

"@playwright/mcp@latest",

"--isolated",

"--headless"

]

}

}

}

--isolated keeps browser state in memory instead of reusing a persistent profile, which prevents an agent from touching your logged-in sessions. Drop --headless while developing so you can watch it work. Then give the agent a bounded instruction, for example: "Open https://example.com/pricing, take a snapshot, and list plan names with prices. Do not click anything that submits a form."

Part 2: A Browser Use task with a step limit

The script below runs one bounded task and prints the result and visited URLs. Browser Use has changed its LLM client imports across releases (older versions used LangChain chat models, newer ones ship their own client classes), so pin a version and check its README if an import fails. Set the API key for your provider in the environment.

# pip install browser-use   (pin the version you test)

# playwright install chromium

# export OPENAI_API_KEY=...   (or the key for the provider you choose)

import asyncio

import sys

from browser_use import Agent

from browser_use import ChatOpenAI  # older releases: from langchain_openai import ChatOpenAI

TASK = (

"Open https://example.com/pricing. List every plan name and its monthly price. "

"Do not log in, do not fill forms, and stop after reading the pricing table."

)

async def main() -> int:

llm = ChatOpenAI(model="gpt-4o-mini")  # choose any model your pinned version supports

agent = Agent(task=TASK, llm=llm)

history = await agent.run(max_steps=12)  # hard ceiling on loop iterations

print("FINAL RESULT:")

print(history.final_result())

print("\nURLS VISITED:")

for url in history.urls():

print(" -", url)

if not history.is_done():

print("Agent stopped without finishing the task", file=sys.stderr)

return 1

return 0

if __name__ == "__main__":

raise SystemExit(asyncio.run(main()))

Part 3: A small evaluation harness

Write 15 to 30 tasks with known correct answers on the sites you care about. Run each tool three times and record: finished or not, correct or not, steps used, and total model tokens from your provider's usage dashboard. Repeating runs matters because the same task can pass and fail on consecutive attempts. Report the pass rate across repeats, and review every failure by replaying its history instead of guessing.

Hardening checklist

Treat every page as untrusted input, because page text can contain instructions aimed at your agent. Use an isolated profile with no saved logins. Restrict navigation to the domains the task needs. Give the agent read-only goals when possible, and require a human confirmation step before any purchase, send, or delete action. Store credentials in the environment, never in the task text, since task text is sent to the model provider. The AI agent security evaluation checklist covers prompt injection and tool-permission review in more detail.

Strategic Catalog Integrations

• A browser agent is only as reliable as its system prompt. The resilient tool-use agent prompt defines retry and fallback behavior you can adapt for failed clicks and timeouts.
• For a lighter prompt-only approach to web research, the web browser prompt shows a minimal pattern for simulating browsing instructions.
• When you convert exploratory runs into real tests, the software quality assurance tester prompt helps turn observed steps into test cases with expected results.
• The Browser Use agent project listing in the catalog is a related entry to compare against the main Browser Use project.
• If your MCP client is Cursor, the Mastering Cursor AI course covers configuring tools and project context, and the Cursor tool page lists current pricing and alternatives.
• Agent code that drives browsers should be strictly typed. The TypeScript strict zero-any rules keep tool-call payloads from drifting into untyped objects, and the Claude Code senior staff engineer rules provide a review-oriented system prompt for agent-written changes.
• To see how tool use fits into larger agent systems, Building Systems with ChatGPT walks through chaining prompts and checking outputs.

Frequently Asked Questions (FAQ)

Is Playwright MCP better than Browser Use?

Neither is better in general. Playwright MCP is stronger when a person is steering inside an editor and wants the browser as one tool among many. Browser Use is stronger when you want an autonomous Python task with a step limit and custom actions. If you need a fixed, repeatable flow, a plain Playwright script beats both.

Does Playwright MCP need a vision model?

No. Its default snapshot is text derived from the accessibility tree, so a text-only model can operate it. Vision mode exists for pages where the accessibility tree misses what matters, such as canvas-heavy interfaces, and it increases cost.

How do I stop an AI browser agent from doing something destructive?

Combine several controls: an isolated profile with no saved sessions, a domain allow-list, a hard step limit, read-only task wording, and a human approval step before irreversible actions. Do not rely on the model's own caution, and keep secrets out of task text.

Why does my browser agent pass one run and fail the next?

Model sampling, dynamic page content, cookie banners, and anti-bot checks all change between runs. Lower temperature where your client allows it, make the task wording specific, and measure over repeated runs rather than a single success.