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

101–110 of 266 posts

Re: Chrome DevTools MCP (2025)

#101

Post by mikrl »

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 was doing similar by capturing XHR requests while clicking through manually, then asking codex to reverse engineer the API from the export.

Never tried that level of autonomy though. How long is your iteration cycle?

If I had to guess, mine was maybe 10-20 minutes over a few prompts.

Re: Chrome DevTools MCP (2025)

#105

Post by quotemstr »

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…

> 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

What about all the CLI tools not baked into the model's priors?

Every time someone says "extensibility mechanism X is dead!", I think "Well, I guess that guy isn't doing anything that needs to extend the statistical average of 2010s-era Reddit"

Re: Chrome DevTools MCP (2025)

#106

Post by bartek_gdn »

mh- wrote: post #7
Etheryte wrote: post #3

Earlier quoted context omitted.

On one hand, cool demo, on the other, this is horrifying in more ways than I can begin to describe. You're literally one prompt injection away from someone having unlimited access to all of your everything.

Not the person you're replying to, but: I just use a separate, dedicated Chrome profile that isn't logged into anything except what I'm working on. Then I keep the persistence, but without commingling in a way that dramatically increases the risk. edit: upon rereading, I now realize the (different) prompt injection risk you were calling out re: the handoff to yt-dlp. Separate profiles won't save you from that, though…

That's also my approach, built quickly a cli for this with lightweight session management

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

Re: Chrome DevTools MCP (2025)

#107

Post by quotemstr »

Torn wrote: post #83
rsalus wrote: post #56

Earlier quoted context omitted.

MCP is very much not dead. centralized remote MCP servers are incredibly useful. also bespoke CLIs still require guidance for models to use effectively, so it's clear that token efficiency is still an issue regardless.

Tbh I find self-documenting CLIs (e.g. with a `--help` flag, and printing correct usage examples when LLMs make things up) plus a skill that's auto invoked to be pretty reliable. CLIs can do OAuth dances too just fine. MCP's remaining moats I think are: - No-install product integrations (just paste in mcp config into app) - Non-developer end users / no shell needed (no terminal) - Multi-tenant auth (many users, dynam…

Imagine if, in addition to local MCP "servers", the MCP people had nurtured a structured CLI-based --help-equivalent consumable by LLMs and shell completion engines alike. Doing so, you unify "CLI" (trivial deployment; human accessibility) and MCP-style (structured and discoverable tool calling) in a single DWIM artifact.

But since when has this industry done the right thing informed by wisdom and hindsight?

Re: Chrome DevTools MCP (2025)

#108

Post by ElectricalUnion »

paseante wrote: post #102

[flagged]

> interface designed for humans — the DOM.

Citation needed.

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

To me, sites that "only have human interfaces" are more likely that not be that way totally on purpose, attempting to maximize human retention/engagement and are more likely to require strict anti-bot measures like Proof-of-Work to be usable at all.

Re: Chrome DevTools MCP (2025)

#109

Post by bredren »

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 also do this. My primary use case is for reproducing page layout and styling at any given tree in the dom. So, capturing various states of a component etc.

I also use it to automatically retrieve page responsiveness behavior in complex web apps. It uses playwright to adjust the width and monitor entire trees for exact changes which it writes structured data that includes the complete cascade of styles relevant with screenshots to support the snapshots.

There are tools you can buy that let you do this kind of inspection manually, but they are designed for humans. So, lots of clickety-clackety and human speed results.

---

My first reaction to seeing this FP was why are people still releasing MCPs? So far I've managed to completely avoid that hype loop and went straight to building custom CLIs even before skills were a thing.

I think people are still not realizing the power and efficiency of direct access to things you want and skills to guide the AI in using the access effectively.

Maybe I'm missing something in this particular use case?

Post reply on HN