Hacker News

I do this via BrowserOS -- https://github.com/browseros-ai/BrowserOS

It has an in-built MCP server and I use it with claude code, codex and like it quite a lot.

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?

I do something similar [1] but it leverages WebMCP (see Amazon example [2]). Could probably turn it into a strongly typed API.

[1] https://github.com/sidwyn/webmcp-tool-library

[2] https://github.com/sidwyn/webmcp-tool-library/blob/main/cont...

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.

Why even use Playwright for this? I feel like Claude just needs agent-browser and it can generate deterministic code from it.

yes please! i need a "comment to follow" functionality on HN

Please do.

Did you compare playwright with mcp? Why one over another?

I use MCP usually, because I heard it’s less detectable than playwright, and more robust against design changes, but I didn’t compare/test myself

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

I use chrome devtools MCP to the same end - it works great for me. Interested in what advantages you see in using Playwright over chrome devtools?

Would this hypothetically be able to download arbitrary videos from youtube without the constant yt-dlp arms race?

Yes, please do and ping me when it's done lol. Did you make it into an agent skill?

I would like to see this!

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.

I would love it if you had time to publish it!

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.

I assume you're not logged into those sites, in order to avoid bans and the risk of hitting the wrong button like, say, "Delete Account".

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

+1, publish, but how will we know when you have published...

Yes, please do!

Id like to see this published as well thx!

Please do!

Please publish!

Commenting to follow up.

Wow. Yes please.

isnt it what everyone that needs web validation does?

[dead]

Love the Mitch Hedberg reference! Thank you! Always good to get a little Mitch!

‘I don’t have a girlfriend. But I do know a woman who’d be mad at me for saying that.’

‘I’m against picketing, but I don’t know how to show it.’

‘I haven’t slept for ten days, because that would be too long.’

‘I like to play blackjack. I’m not addicted to gambling. I’m addicted to sitting in a semi-circle.’

It doesn't seem to work, tried the -u flag with the default address and it just couldn't connect to the existing chrome instance.

The big upside of the MCP is that it connects to already open browser windows. I tried the skill but it always tries to open new windows. Is there a way to get the `--autoConnect` behaviour with the CLI?

Woah got this for the first time.

> Too many requests

You have exceeded a secondary rate limit.

Please wait a few minutes before you try again; in some cases this may take up to an hour. Signing in may provide a higher rate limit if you are not already signed in.

For more on scraping GitHub and how it may affect your rights, please review our Terms of Service.

MCPs cost nothing in CC now with Tool Search.

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.

> Most browser automation tools launch a fresh, isolated browser. This one connects to the Chrome you're already running

Is this the same as what Claude in Chrome does?

I tried that for a while and since I use Firefox and Chromium, the security problem of it seeing your tabs wasn't a big deal. Fresh Chrome install, only ever used for this exact purpose. Plus you can watch it working in real (actually very slow) time so if you did point it at something risky you can take over at any point.

For actual testing of web apps though, a skill with playwright cli in headless mode is much more effective. About 1-2k context per interaction after a bit of tuning.

To be clear, this isn't a skill for the devtools mcp, but an independent project. It doesn't look bad, but obviously browser automation + agents is a very busy space with lots of parallel efforts.

DevTools MCP and its new CLI are maintained by the team behind Chrome DevTools & Puppeteer and it certainly has a more comprehensive feature set. I'd expect it to be more reliable, but.. hey open source competition breeds innovation and I love that. :)

(I used to work on the DevTools team. And I still do, too)

Does anyone really use these hacked up with duct tape skills? why not use something more reliable like playwriter.dev?

Mhh, yt-dlp already has a build in youtube search, could you not use that instead of anything with AI?

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

In these situations you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity. MCP is really useful here, and allows centralized eng and ops teams to manage their services in a way that aligns with the organizations overall posture, policies, and infrastructure.

> Google is so far behind agentic cli coding. Gemini CLI is awful.

This part I totally agree. It's really hard to express how bad it is (and it's really disappointing.)

FYI: Gemini Cli is used internally at Google. It's actually more popular than Antigravity. Google uses MCP services internally for code search (since everything is in a mono-repo you don't want to waste time grepping billions of files), accessing docs and bugs, and also accessing project specific RAG databases for expertise grounding.

Source - I know people at Google.

> 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 they are not being used. Why would anybody want that?

Use agent skills. And say goodbye to MCP. We need to move on from MCP.

MCP is dead? Which cli tool should we use to instruct Chrome to open a page and click the Open button? And to read what appears in the console after clicking?

MCP permanently sacrifice a chunk of the context window? And a skill for you cli is free?

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.

I don't know if this just anecdotal random impression, but in a last week or two I had mostly good experience with Google cli. While previously I constantly complained about it. I have been using it together with codex, and I would not say that one is much better than another.

It is hard to say nowadays, when things change so quickly

Gemini 3.1 Pro through Gemini CLI always tries to write files with cat instead of using the write_file tool, it's awful at tool use.

