Skip to content

Blog

Technical Deep Dive: Why Cook With Gasoline MCP?

Most LLM browser tools fail because they feed the model one of two things:

Raw HTML: This is token-expensive and full of noise (<div class="wrapper-v2-flex...">). The LLM gets lost in the “soup” of utility classes and nesting.

document.body.innerText: This flattens the page, losing all structure. A “Submit” button becomes just the word “Submit” floating in void—the LLM has no idea it’s clickable or which form it belongs to.


CWG is an MCP server that acts as a “Vision Processing Unit” for the LLM.

Instead of scraping HTML, CWG serializes the Accessibility Object Model (AOM). This is the same API screen readers use to navigate the web.

  • Signal, Not Noise: We strip away thousands of <div> and <span> wrappers, exposing only semantic elements: buttons, inputs, headings, and landmarks.
  • The Result: A 50,000-token HTML page becomes a clean, 2,000-token JSON structure that preserves hierarchy and interactivity.

Modern enterprise apps (Salesforce, Adobe, Google Cloud) use Web Components and Shadow DOM to encapsulate styles.

  • The Problem: Standard scrapers (and innerText) hit a “shadow root” and stop. They literally cannot see inside your complex UI components.
  • The CWG Fix: Our serializer recursively pierces open Shadow Roots, flattening the component tree into a single, logical view for the AI.

When Claude or ChatGPT wants to click a button, it usually guesses a CSS selector (e.g., button[class*="blue"]). This is brittle; if you change a class name, the agent breaks.

  • Our Approach: CWG injects ephemeral, stable IDs (e.g., [cwg-id="12"]) into the DOM map it sends to the LLM.
  • The Loop:
    • LLM reads: Button “Save” [id=“12”]
    • LLM commands: click("12")
    • CWG executes the click exactly on that element, regardless of CSS changes.

Frontend errors are often invisible to the UI. If a button click fails silently, the LLM hallucinates that it worked.

  • CWG hooks into the browser’s Console and Network streams.
  • If a 500 API Error occurs after a click, CWG feeds that error log back into the LLM’s context window immediately.
  • Result: The LLM sees “Click failed: 500 Internal Server Error” and self-corrects (e.g., “I will try reloading the page”).
FeatureRaw HTML ScrapingVision (Screenshots)Gasoline MCP
Token Cost🔴 Very High🟡 High🟢 Low (Optimized JSON)
Speed🟢 Fast🔴 Slow (Image Processing)🟢 Instant (Text)
Shadow DOM🔴 Invisible🟢 Visible🟢 Visible & Interactive
Dynamic Content🔴 Misses updates🟡 Can see updates🟢 Live MutationObserver
Click Reliability🟡 CSS Selectors (Brittle)🟡 Coordinate Guessing🟢 Stable ID System

How to Monitor WebSocket Connections with AI Coding Assistants

Gasoline MCP is a browser extension and local server that captures real-time browser telemetry and exposes it to AI coding assistants via the Model Context Protocol. It is the only MCP browser tool that monitors WebSocket connections — capturing opens, closes, and individual messages so your AI assistant can reason about real-time traffic.

WebSocket debugging is painful. Messages fly by in DevTools at a rate that makes manual inspection impractical. There is no search. There is no way to correlate a dropped connection with the UI bug it caused. And critically, your AI assistant cannot see any of it.

If you are building a chat application, trading platform, or collaborative editor, WebSocket issues are some of the hardest to debug. A missing message, a silent reconnection, a stale price feed — these problems live in the stream of events flowing over the wire. You cannot just copy-paste a WebSocket stream into your AI assistant. The data is ephemeral, and by the time you notice the bug, the evidence is gone.

Gasoline intercepts WebSocket activity at the browser level and buffers it for retrieval via MCP tool calls. Here is what your AI assistant gets access to:

  • Connection lifecycle events — open and close, including close codes and reasons
  • Sent and received messages — with precise timestamps for ordering analysis
  • Connection metadata — URLs, protocols, and connection state
  • Message payloads — full text content and binary frame sizes

