"Find 40 dental clinics in Munich, get their emails, and tell me which ones take bookings online." That is the whole instruction. What follows is what Claude actually does with it, and where the arrangement is genuinely different from a hosted scraping API.
The run
you
Find 40 dental clinics in Munich, get their emails,
and tell me which ones take bookings online.
claude
manycrawl_engine_status desktop: true, signed in, pro
manycrawl_create_source maps · "dentist Munich" · maxRows 40
→ tableId session_1788…
manycrawl_table_status filling: true · 12 rows
manycrawl_table_status filling: false · 40 rows
manycrawl_add_column scrape → "Emails"
manycrawl_add_column ai → "Online booking"
manycrawl_get_table coverage: Emails 31/40, Online booking 40/40
Seven calls. The interesting one is the third, and the fact that it appears twice.
Everything is async, and the tools say so
create_source returns a table id immediately and rows stream in afterwards. Google Maps in particular streams a name and a website first, then goes back over the rows in a slower second pass to fill in address and phone.
So a table read at the wrong moment looks half-empty, and an agent that reports on it will tell you something false with complete confidence: "only 7 of 40 have a phone number." That is not a scraping failure, it is a mid-fill read.
The fix is a contract rather than a prompt. table_status carries a filling flag, and the tool descriptions say plainly: while filling is true, do not report what is missing. The agent polls until it is false. Making the tool honest about its own state is more reliable than asking a model to be careful.
get_table returns a coverage object counting each field across the whole table, not just the page you read. Without it, an agent counts the rows in front of it and gets a confidently wrong percentage on anything paginated. The tool hands over the right number so nobody has to derive it.
Why local matters here specifically
The scraping happens on the machine running the app. Not as a privacy slogan — though it is that too — but because of what it makes possible.
Your logged-in sessions come with it. If you have signed into Apollo in the app's built-in browser, your agent can scrape an Apollo search, because it is your browser and your session doing it. No hosted service can offer that without asking you to hand over credentials.
And there is nothing to meter. There is no worker pool between you and the page, so there is no per-request bill and no queue behind other customers. The ceiling is your machine and the source's own limits, which are the honest limits anyway.
The half nobody expects
The tools run in both directions.
Sixteen of them are control: the agent as operator, building tables and reading them back. That is the run above.
Seven are drain, and they invert it. An AI column in the app queues a job; the agent claims it with next_job, does the reasoning — several steps, web access, cross-referencing — and posts the answer back with submit_result. Where a plain API call is one prompt and one response, this is a real agent filling in one cell.
The practical effect is that your Claude subscription does the thinking instead of a metered API key. It is the same 23 tools, pointed the other way.
What it will not do
It does not work once you quit the app. Closing the window is fine, since it hides to the tray and keeps serving, but quitting takes the local bridge with it.
It is not reachable from a cloud agent. The server talks to 127.0.0.1, which is the same property that means nothing is metered.
And it does not get past a source's own limits. Apollo still serves roughly 1–2k results per search. LinkedIn is still paced. The agent gets exactly the ceilings you get.
Try it
Setup is one button in the app's settings, which writes the Claude config for you: no terminal step and nothing to install. The full tool reference lists what each of the 23 returns.
Build a list while this is fresh
Free plan includes 500 actions a month, unlimited tables and rows. No card.