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

121–130 of 266 posts

Re: Chrome DevTools MCP (2025)

#121

Post by rsalus »

attentive wrote: post #113
abhis3798 wrote: post #79

Earlier quoted context omitted.

I see remote MCP servers as a great interface to consume api responses. The idea that you essentially make your apis easily available to agents to bring in relevant context is a powerful one. When folks say MCP is dead, I don't get it. What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint?

> What other alternatives exist in place of MCP? Arbitrary code via curl/sdks to call a remote endpoint? cli? for example aws cli. It's a full interface to aws API. Why would you need mcp for that? and if you have any doubts, agents use it with a great effect even without any relevant skill. "aws help" is fully discoverable.

yes, but clis thus need self-service commands to provide guidance, and their responses need to be optimized for consumption by agents. in a sense, this is the same sort of context tax that MCP servers incur. so in my view cli and MCP are complementary tools; one is not strictly superior over the other.

Re: Chrome DevTools MCP (2025)

#122

Post by imiric »

paseante wrote: post #102

[flagged]

> What we actually need is a standard for websites to expose a machine-readable interaction layer alongside the human one.

We had this 20 years ago with the Semantic Web movement, XHTML, and microformats. Sadly, it didn't pan out for various reasons, most of them non-technical. There's remnants of it today with RSS feeds, which is either unsupported or badly supported by most web sites.

Once advertising became the dominant business model on the web, it wasn't in publishers' interest to provide a machine-readable format of their content. Adtech corporations took control of the web, and here we are. Nowadays even API access is tightly controlled (see Reddit, Twitter, etc.).

So your idea will never pan out in practice. We'll have to continue to rely on hacks and scraping will continue to be a gray area. These new tools make automated scraping easier, for better or worse, but publishers will find new ways to mitigate it. And so it goes.

Besides, if these new tools are "superintelligent", surely they're able to navigate a web site. Captchas are broken and bot detection algorithms (or "AI" themselves) are unreliable. So I'd say the leverage is on the consumer side, for now.

Re: Chrome DevTools MCP (2025)

#123

Post by rsalus »

quotemstr wrote: post #107
Torn wrote: post #83

Earlier quoted context omitted.

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?

that's a pretty interesting idea. It would be nice if there was such a standard. the approach I'm taking right now: a CLI that accepts structured JSON as input, with an 'mcp' subcommand that starts a stdio server. I bundle a 'help' command with a 'describe' action for self-service guidance scoped to a particular feature/tool.

Re: Chrome DevTools MCP (2025)

#124

Post by halJordan »

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

Re: Chrome DevTools MCP (2025)

#125

Post by Rapzid »

cheema33 wrote: post #66
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…

> Also MCP is very obviously dead Some people will push back on this. They are holding out hope that the recent improvements Anthropic has made in this regard have improved the context rot problem with MCP. Anthropic's changes improve things a little. But it is akin to putting lipstick on a pig. It helps, but not much. The reason MCP is dying/dead is because MCP servers, once configured, bloat up context even when th…

The bloat problem is already out dated though. People are having the LLM pick the MCP servers it needs for a particular task up front, or picking them out-of-band, so the full list doesn't exist in the context every call.

Re: Chrome DevTools MCP (2025)

#126

Post by miohtama »

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 just ask Claude to reverse engineer the site with Chrome MCP. It goes to work by itself, uses your Chrome logged in session cookies, etc.

Re: Chrome DevTools MCP (2025)

#127

Post by maxaw »

paseante wrote: post #102

[flagged]

Fully agree. Will take some time though as immediate incentive not clear for consumer facing companies to do extra work to help ppl bypass website layer. But I think consumers will begin to demand it, once they experience it through their agent. Eg pizza company A exposes an api alongside website and pizza company B doesn’t, and consumer notices their agent is 10x+ faster interacting with company A and begins to question why.

Re: Chrome DevTools MCP (2025)

#128

Post by vesselapi »

raw_anon_1111 wrote: post #22

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…

Yes, running Chromium in a Docker container works well for this. There are prebuilt images like https://hub.docker.com/r/browserless/chrome that give you a headless instance you can connect to via CDP (Playwright, Puppeteer). Keeps everything isolated from your actual browser profile and credentials.

Re: Chrome DevTools MCP (2025)

#129

Post by moritonal »

zeroxfe wrote: post #98
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…

> Also MCP is very obviously dead, as any of us doing heavy agentic coding know. As someone that does heavy agentic coding (using basically all the tools), this is so far from the truth. People claiming this have probably never worked in large enterprise environments where things like authentication, RBAC, rate limiting, abuse detection, centralized management/updates/ops, etc. are a huge part of the development and…

Given MCP is supposed to just be a standardised format for self-describing APIs, why are all the features you listed MCP related things? It sounds more like it's forced the enterprise to build such features which cli tooling didn't have?

Re: Chrome DevTools MCP (2025)

#130

Post by heystefan »

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…

Commenting to follow up.
Post reply on HN