All of this data is buffered locally on your machine and made available through a single MCP tool call. Your AI assistant can query the full WebSocket history for any tab at any time.

WebSocket monitoring becomes valuable anywhere real-time data flows through your application:

  • Chat applications — Diagnose message ordering bugs, detect dropped connections, and verify reconnection logic
  • Trading platforms — Identify price feed gaps, detect stale data, and audit message delivery timing
  • Collaborative editors — Debug OT/CRDT sync issues by inspecting the exact operation sequence exchanged between clients
  • Real-time dashboards — Detect data staleness and verify that subscriptions remain active after network interruptions
  • Multiplayer games — Analyze state synchronization problems by reviewing the full message exchange between client and server

The major MCP browser tools — Chrome DevTools MCP, BrowserTools MCP, and Cursor MCP Extension — do not capture WebSocket events. They focus on console logs, network requests, and in some cases screenshots or browser automation. None of them intercept WebSocket frames.

If your application uses WebSockets, Gasoline is the only MCP tool that gives your AI assistant visibility into that traffic.

You are debugging a chat application. Users report that messages stop appearing after a few minutes. The UI shows no errors. The console is clean.

You ask your AI assistant: “What’s happening with the WebSocket connection?”

The assistant calls Gasoline’s MCP tool and retrieves the WebSocket event log. It sees that the connection closed 30 seconds ago with code 1006 (abnormal closure) — no close frame was sent, which typically indicates a network interruption or server-side timeout. The assistant identifies that your server’s idle timeout is set to 60 seconds and your client has no heartbeat mechanism, then suggests adding a ping/pong keepalive interval.

Without Gasoline, this diagnosis would require manually watching the DevTools Network tab, catching the close event in real time, and interpreting the close code yourself.

Install Gasoline and connect it to your AI coding assistant (Claude Code, Cursor, or Windsurf). Open your application in Chrome and reproduce the issue. Then ask your assistant about the WebSocket connection. Gasoline makes the full connection history available through MCP, so your assistant can inspect opens, closes, message sequences, and timing without any manual data gathering on your part.

Which MCP tools support WebSocket monitoring?

Section titled “Which MCP tools support WebSocket monitoring?”

As of early 2025, Gasoline is the only MCP browser tool that captures WebSocket events. Chrome DevTools MCP, BrowserTools MCP, and Cursor MCP Extension provide console and network request capture but do not intercept WebSocket frames or connection lifecycle events.

Terminal window
npx gasoline-mcp@latest

One command. No accounts. No configuration. WebSocket monitoring is enabled by default.

Learn more about WebSocket monitoring →

Gasoline MCP vs Cursor MCP Extension: Which Should Cursor Users Choose?

If you use Cursor, you now have two MCP options for browser debugging: Cursor MCP Extension and Gasoline MCP. Both capture browser telemetry and surface it to your AI assistant through the Model Context Protocol. But they differ in scope, features, and portability.

Cursor MCP Extension is built exclusively for Cursor. Gasoline MCP works with Cursor and every other MCP-compatible tool — Claude Code, Windsurf, Claude Desktop, Zed, and whatever ships next.

Here’s a practical comparison to help you decide.

FeatureGasoline MCPCursor MCP Extension
Console log captureYesYes
Network error captureYesYes
Network body captureYesNo
WebSocket monitoringYesNo
DOM queries (CSS selectors)YesNo
Accessibility auditingYesNo
Test generation (Playwright)YesNo
Multi-editor supportYesNo (Cursor only)

Gasoline MCP covers every capability Cursor MCP Extension offers, then adds network body capture, WebSocket monitoring, DOM queries, accessibility auditing, and Playwright test generation on top.

