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

171–180 of 266 posts

Re: Chrome DevTools MCP (2025)

#171

Post by whattheheckheck »

bloppe wrote: post #154
zeroxfe wrote: post #98

Earlier quoted context omitted.

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

> you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity You're describing MCP. After all, MCP is just reinventing the OpenAPI wheel. You can just have a self-documenting REST API using OpenAPI. Put the spec in your context and your model knows how to use it. You can have all the RBAC and rate limiting and auth you want. Heck, you could even bu…

The clients for mcp can drop a url and http in the mcp.json and get access to the application. Can the client do that for every rest api?

Re: Chrome DevTools MCP (2025)

#172

Post by m00dy »

Connecting a remote VPS to a local Chrome session is usually a headache. It gets complicated when your Claw setup is on the server but the browser session stays on your own machine. I ended up using Proxybase’s relay [0] to bridge the gap, and it actually solved the connection issues for me.

[0] https://relay.proxybase.xyz

Re: Chrome DevTools MCP (2025)

#173

Post by yammosk »

rsalus wrote: post #123
quotemstr wrote: post #107

Earlier quoted context omitted.

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.

There are actually a lot of great things you can to to make CLIs more helpful to agents. I use a structured help called '--capabilities' but there is a ton of JIT context you can do from the CLI as well https://keyboardsdown.com/posts/01-agent-first-clis/

Re: Chrome DevTools MCP (2025)

#174

Post by bloppe »

whattheheckheck wrote: post #171
bloppe wrote: post #154

Earlier quoted context omitted.

> you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity You're describing MCP. After all, MCP is just reinventing the OpenAPI wheel. You can just have a self-documenting REST API using OpenAPI. Put the spec in your context and your model knows how to use it. You can have all the RBAC and rate limiting and auth you want. Heck, you could even bu…

The clients for mcp can drop a url and http in the mcp.json and get access to the application. Can the client do that for every rest api?

Ya, if you just use OpenAPI. That's why I'm saying MCP adds nothing. It's just another standard for documenting APIs. There are many that have been around for a long time and that are better integrated with existing ecosystems. There's also gRPC reflection. I'm sure there are others. LLMs can use them all equally effectively.

Re: Chrome DevTools MCP (2025)

#175

Post by AlphaSite »

bredren wrote: post #109
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…

its mostly because MCPs handle auth in a standardised way and give you a framework you can layer things like auth, etc on top of.

Without it youre stuck with the basic http firewall, etc which is extremely dangerous and this is maybe the 1 opportunity we have to do this.

Re: Chrome DevTools MCP (2025)

#177

Post by zipping1549 »

varenc wrote: post #89
dawnerd wrote: post #61

Earlier quoted context omitted.

Don’t know how this could be more stable than ytdlp. When issues come up they’re fixed really quickly.

yt-dlp was very recently broken for ~2 days for any Youtube videos that required cookies: https://github.com/yt-dlp/yt-dlp/issues/16212 Here is what actually fixed it: https://github.com/yt-dlp/ejs/pull/53/changes yt-dlp is relatively stable, but still occasionally breaks for long periods. I get the sense YouTube is becoming increasingly adversarial to yt-dlp as well. I don't know the details, but it doesn't seem lik…

> const url = (${generate(expression)})("https://youtube.com/watch?v=yt-dlp-wins", "s", sig);

I'm pretty sure yt-dlp is filled with these kinds of gold.

Re: Chrome DevTools MCP (2025)

#178

Post by vinmay »

For something like Chrome DevTools MCP with authenticated browser sessions, the specific risk is credentials in the browser context + any SEND capability reachable from the same entry points. If a page can inject a prompt that triggers a tool call, and that call path can also reach outbound network I/O, you have an exfiltration vector without needing shell access at all.

Re: Chrome DevTools MCP (2025)

#179

Post by nubsero »

I’ve been experimenting with a similar approach using Playwright, and the biggest takeaway for me was how much “hidden API” most modern websites actually have.

Once you start mapping interactions → network calls, a lot of UI complexity just disappears. It almost feels like the browser becomes a reverse-engineering tool for undocumented APIs.

That said, I do think there’s a tradeoff people don’t talk about enough:

- Sites change frequently, so these inferred APIs can be brittle - Auth/session handling gets messy fast - And of course, the ToS / ethical side is a gray area

Still, for personal automation or internal tooling, it’s insanely powerful. Way more efficient than driving full browser sessions for everything.

Curious how others are handling stability — are you just regenerating these mappings periodically, or building some abstraction layer on top?

Re: Chrome DevTools MCP (2025)

#180

Post by lewisjoe »

cheema33 wrote: post #67
commanderkeen08 wrote: post #51

Earlier quoted context omitted.

MCPs cost nothing in CC now with Tool Search.

> MCPs cost nothing in CC now with Tool Search. This is incorrect. Plenty of people have run the numbers. Tool search does not fix all problems with MCP.

Can you elaborate more?
Post reply on HN