peek vs Browser MCP tools
Both give an AI agent access to a browser. The fundamental difference: a fresh browser the agent drives vs your real authenticated session the agent reads to debug what already happened — then exports as a repro.
The category “browser MCP tools” covers browsermcp/mcp, Microsoft's playwright-mcp, browser-use, Browserbase, and similar. All give an AI agent control of a browser over MCP. This page is the honest account of when each shape of tool fits — they are more complementary than competing.
At a glance
| peek | Browser MCP tools (browsermcp, playwright-mcp, browser-use…) | |
|---|---|---|
| The browser the agent works with | Your real, already-authenticated browser session. The agent reads context from what you were doing: the page you had open, with your login, your cookies, your state. | A fresh browser instance (local or cloud) the agent navigates from scratch. No pre-existing session or authentication. |
| Primary job | Give the agent retrospective context: “what broke when I was using the app just now?” Turns a manual session into evidence and repros the agent can reason about. | Give the agent forward control: “go to this URL, fill this form, click this button.” The agent acts on the web autonomously. |
| Generates a Playwright repro | Yes. generate_playwright_repro converts your real session (actual user actions + console + network) into a runnable Playwright test. The agent re-runs it to verify a fix. | Playwright-mcp can run Playwright scripts; it does not generate a test from a recorded session. |
| Handles authentication | Yes — you're already logged in. peek records your real session as you use your app; SSO, MFA, and session cookies are already in place before recording starts. | The agent must automate login from scratch (or you must supply credentials / cookie files). Complex SSO, MFA, and CAPTCHA flows are hard or impossible to automate. |
| Captures what actually happened | Yes. peek records rrweb DOM mutations, console events, and network as you browse naturally — including the moments of failure before you even knew to capture them. | The agent only sees what it navigates to. It cannot retrospectively access a session that already happened before the agent started. |
| Redaction / privacy | Auth and cookie headers deny-listed; form values and PII masked in-page before anything leaves the tab. Per-origin opt-in. Bodies off by default. | The agent has real-time read/write access to the browser it controls. The agent sees exactly what the browser sees — no automatic redaction layer. |
| Where data lives | Local only. Sessions in ~/.peek/sessions.db on your machine. No cloud, no telemetry. | Varies. Local tools (browsermcp, playwright-mcp) run on your machine. Cloud tools (Browserbase) run in their infrastructure. |
| Works on your live production app | Yes — peek records whatever origin you enable. Useful for capturing production bugs in your own app while logged in as yourself. | Depends on the tool. Agents can navigate to any URL, but they authenticate as a fresh user unless you configure session files. |
| Passive vs active | Passive: records as you browse naturally. The agent queries the recording after the fact. | Active: the agent controls the browser in real time. You initiate a task and the agent drives. |
| Write-back (agent acts on browser) | Yes, via execute_action — click, type, navigate, scroll, screenshot — gated by explicit per-action user authorization and an audit log. Acts on your real browser tab. | Yes — this is the primary use case. The agent navigates and acts freely within the browser it controls. |
| Cost | Free. Apache 2.0. | Local tools are generally free and open-source. Hosted tools (Browserbase) charge per usage / browser-minute. |
When peek is the right choice
- You want to debug something that already broke — console errors, a network failure, a layout issue you saw. peek gives the agent your real session context so it doesn't have to reconstruct what happened.
- The app requires authentication that's hard to automate: enterprise SSO, MFA, session-based login. You're already logged in; the agent reads your session.
- You want the agent to turn the bug into a runnable Playwright repro it can replay to verify the fix actually worked.
- Privacy matters: you want explicit per-origin consent and a redaction layer between raw browser data and the AI agent.
- You work locally and want sessions to stay on your machine (no cloud, no telemetry).
- You want the agent to understand the full DOM and network context of a bug, not just what it can reconstruct by navigating to a URL itself.
When browser MCP tools are the right choice
- You want the agent to do things autonomously: fill a form, run a workflow end-to-end, scrape a site, test a flow from scratch. These tools are built for agent-driven automation.
- The task is on a public site or a site where a fresh session is fine. No pre-existing auth state needed.
- You want real-time agent control of a browser — navigating, clicking, and reading the live page state as the agent works.
- You need cloud-hosted isolated browsers (Browserbase) for parallel automation or running browsers in a controlled environment without touching your local machine.
Can you use both?
Yes, and this is a natural pairing. Use peek to record and understand what broke in your real session, then use a tool like playwright-mcp or browsermcp to let the agent act on the fix in a controlled browser. The workflows are complementary: peek gives retrospective context; browser MCP tools give forward action.
A concrete example: you hit a bug on your app while logged in, peek
records the session. You ask the agent to explain what went wrong — it
queries get_session_console_errors and
get_session_network_errors, finds the cause, writes a fix, then
uses generate_playwright_repro to create a test. Later, playwright-mcp
or a Playwright runner verifies the test passes.
What about Sentry Session Replay or LogRocket?
Different category again. Sentry Session Replay and LogRocket record production traffic from your end-users — they are observability tools that instrument your app and capture what users in production actually do. peek records your own developer session during development or debugging. These tools do not compete: one is production monitoring, the other is developer-side context for an AI agent.
Why this page exists
The browser-MCP category is growing fast and the tools look similar from a feature-list distance. The key distinction — your real authenticated session vs a fresh browser the agent controls — determines which tool fits a given task. This page is the honest version of that comparison for someone evaluating the space.
Found something inaccurate above? Open a PR on this page — the goal is accuracy, not advocacy.