Both tools use a Chrome extension paired with a local server. The difference is in the runtime:

  • Gasoline MCP: Chrome extension + single Go binary. Zero dependencies. No Node.js required. The binary you download is the binary you run — no node_modules/, no lock files, no supply chain surface area.
  • Cursor MCP Extension: Chrome extension + Node.js MCP server. Requires a Node.js runtime and npm packages.

If dependency footprint matters to your team — for security audits, enterprise policy, or simply reducing moving parts — Gasoline MCP’s zero-dependency design is a meaningful advantage.

The AI editor landscape is evolving fast. A year ago, most developers hadn’t heard of MCP. Today, it’s supported by Claude Code, Cursor, Windsurf, Claude Desktop, Zed, and more.

Cursor MCP Extension locks your browser debugging setup to a single editor. If you switch to another tool — or even want to try one — you need a different solution.

Gasoline MCP is editor-agnostic. It works with any tool that speaks MCP. Your browser debugging configuration moves with you, regardless of which assistant you’re using today or which one you try tomorrow.

The feature gap is significant if you’re debugging anything beyond basic console errors:

WebSocket monitoring. If your app uses WebSockets — chat, real-time dashboards, collaborative editing, live data feeds — Cursor MCP Extension can’t see that traffic. Gasoline MCP captures WebSocket frames with adaptive sampling to keep overhead negligible.

Network body capture. Cursor MCP Extension reports network errors, but not response bodies. When your AI assistant is debugging a failed API call, it needs to see what the server actually returned. Gasoline MCP captures request and response bodies with configurable filtering.

DOM queries. Gasoline MCP lets your AI assistant query the live DOM using CSS selectors. This is essential for verifying that UI changes rendered correctly or diagnosing layout issues.

Test generation. Gasoline MCP can generate Playwright tests from captured browser sessions. You browse your app, and your AI assistant turns that session into reproducible test code. Cursor MCP Extension has no equivalent.

Cursor MCP Extension is a reasonable choice if all of the following are true:

  • You only use Cursor and have no plans to try other editors
  • You only need basic console log and network error capture
  • You don’t work with WebSocket-based applications
  • You don’t need to inspect network response bodies
  • You want the absolute simplest setup with minimal configuration

For straightforward console-error debugging in a Cursor-only workflow, it gets the job done.

Gasoline MCP is the stronger choice if any of the following apply:

  • You want full-spectrum browser debugging (console, network, WebSocket, DOM)
  • You use multiple AI editors or plan to try new ones
  • You need network body capture for API debugging
  • You work with real-time applications that use WebSockets
  • You want to generate Playwright tests from real browser sessions
  • You prefer zero dependencies and a minimal supply chain footprint

Should Cursor users use Gasoline MCP or Cursor MCP Extension?

Section titled “Should Cursor users use Gasoline MCP or Cursor MCP Extension?”

If you’re a Cursor user deciding between the two, the question is whether you need more than basic console and network error capture. If you do — and most non-trivial debugging sessions do — Gasoline MCP gives you substantially more to work with. It also means your setup won’t break if you try a different editor next month.

Yes. Gasoline MCP works with Cursor through standard MCP configuration. Setup takes a few minutes and requires no special integration. See the Cursor setup guide for step-by-step instructions.

Terminal window
npx gasoline-mcp

One command. No runtime dependencies. Works with Cursor and every other MCP client.

Cursor setup guide | Full getting started guide

Gasoline MCP vs BrowserTools MCP: A Practical Comparison

Gasoline MCP and BrowserTools MCP take the same basic approach: a Chrome extension passively captures browser telemetry and serves it to AI coding assistants via MCP. You browse normally, and your AI sees what happens — console logs, network errors, exceptions.

But the two tools differ significantly in architecture, features, and dependencies. Here’s a practical breakdown.

Gasoline MCP has two components: a Chrome extension and a single Go binary. The extension captures events and sends them to the Go server over a local WebSocket connection. The Go binary handles both the HTTP/WebSocket server and the MCP stdio interface.

BrowserTools MCP has three components: a Chrome extension, a Node.js intermediary server, and a separate MCP server. The extension sends data to the intermediary server, which then relays it to the MCP server. Two server processes instead of one.

