No API, no MCP server. Claude just used the browser.

Every conversation about AI agents runs into the same question sooner or later: the agent is capable enough to do the work, but how does it reach your tools? The standard answers are an API or an MCP server, and if a tool has neither, the conversation tends to stall right there. But almost every tool already ships with an interface an agent can operate. It's the browser, the same one you use.

Claude Code can drive Chrome directly. It reads the page, finds the right button, types, waits for things to load, and checks in with a human when it hits a login screen or a judgment call. That quietly changes the answer to "which tools can my agent use?" from "the ones with integrations" to "any tool you can log into."

One prompt, start to finish

To see how far that goes, Curtis put it to a real test: create the databases on one side, a sync on the other, and give the agent nothing beyond a sentence of intent. This was the entire prompt:

I'm logged into Whalesync and Supabase. Using the browser, can you please create two new Supabase databases with a bunch of field types and sample data, about 100 records? And then can you create a sync in Whalesync between those two Supabase databases?

No connection strings, no schema definitions, no credentials. Claude (running in Claude Code, since Claude Cowork can't drive a browser) created two new Supabase projects, set up a fresh free organization when Curtis's existing orgs turned out to be near their project caps, built schemas with a spread of field types, inserted about 100 rows of sample data, then connected Whalesync to Supabase and created the sync. Curtis's role was signing in, answering a few questions, and drinking coffee.

One detail worth pausing on: Curtis had generated a database password ahead of time, ready for the moment Claude asked for it. Claude never asked. Whalesync connects to Supabase through OAuth, so the one piece of preparation the run seemed to need turned out to be unnecessary.

What a browser run is good for

Honesty first: watching an agent drive a browser is slow. It reads, clicks, waits, confirms. Curtis had time to make coffee and get distracted before the sync was done, and an API call does equivalent work in seconds. So the browser is the wrong tool for anything high-volume or repeated.

Where it shines is everything else. Setup tasks you do once, where writing an integration would never pay back. Tools that have no API for the thing you need. Workflows that cross products which were never designed to talk to each other. In those cases the browser has an advantage nothing else can match: it exists today, for every tool, without waiting for a vendor to ship anything. The interface built for humans turns out to be a perfectly serviceable interface for agents too.

It also comes with supervision built in, which is the right default for an agent working inside your accounts. Claude stopped at sign-in screens and waited while Curtis logged in. It asked before taking control of the browser, and it asked again at the real decisions: two tables in one project or two separate projects, delete the old projects or create a new org.

Where this leaves APIs and MCP

They become the fast lane. When a tool has a good API or an MCP server, use it; the same job finishes in a fraction of the time. What changed is that their absence stopped being a blocker. If a tool has a login page, your agent can use it now.

If the thing you want in sync is your own stack, Whalesync sets up in minutes, or you can do what Curtis did and simply ask Claude. And if an agent editing your data makes you want a review step first (a healthy instinct), that's what Scratch is for. It pulls your data down locally, lets an agent work on it, and shows you every change before anything publishes back.

Oh, by the way, we've launched a Whalesync API and an MCP server. The point of this post stands; the browser needed neither. But the next agent that builds a sync will be done before the coffee is.