Cool to see lots of people independently come to "CLIs are all you need". I'm still not sure if it's a short-term bandaid because agents are so good at terminal use or if it's part of a longer term trend but it's definitely felt much more seamless to me then MCPs.<p>(my one of many contribution <a href="https://github.com/caesarnine/binsmith" rel="nofollow">https://github.com/caesarnine/binsmith</a>)
I am also not sure if MCP will eventually be fixed to allow more control over context, or if the CLI approach really is the future for Agentic AI.<p>Nevertheless, I prefer the CLI for other reasons: it is built for humans and is much easier to debug.
Have a look at code mode mcp. <a href="https://github.com/universal-tool-calling-protocol/code-mode" rel="nofollow">https://github.com/universal-tool-calling-protocol/code-mode</a>
100% - sharing CLIs with the agent has felt like another channel to interact with them once I’ve done it enough, like a task manager the agent and I can both use using the same interface
Thank you for posting binsmith, I've built something similar over the past few days and you've made some great decisions in here
MCP let's you hide secrets from the LLM
Hey this looks cool. So each agent or session is one thread. Nice. I like it.
At this point I'm fully down the path of the agent just maintaining his own tools. I have a browser skill that continues to evolve as I use it. Beats every alternative I have tried so far.
Same. Claude Opus 4.5 one-shots the basics of chrome debug protocol, and then you can go from there.<p>Plus, now it is personal software... just keep asking it to improve the skill based on you usage. Bake in domain knowledge or business logic or whatever you want.<p>I'm using this for e2e testing and debugging Obsidian plugins and it is starting to understand Obsidian inside and out.
Do you experience any context pollution with that approach?
Writing your own skill is actually a lot better for context efficiency.<p>Your skill will be tuned to your use case over time, so if there's something that you do a lot you can hide most of the back-and-forth behind the python script / cli tool.<p>You can even improve the skill by saying "I want to be more token efficient, please review our chat logs for usage of our skill and factor out common operations into new functions".<p>If anything context waste/rot comes from documentation of features that other people need but you don't. The skill should be a sharp knife, not a multi-tool.
Not really. less bad than the mcps i used.
whats the name of the skill?
Creator of Browser Use here, this is cool, really innovative approach with ARIA roles. One idea we have been playing around with a lot is just giving the LLM raw html and a really good way to traverse it - no heuristics, just BS4. Seems to work well, but much more expensive than the current prod ready [index]<div ... notation
Thanks!<p>I actually tried a raw HTML when I was exploring solutions. It worked for "one-off" tasks, but I ran into major issues with replayability on modern SPAs.<p>In React apps, the raw DOM structure and auto-generated IDs shift so frequently that a script generated from "Raw HTML" often breaks 10 minutes later. I found ARIA/semantics to be the only stable contract that persists across re-renders.<p>You mentioned the raw HTML approach is "expensive". Did you feed the full HTML into the context, or did you create a BS4 "tool" for the LLM to query the raw HTML dynamically?
I really like this idea!<p>I’d like to see this other browser plugin’s API be exposed via your same CLI, so I don’t have to only control a separate browser instance.
<a href="https://github.com/remorses/playwriter" rel="nofollow">https://github.com/remorses/playwriter</a>
(I haven’t investigated enough to know how feasible it is, but as I was reading about your tool, I immediately wanted to control existing tabs from my main browser, rather than “just” a debug-driven separate browser instance.)
Thanks! To clarify: webctl allows you to manually interact with the browser window at any time. It even returns "manual interaction" breakpoints to stdout if it detects an SSO/login wall.<p>But I agree, attaching to the OS "daily driver" instance specifically would be a nice addition.
If you look at Elixir keynote for Phoenix.new -- a cool agentic coding tool -- you'll see some hints about a browser control using a API tool call. It's called "web" in the video.<p>Video: <a href="https://youtu.be/ojL_VHc4gLk?t=2132" rel="nofollow">https://youtu.be/ojL_VHc4gLk?t=2132</a><p>More discussion: <a href="https://simonwillison.net/2025/Jun/23/phoenix-new/" rel="nofollow">https://simonwillison.net/2025/Jun/23/phoenix-new/</a>
A little bit different, but also allows to scrape efficiently. Json http communication rather than cli.<p><a href="https://github.com/rumca-js/crawler-buddy" rel="nofollow">https://github.com/rumca-js/crawler-buddy</a><p>More like a framework for other mechanisms
This looks remarkably similar to <a href="https://github.com/vercel-labs/agent-browser" rel="nofollow">https://github.com/vercel-labs/agent-browser</a><p>How is it different?
To be honest, I hadn't seen that one yet!<p>The main difference is likely the targeting philosophy. webctl relies heavily on ARIA roles/semantics (e.g. role=button name="Save") rather than injected IDs or CSS selectors. I find this makes the automation much more robust to UI changes.<p>Also, I went with Python for V1 simply for iteration speed and ecosystem integration. I'd love to rewrite in Rust eventually, but Python was the most efficient way to get a stable tool working for my specific use case.
vibium clicker, too. <a href="https://github.com/VibiumDev/vibium/blob/main/CONTRIBUTING.md#using-clicker" rel="nofollow">https://github.com/VibiumDev/vibium/blob/main/CONTRIBUTING.m...</a><p>"browser automation for ai agents" is a popular idea these days.
How are you holding session if every command is issues through cli? I assume this is essential for automation.
is there a benchmark? there are a lot of scraping agents nowdays..
I don't have an objective benchmark yet. I tried several existing solutions, especially the MCP servers for browser automation, and none of them were able to reproducibly solve my specific task.<p>An objective benchmark is a great idea, especially to compare webctl against other similar CLI-based tools. I'll definitely look into how to set that up.
[dead]
I actually think the CLI approach helps with those boundaries.
Because webctl commands are discrete and pipeable (e.g. webctl snapshot | llm | webctl click), the "authority" is reset at every step of the pipeline. It feels easier to audit a text stream of commands than a socket connection that might be accumulating invisible context.
[dead]