Fewer moving parts means fewer things to configure, fewer things to break, and a simpler mental model when debugging your debugging tool.

FeatureGasoline MCPBrowserTools MCP
Console logsYesYes
Network errorsYesYes
Network bodiesYesNo
WebSocket monitoringYesNo
DOM queriesYesNo
Accessibility auditYesYes (Lighthouse)
Test generationYes (Playwright)No
ScreenshotsNoYes
Lighthouse auditsNoYes

Gasoline MCP covers more capture categories — network bodies, WebSocket messages, DOM queries, and test generation. BrowserTools MCP offers Lighthouse performance audits and screenshots, which Gasoline MCP does not.

Gasoline MCP ships as a single Go binary with zero runtime dependencies. The binary is roughly 10MB. No Node.js, no node_modules/, no lock files, no supply chain surface area.

Terminal window
npx gasoline-mcp

The npx command downloads the prebuilt binary for your platform. No compilation, no runtime required.

BrowserTools MCP requires Node.js and installs multiple npm packages. The full dependency tree is 150MB or more. Each dependency is a potential point of failure during installation and a potential supply chain risk.

For enterprise environments with strict security policies, the dependency footprint is often the deciding factor.

Both tools operate over localhost only — your browser data never leaves your machine.

The difference is in credential handling. Gasoline MCP automatically strips authorization headers, cookies, and other sensitive values from captured network data before exposing it through MCP. This prevents credentials from leaking into AI context windows where they might be echoed back, logged, or included in generated code.

BrowserTools MCP does not strip credentials from captured data. Network headers are passed through as-is, which means auth tokens and session cookies can end up in your AI assistant’s context.

Gasoline MCP also sends zero telemetry and binds exclusively to 127.0.0.1, rejecting non-localhost connections at the TCP level.

Gasoline MCP captures WebSocket connections, frames, and message payloads in both directions. BrowserTools MCP does not support WebSocket monitoring.

If you’re building real-time applications — chat systems, trading platforms, collaborative editors, live dashboards — WebSocket traffic is often where the bugs live. Being able to ask your AI assistant “what WebSocket messages were exchanged in the last 30 seconds?” changes how you debug these systems.

Gasoline MCP records browser sessions and generates Playwright test code from them. You interact with your application normally, and Gasoline MCP produces a test that replays those interactions with proper assertions.

BrowserTools MCP does not offer test generation.

Which is better: Gasoline MCP or BrowserTools MCP?

Section titled “Which is better: Gasoline MCP or BrowserTools MCP?”

It depends on what you need.

Choose Gasoline MCP if you need:

  • WebSocket monitoring for real-time applications
  • Network request and response body capture
  • DOM querying from your AI assistant
  • Playwright test generation from browser sessions
  • Zero runtime dependencies and minimal supply chain risk
  • Automatic credential stripping for privacy

Choose BrowserTools MCP if you need:

  • Lighthouse performance audits
  • Screenshots served through MCP

For most browser debugging workflows with AI assistants, Gasoline MCP covers more ground with less overhead.

Does BrowserTools MCP support WebSocket monitoring?

Section titled “Does BrowserTools MCP support WebSocket monitoring?”

No. BrowserTools MCP captures console logs, network requests, and can run Lighthouse audits, but it does not monitor WebSocket connections or messages. If your application uses WebSockets, Gasoline MCP is the only passive-capture MCP tool that supports this.


For a broader comparison including Chrome DevTools MCP and other tools, see the full alternatives guide. Ready to try Gasoline MCP? Get started in under a minute.

Gasoline MCP vs Chrome DevTools MCP: Which Browser MCP Tool Should You Use?

Gasoline MCP and Chrome DevTools MCP both give AI coding assistants access to browser data, but they take fundamentally different approaches. One watches your real browsing session passively. The other takes active control of a separate browser instance. The right choice depends on what you’re building.

