Hacker News Reader

Comment by xnx | Hacker News Reader

I've had good success with the Chrome devtools MCP (https://github.com/ChromeDevTools/chrome-devtools-mcp) for browser automation with Gemini CLI, so I'm guessing this model will work even better.

View on HN

What sorts of automations were you able to get working with the Chrome dev tools MCP?

Not OP, but in my experience, Jest and Playwright are so much faster that it's not worth doing much with the MCP. It's a neat toy, but it's just too slow for an LLM to try to control a browser using MCP calls.

Yeah I think it would be better to just have the model write out playwright scripts than the way it's doing it right now (or at least first navigate manually and then based on that, write a playwright typescript script for future tests).

Cuz right now it's way too slow... perform an action, then read the results, then wait for the next tool call, etc.

This is basically our approach with Herd[0]. We operate agents that develop, test and heal trails[1, 2], which are packaged browser automations that do not require browser use LLMs to run and therefore are much cheaper and reliable. Trail automations are then abstracted as a REST API and MCP[3] which can be used either as simple functions called from your code, or by your own agent, or any combination of such.

You can build your own trails, publish them on our registry, compose them ... You can also run them in a distributed fashion over several Herd clients where we take care of the signaling and communication but you simply call functions. The CLI and npm & python packages [4, 5] might be interesting as well.

Note: The automation stack is entirely home-grown to enable distributed orchestration, and doesn't rely on puppeteer nor playwright but the browser automation API[6] is relatively similar to ease adoption. We also don't use the Chrome Devtools Protocol and therefore have a different tradeoff footprint.

0: https://herd.garden

1: https://herd.garden/trails

2: https://herd.garden/docs/trails-automations

3: https://herd.garden/docs/reference-mcp-server

4: https://www.npmjs.com/package/@monitoro/herd

5: https://pypi.org/project/monitoro-herd/

6: https://herd.garden/docs/reference-page

Whoa that’s cool. I’ll check it out, thanks!

Thanks! Let me know if you give it a shot and I’ll be happy to help you with anything.

You might want to change column title colors as they're not visible (I can see them when highlighting the text) https://herd.garden/docs/alternative-herd-vs-puppeteer/

Oh thanks! It was a bug in handling browser light mode. I just fixed it.

Now I notice that testimonials are victim of the same issue

Looks useful! What would it take to add support for (totally random example :D) Harper's Magazine?

> or at least first navigate manually and then based on that, write a playwright typescript script for future tests

This has always felt like a natural best use for LLMs - let them "figure something out" then write/configure a tool to do the same thing. Throwing the full might of an LLM every time you're trying to do something that could be scriptable is a massive waste of compute, not to mention the inconsistent LLM output.

Exactly this. I’ve spent some time last week at a 50 something people web agency helping them setup QA process where agents explore the paths and based on those passes write automated scripts that humans verify and put into testing flow.

That's nice. Do you have some tips/tricks based on your experience that you can share?

You can use it for debugging with the llm though.

In theory or in practice?

I've used it a few times with vscode.

Although I find the electron mcp is better for what I'm doing at the moment.

Actually the super power of having the LLM in the bowser may be that it vastly simplifies using LLMs to write Playwright scripts.

Case in point, last week I wrote a scraper for Rate Your Music, but found it frustrating. I'm not experienced with Playwright, so I used vscode with Claude to iterate in the project. Constantly diving into devtools, copying outter html, inspecting specific elements etc is a chore that this could get around, making for faster development of complex tests

Not tested much but Playright can read browser_network_requests' response, which is a much faster way to extract information than waiting for all the requests to finish, then parse the html, when what you're looking for is already nicely returned in an api call. Puppeteer MCP server doesn't have an equivalence.

I've used it to read authenticated pages with Chromium. It can be run as a headless browser and convert the HTML to markdown, but I generally open Chromium, authenticate to the system, then allow the CLI agent to interact with the page.

https://github.com/grantcarthew/scripts/blob/main/get-webpag...

Computer use model comes from interactive demand with computer automatically, Chrome devtools MCP might be one of the core pushers.

This has absolutely nothing in common with a model for computer use... This uses pre-defined tools provided in the MCP server by Google, nothing to do with a general model supposed to work for any software.

The general model is what runs in an agentic loop, deciding which of the MCP commands to use at each point to control the browser. From my experimentation, you can mix and match between the model and the tools available, even when the model was tuned to use a specific set of tools.

Reply on news.ycombinator.com