logoalt Hacker News

Let your Coding Agent debug the browser session with Chrome DevTools MCP

235 pointsby xnxtoday at 7:12 PM102 commentsview on HN

Comments

dataviz1000today at 9:17 PM

I use Playwright to intercept all requests and responses and have Claude Code navigate to a website like YouTube and click and interact with all the elements and inputs while recording all the requests and responses associated with each interaction. Then it creates a detailed strongly typed API to interact with any website using the underlying API.

Yes, I know it likely breaks everybody's terms of service but at the same time I'm not loading gigabytes of ads, images, markup, to accomplish things.

If anyone is interested I can take some time and publish it this week.

show 11 replies
mmaundertoday at 9:14 PM

Google is so far behind agentic cli coding. Gemini CLI is awful. So bad in fact that it’s clear none of their team use it. Also MCP is very obviously dead, as any of us doing heavy agentic coding know. Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in. Playwright with headless Chromium or headed chrome is what anyone serious is using and we get all the dev and inspection tools already. And it works perfectly. This only has appeal to those starting out and confused into thinking this is the way. The answer is almost never MCP.

show 8 replies
aadishvtoday at 7:39 PM

Someone already made a great agent skill for this, which I'm using daily, and it's been very cool!

https://github.com/pasky/chrome-cdp-skill

For example, I use codex to manage a local music library, and it was able to use the skill to open a YT Music tab in my browser, search for each album, and get the URL to pass to yt-dlp.

Do note that it only works for Chrome browsers rn, so you have to edit the script to point to a different Chromium browser's binary (e.g. I use Helium) but it's simple enough

show 1 reply
paseantetoday at 10:38 PM

The real problem this thread exposes is that we're duct-taping browser automation (Playwright, CDP, MCP wrappers) onto an interface designed for humans — the DOM. Every approach discussed here is fighting the same battle: too many tokens to represent page state, flaky selectors, hallucinated DOM structures, massive context cost.

What we actually need is a standard for websites to expose a machine-readable interaction layer alongside the human one. Something like robots.txt but for agent capabilities — declaring available actions, their parameters, authentication requirements, and response schemas. Not scraping the DOM and hoping the AI figures out which button to click.

The web already went through this evolution once: we went from screen-scraping HTML to structured APIs. Now we're regressing back to scraping because agents need to interact with sites that only have human interfaces. A lightweight standard — call it agents.json or whatever — where sites declare "here are the actions you can take, here are the endpoints, here's the auth flow" would eliminate 90% of the token waste, security concerns, and fragility discussed in this thread.

Until that exists, we'll keep building increasingly clever hacks on top of a 30-year-old document format that was never designed for machine consumption.

show 4 replies
paulirishtoday at 9:24 PM

The DevTools MCP project just recently landed a standalone CLI: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/m...

Great news to all of us keenly aware of MCP's wild token costs. ;)

The CLI hasn't been announced yet (sorry guys!), but it is shipping in the latest v0.20.0 release. (Disclaimer: I used to work on the DevTools team. And I still do, too)

show 1 reply
bartek_gdntoday at 10:52 PM

My approach is a thin cli wrapper instead.

https://news.ycombinator.com/item?id=47207790

netdurtoday at 10:29 PM

I wrote an ai agent that do chrome testing, yes, chrome MCP do work https://github.com/netdur/hugind/tree/main/agent/chrome_test...

zxspectrumk48today at 8:12 PM

I found this one working amazingly well (same idea - connect to existing session): https://github.com/remorses/playwriter

cheema33today at 9:57 PM

How does this compare with playwright CLI?

https://github.com/microsoft/playwright-cli

show 2 replies
anesxvitotoday at 10:14 PM

Been using MCP tooling heavily for a few months and browser debugging integration is one of those things that sounds gimmicky until you actually try it. The real question is whether it handles flaky async state reliably or just hallucinates what it thinks the DOM looks like?

tonyhschutoday at 8:53 PM

Very cool. I do something like this but with Playwright. It used to be a real token hog though, and got expensive fast. So much so that I built a wrapper to dump results to disk first then let the agent query instead. https://uisnap.dev/

Will check this out to see if they’ve solved the token burn problem.

boomskatstoday at 8:25 PM

Been using this one for a while, mostly with codex on opencode. It's more reliable and token efficient than other devtools protocol MCPs i've tried.

Favourite unexpected use case for me was telling gemini to use it as a SVG editing repl, where it was able to produce some fantastic looking custom icons for me after 3-4 generate/refresh/screenshot iterations.

Also works very nicely with electron apps, both reverse engineering and extending.

holoduketoday at 10:53 PM

One tip for the illegal scrapers or automators out there. Casperjs and phanthomjs are still working very well for anti bot detection. These are very old libs no longer maintained. But I can even scrape and authenticate at my banks.

rossvctoday at 9:07 PM

I've been using the DevTools MCP for months now, but it's extremely token heavy. Is there an alternative that provides the same amount of detail when it comes to reading back network requests?

senandtoday at 9:03 PM

I suggest to use https://github.com/simonw/rodney instead

show 1 reply
raw_anon_1111today at 8:43 PM

I don’t do any serious web development and haven’t for 25 years aside from recently vibe coding internal web admin portals for back end cloud + app dev projects. But I did recently have to implement a web crawler for a customer’s site for a RAG project using Chromium + Playwrite in a Docker container deployed to Lambda.

I ran the Docker container locally for testing. Could a web developer test using Claude + Chromium in a Docker container without using their real Chrome instance?

silverwindtoday at 9:22 PM

I found Firefox with https://github.com/padenot/firefox-devtools-mcp to work better then the default Chrome MCP, is seems much faster.

NiekvdMaastoday at 7:53 PM

Also works nicely together with agent-browser (https://github.com/vercel-labs/agent-browser) using --auto-connect

speedgoosetoday at 7:53 PM

Interesting. MCP APIs can be useful for humans too.

Chrome's dev tools already had an API [1], but perhaps the new MCP one is more user friendly, as one main requirement of MCP APIs is to be understood and used correctly by current gen AI agents.

[1]: https://chromedevtools.github.io/devtools-protocol/

glerktoday at 9:02 PM

Note that this is a mega token guzzler in case you’re paying for your own tokens!

oldeucryptoboitoday at 8:52 PM

I tell Claude to use playwright so I don't even need to do the setup myself.

show 1 reply
pritesh1908today at 8:57 PM

I have been using Playwright for a fairly long time now. Do checkout

slrainkatoday at 8:48 PM

chrome-cli with remote developer port has been working fine this entire time.

JKoliostoday at 8:57 PM

Now that there's widespread direct connectivity between agents and browser sessions, are CAPTCHAs even relevant anymore?

Yokohiiitoday at 7:48 PM

Was already eye rolling about the headline. Then I realized it's from chrome.

Hoping from some good stories from open claw users that permanently run debug sessions.

robutsumetoday at 10:02 PM

[dead]

aplomb1026today at 10:04 PM

[dead]

ptak_devtoday at 9:26 PM

[dead]

myraktoday at 8:02 PM

[dead]

AlexDunittoday at 8:01 PM

[flagged]

show 2 replies
Sonofg0thamtoday at 7:50 PM

[flagged]

show 1 reply