Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome DevTools MCP (2025)

developer.chrome.com

Post reply on HN
Print view View original

191–200 of 266 posts

Re: Chrome DevTools MCP (2025)

#191

Post by Barbing »

dataviz1000 wrote: post #100
dsrtslnd23 wrote: post #97

Earlier quoted context omitted.

you mean this one? https://github.com/vercel-labs/agent-browser

It is 2 months old! My excuse for not keeping up is that I'm in so deep that Claude Code can predict the stock market. I'll still publish mine and see if has any value but agent browser looks very complete. Thank you for sharing!

>I'm in so deep that Claude Code can predict the stock market.

“What?”, more polite than “yeah right” :)

(oh I guess obviously it would have a chance at nailing it for weeks in a row, and have more good years than bad—since actively managed funds can pull that off until, universally, they can’t [beat the market])

Re: Chrome DevTools MCP (2025)

#193

Post by flash_us0101 »

mmaunder wrote: post #41
rossvc wrote: post #35

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?

Yes. CLI. Always CLI. Never MCP. Ever. You’re welcome.

CLI is great when you know what command to run. MCP is great when the agent decides what to run - it discovers tools without you scripting the interaction.

The real problem isn't MCP vs CLI, it's that MCP originally loaded every tool definition into context upfront. A typical multi-server setup (GitHub, Slack, Sentry, Grafana, Splunk) consumes ~55K tokens in definitions before Claude does any work. Tool selection accuracy also degrades past 30-50 tools.

Anthropic's Tool Search fixes this with per-tool lazy loading - tools are defined with defer_loading: true, Claude only sees a search index, and full schemas load on demand for the 3-5 tools actually needed. 85% token reduction. The original "everything upfront" design was wrong, but the protocol is catching up.

Re: Chrome DevTools MCP (2025)

#194

Post by hugs »

mmaunder wrote: post #40

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…

some serious people use vibium instead. (full-disclosure: "some serious people" is me.)

Re: Chrome DevTools MCP (2025)

#195

Post by hugs »

schainks wrote: post #86
dataviz1000 wrote: post #43

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…

Very interested. Would even pay for an api for this. I am doing something similar with vibium and need something more token efficient.

have you tried vibium's cli + agent skill?

Re: Chrome DevTools MCP (2025)

#196

Post by synalx »

mmaunder wrote: post #40

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…

Antigravity's coding agent is worlds apart from Gemini CLI, though.

Re: Chrome DevTools MCP (2025)

#197

Post by zx8080 »

cyberax wrote: post #186
halJordan wrote: post #124

Earlier quoted context omitted.

I love how HN is loving this idea when it's the exact same thing Anthropic and OpenAi (and every other llm maker) did. It's God's gift to them when it lets them bypass ads and dl copyrighted material. But it's Satan's curse on humanity when the Zuck does it to train his llm and dl copyrighted material.

I would love to pay for content. I'm _paying_ for YouTube Premium. But heck. Do I hate the YouTube interface, it degraded far past usability.

Write to their support. Oh, wait.

Re: Chrome DevTools MCP (2025)

#198

Post by guard402 »

We tested this — the default take_snapshot path (Accessibility.getFullAXTree) is safe. It filters display:none elements because they're excluded from the accessibility tree.

But evaluate_script is the escape hatch. If an agent runs document.body.textContent instead of using the AX tree, hidden injections in display:none divs show up in the output. innerText is safe (respects CSS visibility), textContent is not (returns all text nodes regardless of styling).

The gap: the agent decides which extraction method to use, not the user. When the AX tree doesn't return enough text, a plausible next step is evaluate_script with textContent — which is even shown as an example in the docs.

Also worth noting: opacity:0 and font-size:0 bypass even the safe defaults. The AX tree includes those because the elements are technically 'rendered' and accessible to screen readers. display:none is just the most common hiding technique, not the only one.

Re: Chrome DevTools MCP (2025)

#199

Post by 3abiton »

dataviz1000 wrote: post #43

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…

I always used playwrite as an alternative to selenium, relatively surprised by its ability to interface with LLMs.
Post reply on HN