Architecture: Passive Capture vs Active Control

Section titled “Architecture: Passive Capture vs Active Control”

Gasoline MCP uses a Chrome extension to observe your normal browsing. Console logs, network requests, WebSocket frames, and DOM state are captured silently and served to your AI assistant through a local Go binary via MCP. You browse normally; Gasoline MCP watches and records.

Chrome DevTools MCP uses Puppeteer to drive a dedicated Chrome instance through the Chrome DevTools Protocol. Your AI assistant can navigate pages, click elements, take screenshots, and read page state — but in a separate browser window, not your real session.

This is the core tradeoff. Gasoline MCP captures what actually happens during development. Chrome DevTools MCP controls a browser programmatically.

FeatureGasoline MCPChrome DevTools MCP
Console logsYesYes
Network errorsYesYes
Network bodiesYesPartial
WebSocket monitoringYesNo
DOM queriesYesYes (full control)
Accessibility auditYes (axe-core)No
Test generationYes (Playwright)No
ScreenshotsNoYes
Browser controlNoYes
Cross-browserChrome, Edge, BraveChrome only

Gasoline MCP covers more observability surface — WebSocket monitoring, full network body capture, accessibility auditing, and Playwright test generation are capabilities Chrome DevTools MCP does not offer. Chrome DevTools MCP wins on active capabilities: screenshots and programmatic browser control.

Security posture is where the two tools diverge most sharply.

Gasoline MCPChrome DevTools MCP
Data localitylocalhost only (127.0.0.1)Depends on configuration
Auth handlingHeaders stripped automaticallyNot stripped
DependenciesZero (single Go binary)Puppeteer + npm dependency tree
TelemetryNoneUnknown
Debug portNot requiredRequired (Chrome debug port)

Gasoline MCP rejects non-localhost connections at the TCP level and never makes outbound network calls. Authorization headers are stripped before data reaches the MCP layer. The single binary has zero third-party dependencies, which means no supply chain risk and no node_modules/ folder to audit.

Chrome DevTools MCP requires opening a Chrome debug port, which is a known security surface. It also depends on Puppeteer and its transitive npm dependencies — a significantly larger attack surface for enterprise environments.

Gasoline MCP enforces strict performance SLOs to ensure the extension never degrades browsing. Every WebSocket interception completes in under 0.1ms. Fetch interceptions stay under 0.5ms. Memory is capped at 20MB soft / 50MB hard, with adaptive sampling for high-frequency events.

Chrome DevTools MCP runs a separate Chrome instance entirely, so it does not affect your browsing performance — but it does consume additional system resources for that second browser process.

Should I use Gasoline MCP or Chrome DevTools MCP?

Section titled “Should I use Gasoline MCP or Chrome DevTools MCP?”

Use Gasoline MCP if you want to observe your real browsing session. During normal development, you interact with your app, trigger bugs, and test features in your browser. Gasoline MCP captures all of that context — console errors, failed network requests, WebSocket traffic — and makes it available to your AI assistant without changing how you work. If you need zero dependencies, enterprise-grade security, or Playwright test generation, Gasoline MCP is the clear choice.

Use Chrome DevTools MCP if you need browser automation. If your workflow requires programmatic navigation, taking screenshots, or scripting browser interactions, Chrome DevTools MCP gives your AI assistant direct control. This is valuable for scraping, visual regression testing, or workflows where the AI needs to drive the browser itself.

Yes. The two tools serve different purposes and can run side by side. Use Gasoline MCP as your default for development — it passively captures everything as you work. Reach for Chrome DevTools MCP when you specifically need automation or screenshots. Since they operate independently (Gasoline MCP watches your real browser, Chrome DevTools MCP controls a separate instance), there is no conflict.

Gasoline MCP installs with a single command, no runtime required:

Terminal window
npx gasoline-mcp

See how Gasoline MCP compares to other browser MCP tools in our full alternatives breakdown, or jump straight to the getting started guide.