Playwright MCP Server: Browser Automation for AI Agents — Official + Cloud Options
Browser automation is one of the most powerful capabilities you can give an AI agent. Navigate to any page, read its content, fill forms, click buttons, take screenshots, inspect network traffic, run JavaScript — all programmatically through natural language.
Playwright is the industry standard for browser automation: fast, reliable, cross-browser, built for modern web apps. There are two ways to connect it to AI agents via MCP: Microsoft's official Playwright MCP server and MCPBundles' browser bundles with local and cloud deployment options.
Two Ways to Connect
1. Microsoft's Official Playwright MCP Server
Microsoft maintains the official @playwright/mcp server — a local Node.js package that runs a browser on your machine and exposes Playwright actions as MCP tools. It supports snapshot-based interaction (accessibility tree), screenshotting, and JavaScript evaluation. Works with Claude Desktop, VS Code Copilot, and other MCP clients via stdio.
Pros: First-party from Microsoft, actively maintained, lightweight local setup. Cons: Local install required (Node.js + npx), browser runs on your machine, no cloud option, no localhost tunneling for remote access, no network inspection or performance profiling.
2. MCPBundles Browser Bundles — 35 Tools, Local + Cloud
MCPBundles provides Playwright-based browser automation as 35 hosted MCP tools with two deployment modes:
- Local Browser: Chrome on your machine via the MCPBundles desktop proxy — your cookies, your logins, your
localhost:3000. You watch the automation happen in real time. - Remote Browser: Cloud-hosted Chrome via Steel.dev — zero install, fresh session, with secure tunneling to reach your localhost from the cloud.
Pros: Cloud option with no local install, localhost tunnel for remote browsers, network inspection, performance profiling, cookie/storage access, hosted setup. Cons: REST-based (not Microsoft's official MCP transport).
Both approaches use Playwright under the hood. Use Microsoft's server for a lightweight local setup, MCPBundles for cloud deployment and advanced capabilities like network inspection and localhost tunneling, or use both.
Local vs Cloud Deployment
Local Browser — Chrome on Your Machine
The Local Browser runs a real Chrome instance on your machine via the MCPBundles desktop proxy. The AI sees exactly what you'd see — your cookies, your logins, your localhost:3000.
Setup:
pip install mcpbundles
mcpbundles login
mcpbundles proxy start
The proxy opens a Chrome window on your desktop. The AI agent controls it through Playwright's Chrome DevTools Protocol (CDP). You can watch the automation happen in real time.
Best for: Testing local dev servers, automating authenticated workflows (you're already logged in), visual QA on localhost, form filling against internal tools.
Remote Browser — Chrome in the Cloud
The Remote Browser is a cloud-hosted Chrome instance powered by Steel.dev. No local install, no Chrome on your machine, no Playwright setup. The AI gets a fresh browser session in the cloud.
Best for: Scraping public pages, testing production URLs, running automations without tying up your local machine, CI/CD integration.
Localhost access from cloud: If your AI agent needs the cloud browser to reach localhost:3000, run mcpbundles proxy expose 3000 to create a secure tunnel.
What AI Agents Can Do
Navigate and Interact With Pages
The core of browser automation — go to URLs, click elements, type text, fill forms. The AI uses Playwright's accessibility tree (snapshot) to find interactive elements, then acts on them by reference.
Tools: browser_navigate, browser_click, browser_type, browser_fill_form, browser_select_option, browser_hover, browser_drag, browser_press_key, browser_scroll, browser_navigate_back, browser_file_upload
| What you ask the AI | What happens |
|---|---|
| "Go to our staging site and log in" | Navigates to URL, snapshots the page, finds username/password fields, fills and submits |
| "Click the 'Create New Project' button" | Snapshots to get element ref, clicks by accessibility reference |
| "Fill out the contact form with test data" | Identifies all form fields, fills each one, submits |
| "Upload this CSV to the import page" | Navigates to the import page, finds the file input, uploads the file |
| "Select 'Enterprise' from the pricing dropdown" | Finds the select element, chooses the option by value |
How element interaction works:
browser_snapshotreturns the page's accessibility tree — every interactive element with a unique ref- The AI identifies the target element from the tree
browser_click,browser_type, orbrowser_fill_formacts on the element using its ref
This ref-based approach is more reliable than CSS selectors or XPath — it works even when class names are minified or the DOM structure changes.
Capture Visual Evidence
Screenshots and PDFs let the AI see the page visually and produce artifacts for documentation, bug reports, or visual regression testing.
Tools: browser_take_screenshot, browser_save_as_pdf, browser_snapshot
| What you ask the AI | What happens |
|---|---|
| "Take a screenshot of the dashboard" | Captures the current viewport as an image the AI can see and analyze |
| "Screenshot the full page including below the fold" | Full-page screenshot with scrolling |
| "Save this page as a PDF" | Renders the page to PDF with print styles |
| "What does this page look like on mobile?" | Emulates a mobile device, then screenshots |
Why screenshots matter for AI: browser_take_screenshot returns an ImageContent response — the AI model can actually see the screenshot, not just get raw HTML. This enables visual QA: "Does this button look right?", "Is the layout broken on mobile?", "Compare this to the mockup."
Inspect and Debug
Read the page's text content, monitor console messages, inspect network requests, check cookies and storage. Essential for debugging and understanding page behavior.
Tools: browser_get_visible_text, browser_console_messages, browser_network_requests, browser_get_network_request, browser_get_console_message, browser_get_cookies, browser_set_cookies, browser_get_storage
| What you ask the AI | What happens |
|---|---|
| "What text is visible on this page?" | Returns all visible text content, structured by the DOM |
| "Are there any console errors?" | Returns console messages filtered by level (error, warning, log) |
| "What API calls did this page make?" | Lists all network requests with URLs, methods, status codes, timing |
| "Show me the response body from the /api/users call" | Gets the full request and response for a specific network request |
| "What cookies are set?" | Returns all cookies with names, values, domains, expiry |
| "What's in localStorage?" | Returns all localStorage key-value pairs |
Debugging workflow: Navigate to page → Check console for errors → Inspect network requests for failed API calls → Read response bodies → Identify the issue. The AI does this entire flow in one conversation.
Run JavaScript and Custom Code
For anything the built-in tools don't cover, the AI can run arbitrary JavaScript in the page context or execute Playwright scripts directly.
Tools: browser_evaluate, browser_run_code
| What you ask the AI | What happens |
|---|---|
| "Get the value of window.APP_CONFIG" | Evaluates the expression in page context, returns the result |
| "Count how many items are in the product grid" | Runs document.querySelectorAll('.product-card').length |
| "Run a Playwright script to test the checkout flow" | Executes a multi-step Playwright script with full API access |
browser_evaluate runs a single JavaScript expression in the page. browser_run_code runs a full Playwright script with access to the page object — loops, conditionals, multiple actions, assertions.
Performance and Device Emulation
Profile page load performance, emulate different devices and network conditions, and test responsive layouts.
Tools: browser_performance_trace, browser_emulate, browser_resize
| What you ask the AI | What happens |
|---|---|
| "Profile the load performance of our homepage" | Captures a performance trace with timing metrics, resource loading, layout shifts |
| "Emulate an iPhone 14" | Sets viewport, user agent, and device scale factor to match the device |
| "Test this page at 768px width" | Resizes the viewport to a specific width |
| "How fast does this page load on a slow 3G connection?" | Emulates throttled network, navigates, measures timing |
Session Management
Control the browser session — manage tabs, handle dialogs, wait for conditions.
Tools: browser_tabs, browser_close, browser_wait_for, browser_handle_dialog, browser_install, browser_click_and_switch_tab
| What you ask the AI | What happens |
|---|---|
| "Wait for the loading spinner to disappear" | Waits until a specific element or condition is met |
| "Accept the confirmation dialog" | Auto-accepts the next JavaScript dialog (alert, confirm, prompt) |
| "Click the link and switch to the new tab" | Clicks an element that opens a new tab, then switches context to it |
Real-World Workflows
Automated QA Testing
Workflow: Navigate → Interact → Screenshot → Assert
- Navigate to the staging URL
- Fill the login form and submit
- Navigate through key pages (dashboard, settings, profile)
- Take screenshots at each step
- Check for console errors or broken network requests
- Report findings with visual evidence
Web Scraping and Data Collection
Workflow: Navigate → Read → Paginate → Extract
- Navigate to the target page
- Get visible text or evaluate JavaScript to extract structured data
- Click "Next Page" and repeat
- Collect and structure the data
Form Automation
Workflow: Navigate → Fill → Submit → Verify
- Navigate to a multi-step form
- Fill each step with the provided data
- Handle dropdowns, checkboxes, file uploads
- Submit and verify the confirmation page
Visual Regression Testing
Workflow: Screenshot → Compare → Report
- Navigate to each critical page
- Emulate multiple device sizes
- Take screenshots at each breakpoint
- Compare against baseline images
- Flag visual differences
Localhost Development Testing
Workflow: Navigate localhost → Test → Debug
browser_navigatetohttp://localhost:3000- Test the feature under development
- Check console for errors
- Inspect network requests to the local API
- Screenshot the result for review
Connecting
Local Browser
pip install mcpbundles
mcpbundles login
mcpbundles proxy start
Enable the Local Browser bundle on MCPBundles. The proxy opens Chrome on your machine — the AI controls it directly.
Remote Browser
No setup required. Enable the Remote Browser bundle on MCPBundles — you get a cloud Chrome session immediately.
For localhost access from the cloud browser:
mcpbundles proxy expose 3000
Frequently Asked Questions
Q: How does this compare to Microsoft's official Playwright MCP server?
Microsoft's @playwright/mcp is a local Node.js server that runs a browser on your machine. MCPBundles' browser bundles offer the same snapshot and screenshot capabilities, plus cloud deployment (no local browser needed), localhost tunneling for remote browsers, network traffic inspection, performance profiling, and cookie/storage access. Both use Playwright — you can use either or both depending on whether you need local-only or cloud+local flexibility.
Q: Can I use this with any AI agent?
Yes. Any MCP-compatible client works — Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf, Cline, or custom agents using the MCP SDK.
Q: Local or Remote — which should I use?
Local if you need localhost access, authenticated sessions (existing cookies), or want to watch the automation live. Remote if you want zero setup, cloud scalability, or don't need localhost.
Q: Can I run headless?
The Local Browser runs a visible Chrome window so you can see what the AI is doing. The Remote Browser runs in the cloud — effectively headless from your perspective, but the AI can still take screenshots.
Q: How does the AI find elements to click?
The AI uses browser_snapshot to get the page's accessibility tree — every interactive element gets a unique ref. The AI then passes that ref to browser_click or browser_type. This is more reliable than CSS selectors because it's based on the element's role and accessible name, not its implementation details.
Q: What about authentication on remote sites?
For the Local Browser, you can log in manually first — the AI inherits your cookies. For the Remote Browser, the AI can automate the login flow (navigate to login page, fill credentials, submit). Cookies persist within a session.
Q: What's the session timeout?
Local Browser sessions last as long as the proxy is running. Remote Browser sessions expire after 2 hours — if the session expires mid-workflow, the AI re-navigates.
Ready to automate your browser with AI? Enable the Local Browser or Remote Browser bundle and start navigating, clicking, and screenshotting — all through natural language.