In my previous post, I shared my experience using Vibe coding and highlighted one of the biggest challenges in that workflow: AI coding tools often lack awareness of what’s happening in the browser when you run your app.
This leads to a frustrating dev loop: you’re forced to constantly copy-paste screenshots, console errors, and network logs into your code editor just to help the AI debug your application.
Luckily, there’s a new wave of tools built on the Model Context Protocol (MCP) that bridge this gap. These browser assist tools let your AI-enhanced code editor (like Cursor) directly observe, interact with, and sometimes even control your browser — just like a real user.
Some of these tools go beyond debugging — they can actually drive the browser, making them incredibly useful for UI testing and automation as well.
🧪 Tools I Evaluated
Each of these plugs into Cursor via MCP and serves a slightly different purpose.
🧠 Architecture Overview
Cursor → MCP → Browser Assist Tool → Browser → Observed by LLM → Cursor responds- Cursor uses Model Context Protocol (MCP) to communicate with these tools.
- The tools interact with the browser — either controlling it or reading logs/events.
- The data is passed to the LLM, which interprets it and responds inside Cursor.
🧩 Tool Breakdown
1. Playwright + MCP
Developed by Microsoft, Playwright is a full-featured browser automation framework that supports Chromium, Firefox, and WebKit. It works across OS platforms and supports headless execution — making it perfect for automation and CI testing.
When integrated with Cursor via MCP, it becomes a powerful browser control agent.
✅ Installation
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}🔧 Supported Functions
These functions are exposed by playwright using MCP. playwright has more functionalities than the ones that it exposes to MCP.
browser_click,browser_type,browser_navigatebrowser_take_screenshot,browser_snapshot,browser_pdf_savebrowser_tab_list,browser_tab_select,browser_tab_close- …and many more
💡 Real Use Cases
- Asked Cursor to debug console errors in my e-commerce app
- Asked Cursor to test flows like “Add to Cart”, “View Product Details”
- Used it for:
- Clicking through workflows
- Filling out forms
- Scraping content
- Capturing screenshots for visual debugging
⚠️ Limitations
- Doesn’t read network logs or API errors
- Click interactions does not work reliably with iframes
2. Browser MCP
This is a lightweight adaptation of Playwright, still MCP-compatible, but simpler.
✅ Installation
- Install Chrome extension (manual or via GitHub release)
- Cursor config:
"browsermcp": {
"command": "npx",
"args": ["@browsermcp/mcp@latest"]
}💡 Why It’s Useful
Unlike Playwright, Browser MCP can control your already open browser tab, without launching a new browser instance. This is helpful for debugging apps you’re already running in Chrome.
🔻 Downsides
- Fewer features than Playwright
- Better suited for lightweight debugging, not complex automation
3. Browser Tools MCP
This tool focuses entirely on browser introspection and debugging, rather than control.
Think of it as DevTools for your AI.
✅ Installation
- Install Chrome Extension
- Start middleware:
npx @agentdeskai/browser-tools-server@latest- Cursor config:
"browser-tools": {
"command": "npx",
"args": ["@agentdeskai/browser-tools-mcp@1.2.0"]
}🛠️ Supported Functions
These are exposed by browsertools using MCP.
getConsoleLogs,getConsoleErrors,getNetworkLogs,takeScreenshotrunAccessibilityAudit,runPerformanceAudit,runSEOAudit,runNextJSAuditwipeLogs,runDebuggerMode,runBestPracticesAudit
💡 What I Could Do
- Refresh app and automatically check network + console errors
- Ask Cursor to analyze latency issues or API failures
- Run full Lighthouse-style audits on performance and SEO
📊 Comparison: Which One to Use?
| Use Case | Best Tool |
|---|---|
| Browser automation + basic debugging | 🟢 Playwright |
| Full DevTools-style debugging | 🟢 Browser Tools MCP |
| Debugging current browser tab with minimal setup | 🟡 Browser MCP |
🧠 Final Thoughts
Playwright is phenomenal — not just for browser debugging, but for automation and testing at scale. If it added rich debugging support (like network logs and audits), it could become the one tool to rule them all.
Meanwhile, Browser Tools MCP fills that debugging gap beautifully today, while Browser MCP hits a sweet spot between the two.
🔮 Looking Ahead
I believe browser assist tools will eventually be natively integrated into code assist platforms like Cursor, eliminating the need for users to manually install and configure MCP plugins. In the future, these platforms will likely support a range of built-in agents that work seamlessly across different environments — web, mobile, desktop — and integrate with tools like databases, APIs, and SaaS platforms out of the box.
There’s also a new class of tools like Anthropic’s Computer Use and OpenAI’s Operator, which aim to control not just browsers but the entire computer environment. It feels inevitable that these worlds — browser automation, LLM-powered agents, and full computer control — will start to converge.
Exciting times ahead. ⚡
Sreenivas Makam's Blog 