I know it’s a bit of a tangent but man you’re right re. Gemini CLI. It’s woefully bad, barely works. Maybe because I was a “free” user trying it out at the time, but it was such a bad experience it turned me off subscribing to whatever their coding plan is called today.

> Also MCP is very obviously dead...

Couldn't have been more wrong. MCP despite its manageable downsides is leagues ahead of anything else in many ways.

The fact that SoTA models are trained to handle MCP should be hint enough to the observant.

I probably build one MCP tool per week at work.

And every project I work on gets its own MCP tool too. It's invaluable to have specialized per-project tooling instead of a bunch of heterogeneous scripts+glue+prayer.

Anything specialized goes into an MCP.

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

> So bad in fact that it’s clear none of their team use it.

I use it extensively, many of my colleagues do. I get a ton of value out of it. Some prefer Antigravity, but I prefer Gemini CLI. I get fairly long trajectories out of it, and some of my colleagues are getting day-long trajectories out of it. It has improved massively since I started using it when it first came out.

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

MCP is not just used for coding.

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

I personally found playwright-cli, and agent-browser which wraps playwright, both more token-efficient than using the raw mcp.

Odd that this article from Dec 2025 has been posted to the top of HN though

Its easier to connect to existing sessions in your main browser.

It’s made by Google and comes with Chrome

Interesting. Does it only work with known frameworks like Next, React etc. or could I use it with my plain Node.js app which produces browser-output?

I use playwright CLI. Wrote a skill for it, and after a bit of tuning it's about 1-2k context per interaction which is fine. The key was that Claude only needs screenshots initially and then can query the dev tools for logs as needed.

Mostly, yes: https://github.com/microsoft/playwright-cli

my workaround for this was to make a wrapper mcp server which uses claude haiku to summarize the page snapshot returned in the response of each playwright mcp call, and that has worked pretty well for me: https://github.com/jsdf/playwright-slim-mcp

Very cool idea and site! I wish claude and others could parse video streams then you could even create your own feed.

Neat idea :)

It's probably not fully optimized and could be compacted more with just some effort, and further with clever techniques, but browser state/session data will always use up a ton of tokens because it's a ton of data. There's not really a way around that. AI's have a surprising "intuition" about problems that often help them guess at solutions based on insufficient information (and they guess correctly more often than I expect they should). But when their intuition isn't enough and you need to feed them the real logs/data...it's always gonna use a bunch of tokens.

This is one place where human intuition helps a ton today. If you can find the most relevant snippets and give the AI just the right context, it does a much better job.

https://github.com/microsoft/playwright-cli and https://agent-browser.dev/

i'm experimenting with a different approach (no CDP/ARIA trees, just Chrome extension messaging that returns a numbered list of interactive elements). Way lighter on tokens and undetectable but still very experimental : https://github.com/DimitriBouriez/navagent-mcp

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

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.

Take a look at https://news.ycombinator.com/item?id=47207790

Unfortunately there are like a billion competitors to this right now (including Playwright MCP, Playwright CLI, the new baked-in Playwright feature in Codex /experimental, Claude Code for Chrome...) and I can never quite decide if or when I should try to switch. I'm still just using the ordinary Playwright MCP server in both Codex and Claude Code, for the time being.

Similarly, cursor has a built in browser and visit localhost to see the results in the browser. Although I don't use it much (I probably should).

that is the MCP vs CLI debate.

Done, thanks!

This is the exact problem that pushed me to build a security proxy for MCP tool calls. The permission model in most MCP setups is basically binary, either the agent can use the tool or it can't. There's nothing watching what it does with that access once its granted.

The approach I landed on was a deterministic enforcement pipeline that sits between the agent and the MCP server, so every tool call gets checked for things like SSRF (DNS resolve + private IP blocking), credential leakage in outbound params, and path traversal, before the call hits the real server. No LLM in that path, just pattern matching and policy rules, so it adds single-digit ms overhead.

The DevTools case is interesting because the attack surface is the page content itself. A crafted page could inject tool calls via prompt injection. Having the proxy there means even if the agent gets tricked, the exfiltration attempt gets caught at the egress layer.

Someone left their bot on default settings.

AI

The ultimate conflict of interest here is that the sites people want to crawl the most are the ones that want to be crawled by machines the least (e.g. Youtube). So people will end up emulating genuine human users one way or another.

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.

Is this just a well-documented API?

They’re trying to solve it by making it easier to get Markdown versions of websites.

For example, you can get a markdown out of most OpenAI documentation by appending .md like this: https://developers.openai.com/api/docs/libraries.md

Not definitive, but still useful.

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

I feel like the fact tha HTML is end result is exactly why the Web is so successful. Yes, structured APIs sound great, until you realize the API owners will never give you the data you actually want via their APIs. This is why HTML has done so well. Why extensions exist. And why it's better for browser automation.

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

> expose a machine-readable interaction layer alongside the human one

Which is called ARIA and has been a thing forever.