mcp | Gasoline MCP

Technical Deep Dive: Why Cook With Gasoline MCP?

Jan 26, 2026

Brenn Hill

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.

How Gasoline MCP (CWG) is Different

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

1. The “Accessibility Tree” Strategy

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.

2. Shadow DOM Piercing

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.

3. “Stable ID” Interaction

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.

4. The “Console Vision” Pipeline

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”).

Comparison Table

Feature	Raw HTML Scraping	Vision (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

Feb 1, 2025

Brenn Hill

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.

The Problem with Debugging WebSockets

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.

What Gasoline Captures

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.

Use Cases

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

No Other MCP Tool Does This

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.

Example Workflow

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.

How do I debug WebSocket issues with AI?

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?

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.

Get Started

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?

Jan 31, 2025

Brenn Hill

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.

Feature Comparison

Feature	Gasoline MCP	Cursor MCP Extension
Console log capture	Yes	Yes
Network error capture	Yes	Yes
Network body capture	Yes	No
WebSocket monitoring	Yes	No
DOM queries (CSS selectors)	Yes	No
Accessibility auditing	Yes	No
Test generation (Playwright)	Yes	No
Multi-editor support	Yes	No (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.

Architecture

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.

Why Portability Matters

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.

Features Cursor MCP Extension Lacks

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.

When Cursor MCP Extension Is Fine

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.

When Gasoline MCP Is Better

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?

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.

Does Gasoline MCP work with Cursor?

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.

Get Started

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

Jan 30, 2025

Brenn Hill

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.

Architecture

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.

Feature Comparison

Feature	Gasoline MCP	BrowserTools MCP
Console logs	Yes	Yes
Network errors	Yes	Yes
Network bodies	Yes	No
WebSocket monitoring	Yes	No
DOM queries	Yes	No
Accessibility audit	Yes	Yes (Lighthouse)
Test generation	Yes (Playwright)	No
Screenshots	No	Yes
Lighthouse audits	No	Yes

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.

Dependencies

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.

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.

Privacy

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.

WebSocket Monitoring

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.

Test Generation

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?

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?

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?

Jan 29, 2025

Brenn Hill

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

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.

Feature Comparison

Feature	Gasoline MCP	Chrome DevTools MCP
Console logs	Yes	Yes
Network errors	Yes	Yes
Network bodies	Yes	Partial
WebSocket monitoring	Yes	No
DOM queries	Yes	Yes (full control)
Accessibility audit	Yes (axe-core)	No
Test generation	Yes (Playwright)	No
Screenshots	No	Yes
Browser control	No	Yes
Cross-browser	Chrome, Edge, Brave	Chrome 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

Security posture is where the two tools diverge most sharply.

	Gasoline MCP	Chrome DevTools MCP
Data locality	localhost only (127.0.0.1)	Depends on configuration
Auth handling	Headers stripped automatically	Not stripped
Dependencies	Zero (single Go binary)	Puppeteer + npm dependency tree
Telemetry	None	Unknown
Debug port	Not required	Required (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.

Performance

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?

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.

Can I use both?

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.

Getting Started

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

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.

Zero-Dependency MCP Setup: Browser Debugging Without Node.js

Jan 28, 2025

Brenn Hill

Gasoline MCP gives AI coding assistants real-time browser observability — console logs, network traffic, WebSocket frames, DOM state — through a single Go binary with zero runtime dependencies. No Node.js. No Python. No Puppeteer. No node_modules/.

The Problem with MCP Browser Tools

Most MCP-based browser debugging tools are built on Node.js. That means installing a JavaScript runtime, pulling hundreds of npm packages, and trusting a dependency tree you’ll never fully audit.

Chrome DevTools MCP requires Puppeteer, which alone downloads a bundled Chromium binary and brings roughly 200MB of dependencies. BrowserTools MCP needs multiple npm packages across two separate Node.js processes. Even simpler tools pull in dozens of transitive dependencies.

Every dependency is a surface. A compromised package in your node_modules/ folder can exfiltrate data, modify behavior, or introduce vulnerabilities that won’t show up until your next audit. Enterprise security teams know this. It’s why they flag tools with large dependency trees, and why supply chain attacks against npm packages have become one of the most common vectors in the JavaScript ecosystem.

One Binary. Zero Dependencies.

Gasoline takes a different approach. The entire server is a single Go binary, roughly 10MB, compiled from a codebase with zero external Go dependencies (stdlib only). There is no runtime to install, no interpreter to maintain, and no package manager to trust.

The binary you download is the binary you run. There’s nothing else.

Dependency Comparison

	Gasoline	Chrome DevTools MCP	BrowserTools MCP	Cursor MCP Extension
Runtime required	None	Node.js 22+	Node.js	Node.js
Install size	~10MB	~200MB+	~150MB+	~100MB+
Transitive deps	0	300+ (Puppeteer tree)	100+	50+
Supply chain surface	Single binary	npm registry	npm registry	npm registry
Reproducible build	Yes (Go binary)	Depends on lock file	Depends on lock file	Depends on lock file

Why Enterprise Teams Care

When your security team evaluates a new tool, they ask: what does it install, what does it connect to, and what can it access?

With Gasoline, the answers are simple:

What does it install? One binary.
What does it connect to? Nothing. The server listens on 127.0.0.1 only and makes zero outbound network calls.
What can it access? Only the browser telemetry your extension sends to localhost.

This makes SOC2 audits straightforward. There’s no dependency manifest to review, no lock file drift to monitor, and no risk of a transitive dependency introducing a vulnerability between audits. The binary is statically compiled — you can checksum it, store it in your artifact registry, and know exactly what’s running in every environment.

What About npx?

You install Gasoline with npx gasoline-mcp@latest. That might look like a Node.js dependency — but it isn’t.

The npm package is a thin wrapper that downloads the correct prebuilt Go binary for your platform. Once installed, there is no Node.js process running. The MCP server is the Go binary, communicating over stdio. npx is just the delivery mechanism, chosen because it’s the convention MCP clients expect. If you prefer, you can download the binary directly from GitHub releases and skip npm entirely.

Does Gasoline MCP require Node.js?

No. Gasoline’s MCP server is a compiled Go binary. It requires no runtime — not Node.js, not Python, not Java. The npx gasoline-mcp command downloads a prebuilt binary; it does not start a Node.js server. You can also install the binary directly without npm.

How many dependencies does Gasoline have?

Zero. The Go server uses only the Go standard library. The Chrome extension is vanilla JavaScript with no frameworks or build tools. There are no transitive dependencies, no node_modules/, and no lock files to maintain.

Get Started

npx gasoline-mcp@latest

One command. One binary. Nothing else to install, configure, or trust.

Learn more about Gasoline’s security architecture

Why document.body.innerHTML Ruins LLM Context Windows

Jan 27, 2025

Brenn Hill

Gasoline MCP gives AI coding assistants real-time browser context via the Model Context Protocol. One of the hardest problems it solves is this: how do you represent a web page to an LLM without blowing up the context window?

The most common answer in the wild is wrong.

The innerHTML Problem

Many MCP tools, browser automation scripts, and AI coding workflows grab DOM content the obvious way:

document.body.innerHTML

This dumps the entire raw HTML of the page into the LLM’s context window. Every ad banner. Every tracking pixel. Every inline style. Every SVG path definition. Every base64-encoded image. Every third-party script tag. Every CSS class name generated by your framework’s hash function.

A typical web page might contain 500KB of raw HTML. The actual meaningful content — the text, the form fields, the error messages your AI assistant needs to see — might be 5KB. That’s 99% waste in a context window with hard token limits.

The Math

Consider a React dashboard page. A SaaS admin panel with a sidebar, a data table, some charts, and a modal.

Approach	Token Count	Meaningful Content
`document.body.innerHTML`	~200,000 tokens	~2,000 tokens
Accessibility tree	~3,000 tokens	~2,000 tokens

With innerHTML, you are burning 99% of your context budget on <div class="css-1a2b3c"> wrappers, Webpack chunk references, SVG coordinate data, and analytics scripts. In a model with a 128K token context window, a single innerHTML dump can consume more than the entire window — leaving zero room for conversation history, system prompts, or the code your assistant is actually working on.

Worse, the signal-to-noise ratio is so low that the LLM struggles to locate the relevant content even when it fits. Buried somewhere in 200K tokens of markup is the error message you need it to read.

How Gasoline Handles DOM Content

Gasoline takes a fundamentally different approach. Instead of raw HTML, it uses the accessibility tree — the structured, semantic representation that browsers build for screen readers.

The accessibility tree contains only meaningful elements:

Headings and document structure
Buttons, links, and interactive controls
Form fields with their labels and current values
Text content that a user would actually read
ARIA labels and roles that describe element purpose
State information — checked, expanded, disabled, selected

It strips out everything else. No CSS. No scripts. No SVG paths. No base64 blobs. No tracking pixels. What remains is a clean, hierarchical representation of what the page actually shows and does.

The query_dom Tool

Beyond the full accessibility tree, Gasoline provides a query_dom MCP tool that lets AI assistants query specific elements using CSS selectors:

query_dom(".error-message")
query_dom("form#login input")
query_dom("[role='alert']")

Instead of dumping the entire page and hoping the LLM finds the relevant piece, the assistant can request exactly what it needs. A targeted query might return 50 tokens instead of 200,000.

This changes the interaction model from “here’s everything, good luck” to “ask for what you need.”

Why is innerHTML Bad for LLMs?

Three reasons:

Token waste. Raw HTML is mostly structural noise — closing tags, class attributes, data attributes, script contents. LLMs pay per token. You are paying to process markup that carries zero information about your bug.
Signal dilution. Even when it fits in context, the LLM must locate a needle in a haystack. Error messages, form validation failures, and visible text get buried under layers of generated markup. Model attention is a finite resource.
Fragility. innerHTML output changes with every framework update, CSS-in-JS hash rotation, and ad network injection. The representation is unstable and framework-dependent. The accessibility tree is stable because it represents semantics, not implementation.

How Does Gasoline MCP Handle DOM Content?

Gasoline captures the accessibility tree directly from the browser via its Chrome extension. When an AI assistant calls the get_console_logs, get_accessibility_tree, or query_dom MCP tools, Gasoline returns structured, token-efficient data:

Accessibility tree: Full semantic structure of the page, typically 50-100x smaller than innerHTML
DOM queries: Targeted CSS selector queries returning only matching elements
Console logs: Errors and warnings already captured in real time, no DOM parsing needed

The result: your AI assistant gets the information it needs to debug your application without consuming the context window budget it needs to actually reason about the problem.

Get Started

npx gasoline-mcp@latest

One command. Zero dependencies. Your AI assistant gets clean, structured browser context instead of raw HTML noise.

Learn more about DOM queries ->

How to Generate Playwright Tests from Real Browser Sessions

Jan 26, 2025

Brenn Hill

Gasoline MCP is a browser extension and local server that captures real-time browser telemetry and makes it available to AI coding assistants via Model Context Protocol. It is the only MCP browser tool that can generate Playwright tests from recorded browser sessions.

The Problem with Manual Playwright Tests

Writing Playwright tests by hand is slow. You have to inspect the page, figure out the right selectors, reconstruct the sequence of user actions, and write assertions that actually verify meaningful behavior. For a single form submission flow, you might spend 20 minutes wiring up page.locator() calls, fill() sequences, and waitForResponse() handlers.

Most teams know they should write regression tests after fixing a bug. In practice, the effort-to-value ratio kills it. The bug is fixed. The PR is open. Nobody wants to spend another half hour writing a test for something that already works. So the test never gets written, and six months later the same bug comes back.

Record the Session, Generate the Test

Gasoline solves this by recording what actually happens in your browser. Every click, navigation, form fill, and network call is captured as structured data. When you are done, your AI assistant calls the generate_test MCP tool, and Gasoline produces a ready-to-run Playwright test file based on the real session.

There is no synthetic scenario construction. The test reflects exactly what happened in the browser.

Here is an example of what Gasoline generates after a session where you log in and update a user profile:

import { test, expect } from '@playwright/test';

test('update user profile after login', async ({ page }) => {
  await page.goto('http://localhost:3000/login');

  await page.locator('input[name="email"]').fill('[email protected]');
  await page.locator('input[name="password"]').fill('test-password');
  await page.locator('button[type="submit"]').click();

  await page.waitForURL('**/dashboard');

  await page.locator('a[href="/settings/profile"]').click();
  await page.locator('input[name="displayName"]').fill('Updated Name');

  const responsePromise = page.waitForResponse(
    (resp) => resp.url().includes('/api/users/profile') && resp.status() === 200
  );
  await page.locator('button:has-text("Save")').click();
  await responsePromise;

  await expect(page.locator('[data-testid="success-toast"]')).toBeVisible();
});

That test covers navigation, form interaction, API response validation, and UI confirmation. Gasoline generates it from the captured session data, not from a template.

Why This Matters for Regression Testing

The highest-value time to write a test is immediately after fixing a bug. You have just reproduced the issue, identified the root cause, and verified the fix. The exact sequence of actions that triggers the bug is fresh.

With Gasoline, you fix the bug in your normal browser, and the session is already recorded. Ask your AI assistant to generate a regression test, and you get a Playwright file that encodes the exact reproduction steps plus the expected passing behavior. That bug is now permanently guarded.

This turns regression testing from a discipline problem into a workflow byproduct.

How does Gasoline MCP generate Playwright tests?

Gasoline captures browser events through its Chrome extension: navigations, clicks, form inputs, and network requests with their responses. This telemetry is sent to the local Gasoline server over a WebSocket connection. When your AI assistant calls the generate_test MCP tool, Gasoline translates the recorded event timeline into sequential Playwright actions, mapping DOM interactions to locator strategies and network activity to response assertions.

What browser actions does it record?

Gasoline captures page navigations, link clicks, button clicks, form field inputs, select changes, checkbox toggles, and full network request/response pairs including status codes and URLs. It also captures console output and JavaScript exceptions, which can inform assertion logic in the generated tests.

No Other MCP Browser Tool Does This

Chrome DevTools MCP, BrowserTools MCP, and Cursor MCP Extension all provide some level of browser observability to AI assistants. None of them offer test generation. They can surface console logs and network errors, but they cannot turn a browsing session into a runnable Playwright test. Gasoline is the only tool in the MCP ecosystem with this capability.

Get Started

npx gasoline-mcp@latest

One command. No runtime dependencies. No accounts. See the full test generation guide for configuration options and advanced usage.

How to Give Cursor Access to Browser Console Logs

Jan 25, 2025

Brenn Hill

Cursor is a powerful AI code editor, but it has a blind spot: your browser. When your app throws an error at runtime, Cursor has no idea. You end up copying console output, screenshotting network tabs, and pasting fragments into chat — losing context every time.

Gasoline MCP is an open-source browser extension + MCP server that streams real-time browser telemetry to AI coding assistants. It connects Cursor directly to your browser so it can read console logs, network failures, and DOM state without you lifting a finger.

The Problem: Cursor Can’t See Your Browser

When something breaks in the browser, your workflow probably looks like this:

Notice a blank page or broken UI
Open Chrome DevTools
Read through the console errors
Copy the relevant ones
Paste them into Cursor and explain what happened

By the time Cursor sees the error, you’ve already done the hard part — finding it. And you’ve stripped away surrounding context: the network request that failed before the error, the sequence of console warnings that preceded it, the state of the DOM.

Cursor needs raw, continuous access to what the browser is doing.

Why Existing Approaches Fall Short

You could keep a DevTools window open and manually relay information to Cursor. But manual copy-paste has real costs:

Lost context. You copy one error but miss the failed API call that caused it.
Stale data. By the time you paste, the browser state has changed.
Friction. Every round trip between browser and editor breaks your flow.

Cursor supports MCP (Model Context Protocol) natively, which means any tool that speaks MCP can feed data directly into Cursor’s context. Gasoline uses this to bridge the gap.

What Cursor Can See Through Gasoline

Once connected, Cursor can query your browser for live telemetry:

Data Type	What Cursor Sees
Console logs	All `console.log`, `console.warn`, `console.error` output
JavaScript errors	Uncaught exceptions with full stack traces
Network requests	URLs, status codes, timing, headers
Network bodies	Request and response payloads (opt-in)
WebSocket messages	Real-time WS frame data
DOM state	Query elements, read attributes, check visibility

This is not a snapshot. Gasoline captures events continuously, so Cursor can ask “what happened in the browser?” at any point and get the full picture.

Setup: Four Steps

1. Start the Gasoline server

npx gasoline-mcp@latest

This downloads a single Go binary (no Node.js runtime, no node_modules/). It starts a local MCP server on your machine.

2. Install the Chrome extension

Install the Gasoline extension from the Chrome Web Store. It connects to the local server automatically.

3. Add the MCP server to Cursor

Open Cursor Settings, navigate to MCP, and add a new server with this configuration:

{
  "mcpServers": {
    "gasoline": {
      "command": "npx",
      "args": ["-y", "gasoline-mcp@latest"]
    }
  }
}

4. Ask Cursor to check the browser

In Cursor’s chat or agent mode, just ask:

“Check the browser for errors”

Cursor will call Gasoline’s MCP tools, read the captured telemetry, and respond with what it finds — and often fix the issue in the same turn.

Real Workflow: React Dashboard Blank Screen

Without Gasoline (5 steps):

See blank screen in browser
Open DevTools, find TypeError: Cannot read properties of undefined (reading 'map') in console
Switch to Network tab, notice the /api/dashboard request returned a 500
Copy both the error and the failed request details
Paste into Cursor, explain the situation, wait for a fix

With Gasoline (1 step):

Ask Cursor: “The dashboard page is blank. Check the browser and fix it.”

Cursor reads the console error and the failed network request simultaneously through Gasoline, identifies that the API returned a 500 causing an undefined .map() call, and adds a null check or error boundary — all in one turn.

How do I connect Cursor to my browser?

Install the Gasoline Chrome extension and add the MCP server config to Cursor’s settings. Gasoline handles the connection between browser and editor over localhost. No accounts, no cloud services, no API keys.

Is Gasoline MCP secure?

Gasoline runs entirely on your machine. The server binds to 127.0.0.1 only and rejects non-localhost connections at the TCP level. It never makes outbound network calls. Sensitive headers (Authorization, Cookie) are stripped from captured network data by default. Request and response body capture is opt-in.

Get Started

npx gasoline-mcp@latest

One command to give Cursor full visibility into your browser. For the complete Cursor integration guide, see the Cursor + Gasoline setup docs.

How to Debug Browser Errors with Claude Code Using MCP

Jan 24, 2025

Brenn Hill

Claude Code is powerful, but it has a blind spot: it can’t see your browser. When your frontend throws an error, you open DevTools, find the relevant console message, copy it, switch to your terminal, paste it, and hope you grabbed enough context. This is slow, lossy, and breaks your flow.

Gasoline MCP is an open-source browser extension + MCP server that streams real-time browser telemetry (console logs, network errors, exceptions, WebSocket events) to AI coding assistants like Claude Code, Cursor, Windsurf, and Zed. It closes the feedback loop between browser and AI — automatically.

The Problem: Manual Copy-Paste Debugging

Without browser access, Claude Code operates on incomplete information. A typical debugging cycle looks like this:

You make a code change
You reload the browser
Something breaks
You open DevTools, scroll through console output
You copy the error, maybe the stack trace
You paste it into Claude Code
Claude asks a follow-up — back to DevTools

You lose context at every step. Stack traces get truncated. Network errors get missed entirely. You never think to check the WebSocket connection that silently dropped.

How Gasoline Solves This

Gasoline connects your browser directly to Claude Code via MCP (Model Context Protocol). Once connected, Claude Code can:

Read console logs — errors, warnings, and info messages with full stack traces
See network failures — failed API calls with status codes, URLs, and timing
Inspect request/response bodies — see exactly what your API returned
Monitor WebSocket events — catch dropped connections and malformed frames
Query the DOM — inspect element state with CSS selectors
Generate Playwright tests — turn a real browser session into a reproducible test

Instead of you copying errors to Claude, Claude pulls what it needs directly.

How Do I Connect Claude Code to My Browser?

Setup takes under 60 seconds.

Step 1: Start the server

npx gasoline-mcp@latest

Single Go binary. No Node.js runtime. No node_modules/. Zero dependencies.

Step 2: Install the Chrome extension

Grab it from the Chrome Web Store (search “Gasoline”). The toolbar icon shows Connected when the server is running.

Step 3: Add the MCP config

Add this to .mcp.json in your project root:

{
  "mcpServers": {
    "gasoline": {
      "command": "npx",
      "args": ["-y", "gasoline-mcp@latest"]
    }
  }
}

Restart Claude Code. The server starts automatically on every session.

Step 4: Ask Claude

Open your web app in Chrome and ask:

“What errors are in the browser?”

Claude Code calls Gasoline’s observe tool and gets back structured data — not a screenshot, not a blob of text, but parsed console entries with timestamps, levels, stack traces, and source locations.

What Browser Data Can Claude Code See Through Gasoline MCP?

Gasoline exposes five composite tools to Claude Code:

Tool	What Claude Can Do
`observe`	Read console errors, network requests, WebSocket events, Web Vitals, page info
`analyze`	Detect performance regressions, audit accessibility, diff sessions
`generate`	Create Playwright tests, reproduction scripts, HAR exports
`configure`	Filter noise, manage log levels, set persistent memory
`query_dom`	Inspect live DOM state using CSS selectors

When Claude calls observe with what: "errors", it gets back every console error from the active tab — structured, timestamped, and ready to act on. When it calls observe with what: "network", it sees every failed HTTP request with status codes, URLs, headers, and optionally full response bodies.

This is not a one-shot snapshot. Gasoline streams continuously. Claude sees errors the moment they happen.

What About Privacy?

Gasoline runs entirely on localhost. The server binary binds to 127.0.0.1 only, rejects non-localhost connections at the TCP level, and never makes outbound network calls. Authorization headers are stripped by default. Request/response body capture is opt-in.

No data leaves your machine. No accounts. No telemetry.

Get Started

npx gasoline-mcp@latest

One command. Zero dependencies. Claude Code sees your browser in under a minute.

Full setup guide

MCP Browser Debugging Tools Compared (2025)

Jan 23, 2025

Brenn Hill

If you’re using an AI coding assistant (Claude Code, Cursor, Windsurf), you’ve probably wished it could see your browser. Several MCP-based tools now make that possible — but they take different approaches.

Here’s a practical breakdown of the options.

The Landscape

Four tools currently give AI assistants browser access via MCP:

Tool	Architecture	Approach
Gasoline	Extension + Go binary	Passive capture
Chrome DevTools MCP	Puppeteer-based server	Active control
BrowserTools MCP	Extension + Node server + MCP server	Passive capture + Lighthouse
Cursor MCP Extension	Extension + MCP server	Passive capture

Passive vs Active: The Fundamental Split

The biggest architectural difference is passive capture vs active control.

Passive Capture (Gasoline, BrowserTools, Cursor MCP)

You browse normally. The extension watches what happens — console logs, network errors, exceptions — and makes that data available to your AI.

Pros:

Zero interference with your browsing
Captures real user behavior
Works on any page you visit

Cons:

Can’t click buttons or navigate programmatically
Can’t take screenshots (traditionally — though some add this)

Active Control (Chrome DevTools MCP)

The tool takes control of a Chrome instance via the Chrome DevTools Protocol (Puppeteer). It can navigate, click, screenshot, and inspect.

Pros:

Full browser automation
Can reproduce issues programmatically
Can take screenshots

Cons:

Requires a separate Chrome instance
Can’t observe your normal browsing
Needs Chrome debug port open

Dependencies Matter

For enterprise environments, the dependency footprint matters:

Tool	Runtime	Install Size	Supply Chain
Gasoline	None (single Go binary)	~10MB	Zero deps
Chrome DevTools MCP	Node.js 22+	~200MB+	Puppeteer + deps
BrowserTools MCP	Node.js	~150MB+	Multiple npm packages
Cursor MCP Extension	Node.js	~100MB+	npm packages

Gasoline’s zero-dependency approach means no node_modules/ folder, no lock file drift, and no supply chain risk. The binary you audit is the binary you run.

Privacy: Where Does Data Go?

Tool	Data Stays Local?	Telemetry	Auth Handling
Gasoline	Yes (127.0.0.1 only)	None	Headers stripped
Chrome DevTools MCP	Depends on config	Unknown	Not stripped
BrowserTools MCP	Yes	Unknown	Not stripped
Cursor MCP Extension	Yes	Unknown	Not stripped

Gasoline is the only tool that architecturally guarantees data locality — the server binary rejects non-localhost connections at the TCP level and never makes outbound network calls.

Performance Impact

Tool	Page Load Impact	Per-Event Overhead	Memory Cap
Gasoline	Zero (deferred init)	< 0.1ms	20MB soft, 50MB hard
Chrome DevTools MCP	N/A (separate instance)	N/A	Unbounded
BrowserTools MCP	Unknown	Unknown	Unknown
Cursor MCP Extension	Unknown	Unknown	Unknown

Gasoline enforces strict SLOs with adaptive sampling for high-frequency events (WebSocket, network bodies).

Feature Comparison

Feature	Gasoline	DevTools MCP	BrowserTools	Cursor MCP
Console capture	Yes	Yes	Yes	Yes
Network errors	Yes	Yes	Yes	Yes
Network bodies	Yes	Partial	No	No
WebSocket monitoring	Yes	No	No	No
DOM queries	Yes	Yes (full control)	No	No
Accessibility audit	Yes (axe-core)	No	Yes (Lighthouse)	No
Test generation	Yes (Playwright)	No	No	No
Screenshots	No	Yes	Yes	No
Browser control	No	Yes	No	No

When to Choose What

Choose Gasoline if:

You want zero dependencies and zero supply chain risk
Enterprise security policies require local-only data handling
You need WebSocket monitoring or network body capture
You want to generate Playwright tests from real sessions
You use any MCP-compatible tool (not just Cursor)

Choose Chrome DevTools MCP if:

You need to automate browser actions
You want screenshot capabilities
You’re building testing/scraping workflows

Choose BrowserTools MCP if:

You specifically need Lighthouse audits
You’re already invested in the Node.js ecosystem

Choose Cursor MCP Extension if:

You only use Cursor
You want the simplest possible setup

How do I get started with Gasoline?

npx gasoline-mcp

One command. No Node.js runtime. No accounts. Full setup guide →