Where it sits in a waterfall
The leg your B2B providers keep returning empty.
A normal enrichment waterfall runs a contact database, then a second provider, then a pattern guess, then a verification step. That works on companies with employee records. It falls apart on a plumber, a dental practice or an independent gym, where there is no employee record to find and the business's own website is the only place the address exists.
LeadFindr is built for that leg. It starts at the Google Maps listing for a niche and a city, opens each business's own site while the search runs, and returns what is published there, plus the decision maker behind the business with a LinkedIn profile and a verified work email where one is found. Then it charges you only for the rows that came back contactable.
Plain language instead of a filter schema
Fewer tool arguments for the model to get wrong.
Most data tools expose a filter object, and an agent spends its turns guessing the enum for industry, the shape of a location and which boolean means verified. LeadFindr is built the other way round: an agent says what it wants the way a person would say it, gets a free count back, and decides whether that search is worth running.
The MCP that exposes this is in early access. Nothing is installable yet, there is no endpoint published, and no tool list here should be treated as live. The app does the same searches today if you need the data before the tooling lands.
Cost control inside a loop
The failure mode of agent driven data is spend, not quality.
- Free count preview: the agent can size a search before it costs anything.
- Per search cap: the maximum number of leads is set before the search runs, so a bad loop stops at a ceiling.
- No charge for empty rows: a business with no email, phone or social profile is free.
- No seats: you are not buying a licence for a bot, or for each engineer who wires one up.
- Failed people lookups are never charged, including during a provider outage.
At 0.25 credits a lead, about $0.025, a 500 lead run is roughly $12.50 if every single row comes back contactable. That is a number you can put in a loop without a finance conversation.
What it is not, for your architecture diagram
Four honest gaps, so you can plan around them.
- No public REST API today. MCP is the route being built, and it is early access.
- No stored database to query. Every search is live, so a run takes longer than a lookup and the pattern is start, poll, fetch.
- No sending. LeadFindr finds and verifies; sequencing happens in your stack, or in DM Champ if you import the leads as contacts.
- No firmographic or technographic filters. The unit here is a niche and a place, or a role and a place.
What you get today while MCP is in early access
The app, a CSV and a spend you can predict.
Run the search in the app, export CSV, and feed it into whatever you are building. Searches are saved with their results, leads can be starred into lists, every email can be copied in one block, and leads can be imported into DM Champ as contacts. New accounts start with 100 credits, which is 400 leads, so the evaluation costs nothing.
Questions People Actually Ask.
Can I call LeadFindr from Claude Code today?
Not yet. The MCP and the Claude Code skill are in early access, with no install command or endpoint published. DM Champ already runs a hosted MCP server for its own API and LeadFindr joins it when it ships.
Is there an API I can build against now?
No. There is no public REST API. If your pipeline needs one today, use the app and its CSV export, or pick a different tool for now.
How does this fit next to a B2B database?
It does not replace one. Keep the database for companies with employee records and use LeadFindr for the local leg, where those providers return blanks and where you only pay for rows that came back contactable.
How do I stop an agent burning credits?
The count preview is free, every search carries a cap set before it runs, and leads without contact details are never charged.