Half joking, sure, but the "click around the app" problem is already real for teams running browser automation at scale. The issue isn't the clicks themselves - it's that every Chrome instance looks identical to a bot detector the moment you spin up ten of them from the same machine. The fingerprint (canvas, WebGL, navigator properties, etc.) is basically screaming "I'm automated". Dealing with this from the ops side: the headache isn't writing the automation, it's keeping each browser session isolated enough that sites don't treat them as the same entity. MCP or CLI doesn't really change that underlying problem.

Because the Tools model allows for finer grained security controls than just bash and pipe. Do you really want Claude doing `find | exec` instead of calling an API that’s designed to prevent damage?

Making those tools first-class primitives is good for (human) UX: you see the diffs inline, you can add custom rules and hooks that trigger on certain files being edited, etc.

Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.