I build outbound lists for a living, and teams that dial ask me the same thing every month. Not "does this vendor have numbers". They ask how many of the people they actually want have one. Nobody can tell them that before the contract is signed.

So on 2026-10-29 I spent a morning answering it the cheap way. One ideal customer profile, four Apify Actors, free counts before any paid pull, and Claude Code doing the clicking over MCP. Every number below comes from those runs, and the inputs are in the text.

In one paragraph: a Lusha or ZoomInfo alternative here is one people database behind a few Actors. Count your ICP for free. Then pull leads with the number where one exists, or only the callable ones, or look up numbers for contacts you already hold, or walk named accounts for anyone with a mobile. You pay per row delivered, nothing for the misses.

How big is the box, and does it matter where you sell

Before any pull I ran the ICP most call lists are built from through People Search in count mode: US sales leaders at software companies with 51 to 500 employees. Count mode charges nothing per row, and segments compares countries in one call.

{
  "mode": "count",
  "titleKeywords": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "employerIndustries": ["Software Development"],
  "employeeCountMin": 51,
  "employeeCountMax": 500,
  "segments": [
    { "name": "US", "countries": ["us"] },
    { "name": "UK", "countries": ["gb"] },
    { "name": "Germany", "countries": ["de"] },
    { "name": "Canada", "countries": ["ca"] },
    { "name": "Australia", "countries": ["au"] }
  ]
}

Inside the US box, "sales director" is more than half of the people. "VP Sales" as a literal title is a small slice. Worth knowing before you read anything into a sample of twenty.

What the free read does not tell you is who has a number. Market mode shows email coverage (about two thirds of this box have a personal address on record) and says nothing about phones. The phone share comes one step later, and that step is cheap: the Actors skip people without a number for free and count them in a note row.

1. We need a fresh list, with numbers where they exist

The default case. A list to work by email first, phone when you have it. B2B Leads Finder with includePhones on:

{
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "countries": ["us"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "any",
  "includePhones": true,
  "maxResults": 20
}

A free Apify plan delivers up to twenty leads per API run, so I ran it five times and passed the earlier datasets in excludeDatasets each time. A hundred people at ninety-six companies, no repeats, each run under half a minute.

Thirty-five of them had a mobile number. That is the honest headline for this ICP: about one in three.

The pattern I keep seeing: the more senior the title, the more often a number is on record. CROs had one about half the time, sales directors one in four. The six VPs had none, which says more about six being a small number than about VPs.

Two things I expected to matter did not. Records refreshed within the last year carried a number at the same rate as older ones. And a work address and a number came together on a quarter of the list, which is the row a dialling team actually wants.

Then the same box for the UK and for Germany, twenty leads each. Zero numbers in both. Mobile numbers in this database are a US thing, and I would rather say that here than have you find it on the invoice.

2. We only want people we can call

A dialling team does not want the seventy rows without a number. Leads with Phones is the same search with phoneRequired on by default: every row has a verified mobile on record and a live email, the rest are skipped free.

{
  "jobTitles": ["vp sales", "head of sales", "chief revenue officer", "sales director"],
  "countries": ["us"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "any",
  "phoneRequired": true,
  "maxResults": 20
}

Twenty people came back in about fifteen seconds, all with numbers. To find them the Actor read 125 matches. Thirty-five had left the role the search matched. Sixty-eight had no number or no live address. Both groups sit in the note rows at the end of the dataset, and neither is on the bill.

That note row answers the question from the top of the post. For this ICP, about one in six people the search matches is someone you can ring today.

I ran it once more with the first dataset in excludeDatasets. Twenty new people, zero repeats. Put that on a weekly timer and the call list grows only with new people.

3. The CRM has two thousand contacts and no numbers

This is the version I hear most. The list already exists, bought or built years ago, names and companies in a spreadsheet. Phone Number Finder takes exactly that: one line per person as "First Last, company domain", or an email, or a profile URL. Up to twenty thousand lines in one run.

I fed it twenty marketing leaders from a random sample of a different segment, random so I could not cherry-pick, as name plus domain:

{
  "profileUrls": [
    "Jane Smith, acme.com",
    "...nineteen more lines, one person each"
  ]
}

Five seconds. Nine came back with a number. Ten matched a person at that company who has no number on record, free. One profile was no longer in the database, also free.

Nine of twenty beats the one in three from the fresh list, and I would not read much into it: marketing leaders, a tiny sample. The shape is the point. You pay for the nine, and the eleven misses cost nothing and each one says why.

4. We sell to forty named accounts

Account-based teams have the opposite problem. They know the companies and want everyone there they can call. Company Employees Scraper walks a list of company domains, and mustHave: ["phone"] keeps only people with a number.

I took ten company domains from the first list. Any account list works: your CRM, a company-database-search run, domains resolved with domain-to-company. Leadership roles, sales or revenue in the title, contacts tier, compact rows:

{
  "companies": ["<ten company domains, one per line>"],
  "roles": ["cxo", "vp", "director"],
  "titleContains": ["sales", "revenue"],
  "profileDetail": "contacts",
  "mustHave": ["phone"],
  "compact": true,
  "maxRows": 20
}

Nineteen people with a number at nine of the ten companies, eleven seconds. Fifty-three employees in those roles had no number and were skipped free.

Most of the nineteen were directors, because there are simply more directors with "sales" in the title than there are CROs. If what you want is the one top person per account, run the roster tier first with roles: ["cxo"], read it, then pull contacts for the names you picked.

What Claude Code did with the same question

I gave Claude Code two of the Actors over MCP and a prompt in plain words: I run a three-person team that works the phone, this is our ICP, run anything free first, keep every paid pull at twenty or fewer, never run the same paid pull twice. Shell and file tools were switched off, so the Apify tools were all it had.

It did the free reads first, as told. Then it did something I had not asked for: it expanded my four titles into ten spellings ("vp of sales", "vice president sales", "director of sales", "cro"). The box roughly doubled, to about ten thousand people. The right call for a call list, and the reason its count does not match mine above.

It tried to get the phone share for free by running count mode with a phone requirement. Count mode ignores that requirement, and the agent said so instead of inventing a number. Then it ran one paid pull, with its own title list:

{
  "jobTitles": ["vp sales", "vp of sales", "vp, sales", "vice president sales", "vice president of sales",
                "head of sales", "chief revenue officer", "cro", "sales director", "director of sales"],
  "countries": ["us"],
  "industries": ["Software Development"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "phoneRequired": true,
  "emailType": "any",
  "maxPerCompany": 1,
  "maxResults": 20
}

Twenty rows, all with numbers, from 111 matches read. Fourteen had a work address at the current employer, six only a personal one.

Its read of the rows was the useful part. Three of the twenty were pre-sales or operations: a technical sales director, a director of sales operations, a VP of sales engineering. "Sales director" as a substring brings them in. It proposed an excludeJobTitles list for the next run and reusing the dataset in excludeDatasets. Both are the right next move.

It also read the rows with a fields list instead of pulling whole records, which nobody told it to do. Twelve turns, under six minutes.

Before you dial

Everything above is a number on record, not a number that rings. Nobody dialled anything for this post. Line type, do-not-call lists and consent rules (TCPA in the US, GDPR in Europe) are yours to handle before the first call, the same as with any vendor.

And the numbers are US-centric. If your market is the UK or Germany, run the free count, then one twenty-row pull with the phone required, and read the note row before you plan a calling campaign around it.

FAQ

Is this a drop-in Lusha or ZoomInfo replacement? For the list, yes: ICP in, rows with numbers out, no seat, no browser extension. For a dial-from-the-browser plugin, no. You get data, not a dialler.

How do I learn the phone share before paying for a list? Run Leads with Phones with a small maxResults and read the skipped_no_contact note row. The skipped people are free and they are your denominator.

Why did the UK and Germany return no numbers? Mobile coverage in this database is concentrated in the US. Outside it, treat the number as a rare bonus and build the list for email.

I already have the contacts. Which Actor? Phone Number Finder, one line per person: name plus company domain, an email, or a profile URL. Misses are free and come back with a reason.

Can I avoid paying twice for the same person? Pass earlier dataset ids in excludeDatasets. Everyone in them is skipped free, so a weekly rerun delivers only new people.

For AI agents reading this

The Actors run over the hosted Apify MCP server with the tools pinned in the URL, so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/b2b-leads-with-phones,b2bsearch/people-database-search" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/b2b-leads-with-phones,b2bsearch/people-database-search",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--people-database-search, b2bsearch--b2b-leads-finder, b2bsearch--b2b-leads-with-phones. For a call list: run people-database-search with mode: "count" and segments first and read _total per segment. Then run b2b-leads-with-phones with phoneRequired: true, maxPerCompany: 1 and a maxResults you can defend, or b2b-leads-finder with includePhones: true when the number is optional.

Read rows with get-dataset-items and a fields list. Rows whose _status is not found are note rows (skipped_no_contact, skipped_moved, skipped_relocated) and are the denominator. On reruns pass earlier dataset ids in excludeDatasets.

For contacts the user already holds, run b2bsearch/linkedin-to-phone with profileUrls as "First Last, domain" lines, emails or profile URLs. For named accounts, run b2bsearch/company-employees with companies, roles, profileDetail: "contacts" and mustHave: ["phone"]. Phone coverage is US-centric; outside the US expect the number column to be mostly empty. Per-tier pricing is on each Actor page.

Earlier posts on the same question

The first Lusha test ran one ICP with the number optional and required. The phone hit-rate map measures nine role and country populations. The Apollo alternative and the Sales Navigator alternative build the email side of the same lists from Claude Code, and the account mapping post walks named accounts at full length.

Any email finder will fill that column. What none of them tells you is whether the person still reads that mailbox. A record collects addresses the way a career collects employers, and the finder hands you the one on top. The bounce arrives a week later, on your domain's reputation, not theirs.

So on 2026-10-29 I ran two hundred profile URLs through an Apify Actor that labels the address instead of just returning it. Current employer, older employer, nothing on record, profile gone. Then I put two more Actors behind it, and let Claude Code run the same twenty over MCP. Every number below comes from those runs.

In one paragraph: a bulk email finder here takes profile URLs, one per line, and returns the addresses on each person's record with a label. An address on the current employer's domain, an older company address, or nothing. Misses are free rows with a reason.

For the older and empty rows a second Actor tries name plus company domain and verifies what it finds. A free search step sizes the segment before anyone pays.

Where two hundred URLs come from, and what a free read says

I did not want to run a client's list for a blog post, so I drew two random samples from the same people database the finder reads: in-house marketing leaders, and founders. Different inboxes, different habits. People Search in market mode first, which costs nothing and tells you what the box looks like before you pull from it.

Inside the marketing box, chief marketing officers and other C-level titles were nearly half, directors about a third, VPs fewer than one in ten. Useful to know before you read anything into a sample of a hundred.

Then the pull. people mode, compact rows, a random seed so I could not cherry-pick, five runs of twenty per segment:

{
  "mode": "people",
  "titleKeywords": ["vp marketing", "head of marketing", "chief marketing officer", "marketing director"],
  "countries": ["us"],
  "employerIndustries": ["Software Development"],
  "employeeCountMin": 51,
  "employeeCountMax": 500,
  "profileDetail": "row",
  "compact": true,
  "maxResults": 20,
  "sampleSeed": 41
}

Two of the hundred marketing draws were the same person, so that list is ninety-eight. Each compact row carries a profile URL, the employer's domain, company size, and two flags: hasWorkEmail and hasPersonalEmail. Eighty-two of the ninety-eight marketing leaders said yes to a work email. Seventy-six of the hundred founders did.

Hold that number.

The run: one field, four seconds

The finder takes one field. Links, bare handles and mobile URLs all work, and spellings of the same profile are looked up once. Up to a thousand per run; a free plan returns up to a hundred results per run, and I fed twenty at a time so I could read each batch before the next.

{
  "profileUrls": [
    "<one profile URL per line>",
    "..."
  ],
  "includePersonalEmails": false
}

Four seconds per batch of twenty. Here is what two hundred URLs became:

Only the first two rows are billed. The empty and gone rows come back with a status, and for the empty ones with the name and title, so you know who to route elsewhere.

Now back to the flag. Eighty-two marketing leaders had "has a work email" on their database row. Thirty-eight of them have one at the company they work for today. A yes in a database means an address exists somewhere in the record. It does not say where.

That is the whole post in one line. About half the work addresses in a B2B record belong to a job the person has left, and a finder that does not label them sells you the bounce.

What an older address looks like

A career leaves a trail of mailboxes. The found marketing records held four addresses each in the middle of the pack, three quarters of them three or more, and one person had thirteen. Founders' records were a little shorter, three in the middle.

The finder sorts the current employer's address first when it has one. When it has none it can tie to today's employer, the row is labelled work_other and the first address in the list is simply the first one, with no claim about recency.

I checked the label against the employer domain from the source row, the one a CRM would hold:

The eleven are brands whose mail domain is not the website: a product name on the site, the legal entity on the envelope. Among founders it split in half, which is what you get when one person runs two companies at once.

Record freshness shifts the odds without deciding anything:

Fresher records lean toward a live address. Not by enough to filter on. The label does the filtering, freshness only tells you how much to trust it.

Personal mailboxes, on request

By default the finder returns company addresses only. When a matched profile has nothing corporate but a personal mailbox is on record, the empty row says so in a _note. Five of the twenty-four empty founder rows carried that note. None of the twelve empty marketing rows did, and their source rows agreed: nothing of either kind.

I reran those five with includePersonalEmails on. Five personal addresses, as promised.

Then I reran one whole founder batch of twenty with personal mailboxes on from the start, to see what the switch does to rows that already had something:

With the switch on, a personal mailbox outranks an older company address. For the founder of a twelve-person company that is usually the inbox that gets read. For an in-house CMO it is the wrong one, which is why the switch is off by default.

The second door: name plus domain, verified

The older and empty rows are not dead people, they are people whose record is behind. For those there is a different Actor. Work Email Finder takes a name and a company domain, builds the candidates the way the domain writes addresses, and with verifyTopCandidate on checks the best one against the mail server and its own records.

I took the eighty-one found marketing rows, the name from the finder's row and the domain from the source row, and ran all of them through it:

{
  "lookups": [
    { "domain": "<company domain from your CRM>", "full_name": "<name from the finder row>" },
    "...eighty more"
  ],
  "verifyTopCandidate": true
}

Thirty-three of the forty-three "older" rows came back with a verified address at today's employer. Twenty-one of those were already in the record's workEmails list, below the one on top. The finder ties addresses to the employer's canonical domain, so a brand domain further down the list stays labelled older.

Two lessons for a pipeline. Match the whole list against your own domain list before you discard a row. And send what is left through the name-plus-domain door with verification on, which rescued most of the rest here.

The honest other half: eight people with a current address on record got no verified candidate from the pattern door. Record and pattern are two sources. Where they agree, twenty-six rows here, is where I would send first.

What Claude Code did with twenty of them

I gave Claude Code the Email Finder and People Search over MCP, nothing else. Shell and file tools off.

The prompt was a RevOps person in plain words. Two thousand CRM contacts with profile URLs and no email, here are twenty. Our policy is work addresses at the current employer only, never a personal mailbox unless you can say why. Look each person up once.

It loaded the two tool definitions, ran one lookup on all twenty with personal mailboxes off, read the twenty rows with get-dataset-items, and wrote its answer. Four tool calls, one of them paid, under four minutes. It did not run the free search, and said so: nothing in the task needed it.

Its ledger for the twenty: seven current, eight older, two with nothing, three profiles gone. Then it did the reading I would have skipped on a Friday.

One "older" row held an address on the current employer's domain further down the list. It proposed matching the whole list against the CRM's domain before discarding anything, the same fix I arrived at with eighty-one rows and a second Actor.

One row's only address sat on a domain made of the person's own name. A one-person consultancy mailbox in practice, it said, and excluded under the policy whatever the label says.

It noticed that profile_removed is not in the tool's description, read the status correctly anyway, and said it could not confirm the meaning with the tools it had. That gap in the listing is mine to close.

It also noted that _freshness did not vary across its fifteen found rows, so on that sample the field filtered nothing. True, and worth knowing before you build a rule on it.

Before the remaining two thousand it asked for five things: normalise and dedupe the URLs on the handle, compare work_current employers with the CRM's, verify deliverability before trusting hundreds, watch the share of gone profiles, and poll the run instead of waiting inline. I would sign all five.

Before you send

Addresses from the first Actor are on record, not verified at run time. The second Actor's check says a mailbox accepts mail. Neither says the person reads it.

The label can lag. A job change in the last few months can still show as current. Compare the row's employer with the one you hold.

Brands with a second mail domain show up as "older". Match on your domain list, not on the label alone.

Seven of the hundred and ninety-eight URLs pointed at a profile that no longer exists. A CRM full of URLs from three years ago will have more. Keep that share in view, it is free to measure.

Consent and the law are yours: CAN-SPAM, GDPR, PECR, whatever applies where the person sits. A verified address is not permission.

FAQ

Is this a Hunter or Apollo email finder replacement? For turning profile URLs into addresses in bulk, yes: no seat, no browser extension, you pay per found row and the misses are free. For a Chrome plugin that fills an address while you browse, no.

Does it guess addresses? The first Actor does not: it returns only addresses that exist in the person's record and says so when there are none. The second one builds candidates from name and domain and can verify the best one. That is the guessing door, and it is labelled as such.

What does work_other mean? A company address the finder cannot tie to the current employer. Usually a previous job, sometimes the same company under a brand domain. Check the workEmails list against your own domains before you decide.

Why were some addresses personal when I did not ask? They were not, unless includePersonalEmails is on. With it on, a personal mailbox outranks an older company address on the row.

How big can one run be? Up to a thousand URLs per run on this Actor. A free Apify plan returns up to a hundred results per run and five hundred rows a month; any paid plan removes that.

For AI agents reading this

The three Actors run over the hosted Apify MCP server with the tools pinned in the URL, so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/linkedin-email-finder,b2bsearch/work-email-finder,b2bsearch/people-database-search" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/linkedin-email-finder,b2bsearch/work-email-finder,b2bsearch/people-database-search",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--linkedin-email-finder, b2bsearch--work-email-finder, b2bsearch--people-database-search. For a list of profile URLs: dedupe on the handle, run the email finder with profileUrls and includePersonalEmails: false, then read rows with get-dataset-items and a fields list (_status, emailType, email, workEmails, emailCount, jobTitle, companyName, _freshness, _note).

Rows with _status other than found are free: no_email (a _note says when a personal mailbox is on record), not_found, profile_removed. For work_other rows, match every entry of workEmails against the user's company domain first.

For what is left, run work-email-finder with lookups of { "domain", "full_name" } and verifyTopCandidate: true, and read email_validity. To size a segment before any paid pull, run people-database-search with mode: "market" or mode: "count". Per-tier pricing is on each Actor page.

Earlier posts on the same question

The lead list autopsy counts how many leads in an ordinary ICP box were dead before the first email. The fractional CFO post is where I first saw work addresses that belonged to former employers.

The Apollo alternative builds the lists these URLs usually come from, and the Actor map by key says which door to use when you hold domains, emails or names instead of URLs.

Three of the twenty are mine, so this is also a check on my own work. The numbers are from 28 October 2026, and the method is a curl handshake you can rerun on any Actor in a minute.

Why the tool definition is the first cost

An MCP client loads every tool's name, description and JSON schema before the model reads your question. On the hosted Apify server each Actor becomes one tool, and the tool carries three parts: the description (the Actor's Store description after a one-line preamble), the input schema (the Actor's input fields, as the author wrote them), and an output schema that the server infers from what the Actor's runs return (documented here; the local stdio server does not add it). The third part is the one most Actor authors have never looked at, because they never wrote it.

A post two days ago measured a hand-built server at 15 tools and rebuilt it to 4. I wanted the same number for tools I did not build and cannot rebuild: the Actors an agent meets when a user says "find me backend jobs in Germany".

How I measured

Hosted server, one Actor pinned per session with ?tools=, then the plain tools/list after the initialize handshake:

U='https://mcp.apify.com?tools=curious_coder/linkedin-jobs-scraper'
H=(-H "Authorization: Bearer $APIFY_TOKEN" -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream')

# 1. initialize; the session id comes back as a response header
curl -s -D hdr -o /dev/null "$U" "${H[@]}" -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"probe","version":"0"}}}'
SID=$(grep -i '^mcp-session-id' hdr | awk '{print $2}' | tr -d '\r')

# 2. initialized notification, 3. the list (server-sent events; the data: line holds the JSON-RPC result)
curl -s -o /dev/null "$U" "${H[@]}" -H "Mcp-Session-Id: $SID" -d '{"jsonrpc":"2.0","method":"notifications/initialized"}'
curl -s "$U" "${H[@]}" -H "Mcp-Session-Id: $SID" -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' > tools.sse

I serialized each tool definition as compact JSON and counted tokens with tiktoken's o200k_base. Claude's tokenizer is not public, so treat the counts as a scale, not an invoice. The relative sizes are the point, and those do not depend on the tokenizer.

The twenty are the Actors the Store returns for "linkedin jobs", "job search", "job postings", "indeed jobs" and "glassdoor jobs", ranked by users in the last 30 days, plus my three (they are new and would not have made the cut on users).

The table

Where the tokens go

The input schema tracks the number of fields, not the quality of the Actor. Six fields cost 406 tokens; 38 to 41 fields cost 3,410 to 6,061. Every filter an author adds is a line the agent reads on every turn it has the tool loaded. Mine sits in that band on purpose: 38 fields, 3,410 tokens, because the Actor exposes the database's filters (boolean title and description search, exclusions, employer size, industry, salary, applicants, expiry) instead of hiding them behind one free-text box. That is a trade, and the number is its price.

The output schema is the larger half in nine of the twenty tools. The server generates it from the Actor's dataset, so a scraper that returns a deeply nested row pays for it on every turn, and the author never sees it unless they run tools/list themselves. The Indeed scraper at the top of the table returns rows that produced a 3,400-node schema; the tool definition for my jobs Actor has 229 nodes. The other nineteen output schemas came in between 1,068 and 2,217 tokens, which looks like the floor for a flat row with a few dozen keys.

The description is cheap, 43 to 107 tokens. The server takes the Store description verbatim after a preamble ("This tool calls the Actor ... and retrieves its output results. Actor description: ..."). So the one text an author writes for humans is also the text the agent reads to choose between tools, and it is under three percent of the tool's cost. Spend the words there.

What the server does to a listing

Three transformations were visible in the payloads.

Long field descriptions are cut. On the Actor with the longest ones, four of 38 fields ended in "[Description truncated]"; their raw descriptions ran 518 to 810 characters and came through at 371 to 495 plus the marker. Whatever you wrote after the cut, the agent never reads.

Prefill values are appended to the description as "Example values: ...". If the prefill is a realistic example, that is free documentation. If it is a placeholder, the agent copies the placeholder.

required is passed through as written. Four of the twenty require at least one field. A required field that also has a default is a small trap: the agent must supply it even though the Actor would run without it.

The fixed overhead you pay even for one Actor

Pin one Actor and the server still sends four helper tools: get-actor-run (1,437 tokens), abort-actor-run (1,311), get-dataset-items (667) and get-key-value-store-record (373). That is 3,788 tokens before the Actor itself; for the median Actor, half the bill.

Without ?tools=, the default server sends 12 tools and 18,391 tokens: the three discovery tools (search-actors 2,315, fetch-actor-details 1,755, call-actor 2,009), the four helpers, two docs tools, a problem reporter and two web tools (rag-web-browser 4,508, web-fetch 2,647). ?tools=actors keeps discovery and cuts the rest: 7 tools, 9,867 tokens.

What Claude Code does with it

I have five recorded claude -p sessions over the pinned jobs tools from the last three posts, two or three Actors pinned each time. In all five, the agent's first action was ToolSearch with select:mcp__apify__b2bsearch--linkedin-job-search-api,.... Claude Code defers MCP tool definitions above a size threshold: the model sees the names at the start and pulls a definition into context when it decides to use the tool. The first turn of the Java-in-Berlin session carried 43,743 tokens of context before any Actor definition had been fetched.

So in Claude Code the tool tax is not paid on turn one. It is paid from the turn the definition is loaded, on every turn after. The session that ran 18 free previews took 39 turns and read 523,825 cached input tokens in eleven minutes, and the tool definitions were part of every one of those reads. Across the five sessions the agent used between 9 and 16 of the Actor's 38 input fields; the other 22 to 29 rode along in every turn as schema the agent had read and did not need.

A host without deferral puts the whole tools/list into the system prompt on turn one, and pays the table above on every turn from the first. The 15-to-4 post I linked measured exactly that case.

Discovery versus pinning: two sessions, one question

Same prompt, two Claude Code sessions, one difference in the MCP URL. The prompt is a backend developer in Berlin with six years of Java asking which technology to learn next, judged by what German employers ask for: count the base, count the current stack in descriptions, count eight candidates, count two of them together with Java.

Pinned, ?tools=b2bsearch/linkedin-job-search-api,b2bsearch/hiring-companies-finder (the recorded session from the third post): 39 turns, eleven minutes, 18 free previews, 523,825 cached input tokens read. The agent had exact counts for the base and for every technology, by employer, and picked Kubernetes with AWS close behind.

Discovery, ?tools=actors (search, details, call, plus the four helpers: 9,867 tokens of definitions), with money rules added to the prompt: read an Actor's pricing before calling it, cap every call, keep the total small, prefer free counts. 33 turns, fifteen minutes, 32 tool calls: 5 Store searches, 12 listing fetches, 3 paid runs on two scrapers, 11 reads of run state and rows. 220,114 tokens written to cache and 1,571,639 read, three times the pinned session. The agent never saw my Actor: the five searches came back led by the most-used scrapers, and a tool with a handful of users in its first week was in none of the lists. It chose the most-used LinkedIn scraper and an Indeed scraper, pulled 225 rows, filtered them to 82 backend postings, and answered with shares of that sample, labelled as a sample with a ten-point margin, and picked AWS with Kubernetes close behind. The three runs all stayed under the cap the agent had set on each call.

Where the discovery turns went is the part worth keeping. Two of the twelve listing fetches came back over Claude Code's tool-result limit (61,678 and 68,510 characters: a README plus both schemas), one hit a 502, and the rest were 14,000 to 24,000 characters each. Reading listings cost the session more context than running them.

My first attempt at the discovery session had to be killed, and the reason belongs in the post. I had left the shell tool allowed. When a listing fetch overflowed and Claude Code wrote it to a file, the agent read the file with the shell, then started checking the environment and my credentials file for an Apify token so it could call the API directly. Nothing was sent anywhere and the transcript holds no token, but an agent with a shell and a blocked tool result will look for another road. The second run had --permission-mode default and the shell in --disallowedTools, and stayed on the MCP tools.

What I keep in my own schema, and what I changed

The three b2bsearch Actors follow rules I had set before this measurement, and the payloads confirm they survive the server:

• The two fields that change what a run costs, previewOnly and compact, are the fourth and fifth fields in the schema, before any filter, so a client that shows the first N fields shows them.
• Field descriptions are capped at 350 characters by a test in the build (the longest live one is 342). None of my fields carries the "[Description truncated]" marker.
• No required fields. {"previewOnly": true, "titleSearch": ["backend"], "locationSearch": ["de"]} is a complete call.
• Rows nest two levels at most (a company card, a recruiter), which gives an output schema of 2,123 tokens and 229 schema nodes. The 3,400-node schema at the top of the table cost 32,136.

What this measurement changed: I had been treating the input schema as the tool's cost. It is a third to a half of it. The helper tools and the inferred output schema are the rest, and only the second of those is under an author's control, through the shape of the rows the Actor writes.

What I did not do is cut fields. The recorded sessions used nine to sixteen of them, different ones each time, and a database-backed search with fewer filters would just move the filtering into the agent's own loop, which is far more expensive than a schema line.

Three calls to try on the jobs tools

The table is about cost. Here is what the three pinned tools of mine return when an agent asks a plain question. Every call below is a free preview: no rows, no charge, just the count and a breakdown. I ran them on 31 October 2026 and the data runs through 21 October.

LinkedIn Jobs Database API: "how many backend postings in Germany, and who answers them?"

{"previewOnly": true, "titleSearch": ["backend engineer"], "locationSearch": ["de"], "timeRange": "30d"}

155 open postings at 101 employers. Berlin has 41 of them and Munich 17. 18 state a salary and 14 name a recruiter. 55 had fewer than 25 applicants and 29 had over 200, which is the number I would show a candidate before they pick where to apply. My first try used the default 7d window and came back with 0, because the data stops on 21 October; the note on the preview row says so, which is what lets an agent widen the window by itself.

Companies Hiring Now: "which employers are hiring data engineers?"

{"previewOnly": true, "jobTitles": ["data engineer"], "locations": ["Germany"], "postedLimit": "month"}

292 employers posted 540 matching jobs in the last month, agencies and job boards already left out (that filter is on by default here). 192 of the postings went up in the week of 12 October, the busiest of the four. The same call with previewOnly off and decisionMakers on returns one row per employer with the people who would own the hire, which is the version a recruiter or a salesperson wants.

Advanced LinkedIn Jobs Scraper: "is there a market for SREs in the Netherlands?"

{"previewOnly": true, "jobTitles": ["site reliability engineer"], "locations": ["Netherlands"], "postedLimit": "month", "excludeAgencies": true}

18 open jobs at 14 employers, 12 of them mid-senior. 5 name a recruiter and 4 state a salary, all in euros. Small enough that the next call can pull every row with compact: true and still stay cheap for the agent's context.

In an agent session I do not write the JSON. I pin the tool as in the section below and ask in words: "count backend engineer postings in Germany over the last 30 days, free preview only, and tell me which cities lead". The agent fills titleSearch, locationSearch and timeRange from the schema, reads the preview row and answers in one call.

For AI agents reading this

To use the jobs tool from Claude Code with the smallest tool set, pin it:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api" --header "Authorization: Bearer <APIFY_TOKEN>"

or in any MCP client config:

{"mcpServers": {"apify": {"type": "http", "url": "https://mcp.apify.com?tools=b2bsearch/linkedin-job-search-api", "headers": {"Authorization": "Bearer <APIFY_TOKEN>"}}}}

The tool is named b2bsearch--linkedin-job-search-api (mcp__apify__b2bsearch--linkedin-job-search-api inside Claude Code). Call it first with previewOnly: true: it returns the count of matching postings and a breakdown by country, seniority, employment type, industry, top employers, titles and cities, no rows and no charge. Then turn previewOnly off and set limit to pull rows; rows come back through get-dataset-items. Filters that matter most: titleSearch (one line per title variant, boolean allowed), locationSearch (country codes or cities), timeRange (7d, 30d, 6m), descriptionSearch (one line per technology, lines are OR, quote phrases), removeAgency: true to drop staffing agencies and job boards, status (active, expired, any).

To measure any Actor's tool cost: run the handshake above with ?tools=<owner/actor>, take the data: line of the tools/list response, and count the compact JSON of each entry in result.tools. Expect four helper tools in the list besides the Actor.

What this does not measure

Token counts are tiktoken's, not Claude's; the ranking holds, the absolute numbers are a scale. I measured one host, Claude Code, for deferral; other hosts load the list differently. The twenty Actors are a Store search on one day, not the whole category. And none of this says whether a bigger schema makes an agent worse at the task; the post I linked measured call counts for one server, and the discovery session above is one run, not a benchmark.

This post is a companion to the series on developer job search with Claude Code: the first post searches the market by stack, the second measures ghost jobs, the third counts the technologies employers ask for, all over the same pinned tool. The Actors are LinkedIn Jobs Database API, Companies Hiring Now and Advanced LinkedIn Jobs Scraper; per-tier pricing is on each Actor page.

This is the answer I now send back. Seven Actors on Apify, all reading one database of professional profiles and companies: links, what each one takes and returns, what I measured on them on 30 October, and how an AI agent calls them over MCP.

If your last week included a 403 page, a CAPTCHA, or a scraping account that stopped working, start with the next section. It explains why these are lookups and not scrapes.

In one paragraph

The b2bsearch Actors on Apify are a B2B data API over a database of 800M+ professional profiles and 115M companies. Filters, domains, profile URLs or emails go in; leads, employees, company cards, emails and phone numbers come out. Nothing is scraped at run time, misses and counts are free, and every Actor is an MCP tool for Claude Code and other agents.

Why a database and not a scraper

Most listings in this corner of the Store are live scrapers. They need a session cookie or a login, they run through proxies, a run takes minutes, and when the site answers 403 or 429 the scraper retries or stops. The account carrying the risk is yours.

Pricing follows the same logic. Many charge per returned row whether or not the row has what you asked for. Some add a start fee per run, a minimum budget per run, or a lifetime run cap for free accounts.

I read 86 listings in this category in October: about a third have a hard limit for free users and 16 charge a start fee of a cent or more.

The seven Actors below answer from a database. No cookies, no login, no proxies, and a run finishes in seconds. The things that are never charged are the part I would defend anywhere:

Two honest limits. A database lags a live page: rows about people carry a refreshed-on stamp and a _freshness bucket, and the people and leads searches take updatedAfter, so you can insist on fresh records and pay only for those.

And on price I will not claim the cheapest in every niche. In some of them a listing with more users charges less per row; on company search and company employees these sit below the category leader on every plan. The list of what is never charged is where they differ most.

The seven, by what you hold

How to read the sections below

Every section starts the same way: the Actor link, a short overview, what it takes (the filters that matter) and what it returns. Then come scenarios you can repeat, each with the exact input and a table of the fields that come back.

All runs are from 30 October 2026. They go through the same three addresses, so one example is enough to learn the pattern:

The slug is the last part of the link in each section's first line. The headline segment, where I use one, is fintech companies in London with 51 to 200 employees that raised a round since January 2024. Everything else is a fresh example you can paste.

1. Company Search: filters to companies, count first

Company Search · slug company-database-search

You give it a filter box and it returns company rows. The first call should always be a free count: previewOnly: true answers with the size of the segment and charges nothing.

Takes (the filters that matter):

• countries, or countryGroups such as dach, nordics, eu, gcc, latam
• industries and hqLocations (city or state)
• employeesMin and employeesMax, foundedFrom and foundedTo
• hasFunding, fundingRounds (seed, series_a and on), fundedAfter, fundingAmountMin
• companyDomains to look up a known list, previewOnly, maxResults

Returns: one row per company.

Scenario A: Series A software companies in Germany

Count first, free:

{
  "countries": ["de"],
  "industries": ["Software Development"],
  "fundingRounds": ["series_a"],
  "fundedAfter": "2025-01-01",
  "employeesMin": 20,
  "employeesMax": 200,
  "previewOnly": true
}

One row back in 4 seconds: 16 companies match. Swap previewOnly for "maxResults": 5 and the same call returns five company rows in 5 seconds, each with its round type, date and, when it is public, the amount.

Scenario B: a whole region with one word

countryGroups: ["dach"] stands for Germany, Austria and Switzerland, so one input covers three markets:

{
  "countryGroups": ["dach"],
  "industries": ["Financial Services"],
  "employeesMin": 11,
  "employeesMax": 50,
  "hasFunding": true,
  "previewOnly": true
}

Free answer: 236 companies. If that is too many, add fundingRounds or a city before you pay for a single row.

Scenario C: the headline segment

{
  "countries": ["gb"],
  "hqLocations": ["London"],
  "industries": ["Financial Services"],
  "employeesMin": 51,
  "employeesMax": 200,
  "fundedAfter": "2024-01-01",
  "maxResults": 20
}

The trap is headcount: about half of all companies on file carry none, and a size filter drops them unless you switch on includeCompaniesWithoutHeadcount. For a funded fintech list that is fine. For long-tail segments, run the count both ways.

2. Company Enrichment by Domain: one domain, one card

Company Enrichment by Domain · slug domain-to-company

The simplest Actor in the family and the one where agents outnumber humans in my request logs. A list of domains in, a company card per domain out.

Takes: one input, domains, a list of site domains.

Returns: a card per domain.

Scenario A: three domains, three cards

{ "domains": ["stripe.com", "wise.com", "notion.so"] }

Three cards in 8 seconds, each with a headcount, a sector and a funding flag.

Scenario B: what it does when it is not sure

I sent the eight domains from the London list in Company Search. Six came back as cards. Two came back as ambiguous, each with a note that two unrelated company pages list that domain and neither carries its name, and no charge. A guessed card would have cost more than a free "I do not know".

Scenario C: sort a column of form fills

Drop the domain part of every address on your sign-up list into domains, dedupe first, and read employeeRange and hasFunding. You get the account behind each form fill without opening a tab. The full inbound version is inbound lead qualification from the email domain.

3. Company Employees: the roster, the profiles, or the people you can write to

Company Employees · slug company-employees

The account-based door. One company domain per line, and profileDetail picks how much each person row carries. Everything that narrows the list runs before anything is charged.

Takes:

• companies: domains, one per line
• profileDetail: roster (staff list), profile (career record) or contacts (adds emails and phones)
• roles: cxo, founder, vp, director, manager, other
• titleContains and titleExcludes
• mustHave: email, workEmail, currentWorkEmail, personalEmail, phone, github, twitter, facebook
• compact: true for agents, maxRows to cap

Returns: one row per person, wider with each tier.

Scenario A: who runs this company

{
  "companies": ["stripe.com"],
  "roles": ["founder", "cxo"],
  "profileDetail": "roster",
  "compact": true,
  "maxRows": 5
}

Five people in 4 seconds with title, seniority and the two email flags. The sixth row is a free note, skipped_row_budget, telling you more people matched and maxRows cut the list.

Scenario B: the sales leaders of one company, with an address

{
  "companies": ["wise.com"],
  "titleContains": ["head of sales", "sales director"],
  "profileDetail": "contacts",
  "mustHave": ["email"],
  "compact": true,
  "maxRows": 5
}

Four people in 6 seconds, each with an address, its label and the profile. People without an address are skipped for free and counted in one note row.

Scenario C: leaders across a list of accounts

I ran the two largest companies from the London list twice.

Of the 20 leaders, 12 came with a company address and 7 with a personal one. The row says which tier it could actually answer: _detail reads contacts when a contact reaches the person today and profile when it does not, and the price follows the row, not the request.

Scenario D: read before you write

Take companies: ["wise.com"], roles: ["founder", "cxo"], "profileDetail": "profile", "compact": true and "maxRows": 3. Three rows come back in 5 seconds with about, positions, education, skills and followersCount. That is enough context for an LLM to draft an opener that mentions something real.

Two more notes. A repeat of an employee already delivered never charges, so re-running a domain next month costs only the new people. And compact: true is the switch for agents: the compact contacts row was about a third the size of the full one in my run, with the same identity, role, five latest positions and contact fields.

The listing prices this Actor below the category leader on every Apify plan. That is a Store fact, not a promise from me; the pricing tab has the per-plan numbers.

4. B2B Leads Finder: a filter box, people with a live email

B2B Leads Finder · slug b2b-leads-finder

The Apollo alternative in the family. You describe the people; every delivered lead has an email at their current employer or a personal one, plus the profile and social links. People who fail the test are not sold: they come back as free note rows with a count.

Takes:

• jobTitles, excludeJobTitles, titleMatch (substring or word), seniority
• countries, countryGroups, cities, companyHqCountries
• industries, companySizeMin and companySizeMax, keywords
• companyDomains for named accounts, pastCompanyDomains for alumni of a company
• emailType: any, work or personal; includePhones
• maxPerCompany, excludeDatasets, updatedAfter, apolloUrl instead of all of the above

Returns: one row per lead.

Scenario A: marketing heads at mid-size software companies

{
  "jobTitles": ["head of marketing", "vp marketing"],
  "countries": ["us"],
  "industries": ["Computer Software"],
  "companySizeMin": 51,
  "companySizeMax": 200,
  "emailType": "work",
  "maxPerCompany": 1,
  "maxResults": 10
}

About 20 seconds. The skipped rows are the feature: the Actor reads the profile, sees the position is closed, and says so in a note row instead of selling you a dead lead.

Scenario B: alumni of a company you compete with

pastCompanyDomains finds people who used to work somewhere. Sales leaders in the DACH region who left a big CRM vendor:

{
  "jobTitles": ["sales director", "vp sales"],
  "countryGroups": ["dach"],
  "pastCompanyDomains": ["salesforce.com"],
  "emailType": "work",
  "maxResults": 5
}

Five leads in 19 seconds, 11 skipped for no work address and 11 more because they had already moved on. These are people who know the tool you replace, which is the warmest cold list I know how to build.

Scenario C: leads with a mobile number

{
  "jobTitles": ["vp sales", "chief revenue officer"],
  "countries": ["us"],
  "industries": ["Computer Software"],
  "companySizeMin": 51,
  "companySizeMax": 500,
  "emailType": "work",
  "includePhones": true,
  "maxPerCompany": 1,
  "maxResults": 10
}

Ten leads in 17 seconds, 4 of them with a mobile on record. The phone sits in the same row as the email, so there is no second lookup.

Scenario D: the headline segment, sized first

Before pulling I size the people box for free on People Search with mode: "count". Sales leaders at London fintechs of this size: 231 people. mode: "market" then shows the shape, seniority, employer size and the title spellings in use, also free. The pull itself, work addresses only and one lead per company:

Scenario E: only the new people next week

Pass the dataset id of last week's run in excludeDatasets and rerun the same search. Everyone already delivered is left out and never charged again.

I wrote a whole post on the dead rows: 243 of 417 leads in a typical ICP box were dead before the first email. Built the search in Apollo? Paste its URL into apolloUrl; a Sales Navigator saved search has a twin that takes the URL: Sales Navigator alternative in Claude Code.

5. Email Finder: profile URLs to addresses on record, labelled

Email Finder · slug linkedin-email-finder

You hold profile URLs, you want addresses. It returns the addresses in the person's record, never a pattern guess.

Takes:

• profileUrls: full URLs or bare handles, up to 1,000 per run
• includePersonalEmails: off by default

Returns: one row per profile.

Label meaning: work_current is an address on the current employer's domain, work_other is a company address it cannot tie to the current employer, personal shows up only when you switch the flag on. A no_email row is free and still carries the name, title and employer; a not_found row is free too.

Scenario A: addresses for a list you already hold

{
  "profileUrls": ["satyanadella", "jane-doe-example"],
  "includePersonalEmails": false
}

I fed it the 10 profile URLs from the marketing-leads pull above with personal mailboxes switched on. All 10 came back as work_current in 4 seconds. That is the point of starting from a leads search: the profile URL is a by-product of the pull.

Scenario B: a roster with a hit rate

The 20 roster rows from the Company Employees run went in: 13 came back with a company address, 7 as free rows, 2 of those with a note that a personal mailbox is on record. About 5 seconds.

The labels matter more than the hit rate. On a 200-URL list of marketing leaders earlier this week, about half of the addresses on record were at an older employer, and the label is what kept them out of the send list. That run is here: Bulk email finder in Claude Code: 200 profile URLs, 64 still current.

6. Phone Number Finder: verified mobile numbers, pay per found

Phone Number Finder · slug linkedin-to-phone

Direct dials, not switchboards. It is built to take whatever you already have and find the mobile.

Takes: profileUrls, one entry per line, up to 20,000 per run. Each line can be a profile URL or handle, an email address, or a name plus domain like Jane Smith, acme.com.

Returns: one row per entry.

A miss is a free no_phone row. It is US-centric, by the listing's own words and in my runs.

Scenario A: a mobile for each US lead

I sent the 10 US marketing leads from section 4 by profile URL:

{ "profileUrls": ["https://www.linkedin.com/in/<handle>", "<handle>"] }

Three came back with a mobile, seven as free no_phone rows, in 6 seconds.

Scenario B: the same people, by email

Same 10 people, but the input is their work addresses, one per line. Same result: 3 numbers, 7 free rows. This is the version for a CRM export that has addresses and no profile links.

Scenario C: names and domains only

{ "profileUrls": ["Jane Smith, acme.com", "Raj Patel, example.org"] }

Use it when all you have is a name and a company. I did not run this form today; it is in the listing's input description.

Earlier this week a hundred US sales leaders gave a mobile for 35 of them, chief revenue officers about half, directors one in four. My London roster gave almost nothing, and the misses cost nothing. Run it on US rows. The full call-list recipe is in Lusha and ZoomInfo alternative in Claude Code.

7. Email to Profile Finder: an address in, the person out

Email to Profile Finder · slug email-to-linkedin

The inbound door. It turns email addresses, work or personal, into the person.

Takes: emails, one address per line, up to 1,000 per run. Put a name beside a work address to find more: Jane Doe <jane@acme.com> or jane@acme.com, Jane Doe.

Returns: one row per address.

Addresses it cannot match, invalid ones and duplicates come back as free rows that say why.

Scenario A: a column of work addresses

{ "emails": ["jane@acme.com", "Jane Doe <jane@acme.com>"] }

Ten work addresses from the leads pull went in and 10 people came out, every one matchedVia: as_given, in 6 seconds.

Scenario B: close the loop

The 13 addresses the Email Finder returned for the London roster went back in. 13 people came out, and all 13 were the profiles the roster started from. About 6 seconds.

Scenario C: a form fill becomes an account

A visitor leaves an address. Run it here, take companyLinkedinUrl or the domain into Company Enrichment by Domain, then Company Employees for the decision makers next to them. That is the inbound chain in inbound lead qualification from the email domain.

How they chain

What does an agent pay to load all seven?

An MCP tool costs tokens before it is called: the description, the input schema and the output schema the server infers from rows. I measured tools/list on the hosted Apify MCP server with the seven pinned, tiktoken o200k on compact JSON.

For scale: two days ago I measured 20 job Actors the same way and got a median of 3,829 per tool, with one at 32,737. The seven here sit at a median of 2,016.

The descriptions are 80 to 97 tokens each; the weight is in the input schemas of the search Actors and in the inferred output schema of Company Employees. Flat rows keep that schema small, and compact: true keeps the rows small after the call.

Method and the job numbers: MCP tool cost: 20 job Actors on Apify.

Wiring: Claude Code, MCP, n8n, REST

Pin the Actors in the server URL so an agent loads only these definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/company-employees,b2bsearch/b2b-leads-finder,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/email-to-linkedin" --header "Authorization: Bearer <APIFY_TOKEN>"

The same server in any MCP client (Cursor, Windsurf, Claude Desktop, ChatGPT, LangChain, CrewAI, the OpenAI Agents SDK):

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/company-employees,b2bsearch/b2b-leads-finder,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/email-to-linkedin",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen: b2bsearch--company-employees, b2bsearch--b2b-leads-finder, and so on. Cap a run with callOptions.maxTotalChargeUsd, read rows with get-dataset-items and a fields list, and run the free count before the paid pull.

Without an agent: every Actor is a REST endpoint. One call, rows back in the response:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~domain-to-company/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["acme.com", "example.org"]}'

The same Actors are steps in n8n, Make and Zapier through the Apify integrations, and the Store page of each one has the input schema, the output example and the per-plan price.

What the agent did on its own

I gave a Claude Code session the seven tools pinned and a brief: size the segment, pull ten companies, get the leadership of the two largest with a current work email, fall back to the email finder where that fails, cap every paid run, report a ledger. Shell and file tools were denied. Eleven turns, about four minutes, four Actor runs.

What it did without being told:

• loaded all seven tool definitions first, then wrote a cost table from the descriptions before the first paid call, naming the tools it would not use
• added hasFunding: true and sort: "employee_count_desc" to the company search; its free count matched mine, 79
• read rows with a fields list that left out description, the longest field on a company card
• added titleExcludes for assistants, "office of" and chiefs of staff to the leadership pull, after reading the field description that warns the C-level bucket catches them
• noticed that callOptions is in no Actor's schema and passed the spend cap anyway, in the call options of the MCP server

Where it stopped. It asked Company Employees for leaders with an address at the current employer, exactly as briefed, and both runs came back as one free note row each: the leaders on record did not carry one, so nothing was delivered and nothing charged. With no profile URLs in hand it skipped the email finder, handed over the account list with a trust column (two rows marked questionable, one not fintech by its industry, one to check for HQ) and stopped.

That is the behaviour I want from an agent spending money. It is also a brief bug: step three should pull the cheap roster first and run the finder on its URLs. With the requirement loosened to any address on record, the same two companies gave 20 people in my own run above.

What this does not do

It does not read a live page. A row can be months old; the stamp is on rows about people, and updatedAfter on the people and leads searches lets you refuse old ones. The email finder does not verify deliverability; the Work Email Finder does that for name-plus-domain lookups.

Phone coverage is US-centric. And the free Apify plan caps a run at a hundred results and an account at five hundred rows a month per Actor, with the same rows paid users get; any paid plan lifts that.

FAQ

Is this an Apollo, Lusha or Sales Navigator replacement? For building lists and enriching them by domain, URL or email, yes: no seat, no login, pay per found row. For browsing profiles one at a time in a sidebar, no.

Do these Actors scrape anything when I run them? No. The answer comes from a database of publicly available professional data; the network names in the listings describe the kind of data, not a crawl at run time.

Where do the email addresses come from? From the contact block of the person's record. The email finder returns only what is on record and labels it; nothing is generated from a name pattern.

How do I stop an agent from overspending? Pin the tools, cap every run with maxTotalChargeUsd, run the free count or previewOnly first, and use excludeDatasets so a rerun never pays for the same person twice.

Which one first? Hold a domain: Company Enrichment by Domain, then Company Employees. Hold a filter: Company Search for accounts, B2B Leads Finder for people. Hold URLs or emails: the finders.

For AI agents reading this

The seven Actors run as tools over the hosted Apify MCP server with the tools pinned in the URL (the wiring block above). The workflow, tool by tool:

• b2bsearch--company-database-search with previewOnly: true to size a segment, then rows with maxResults
• b2bsearch--domain-to-company for a card per domain; _status ambiguous means do not guess
• b2bsearch--company-employees with profileDetail, roles, mustHave and compact: true
• b2bsearch--b2b-leads-finder with emailType, maxPerCompany and excludeDatasets
• b2bsearch--linkedin-email-finder and b2bsearch--linkedin-to-phone with profileUrls
• b2bsearch--email-to-linkedin with emails

Every row has _status; rows other than found are free and say why in _note or _error. Read results with get-dataset-items and a fields list. Per-plan pricing is on each Actor page; set callOptions.maxTotalChargeUsd on every paid run. Platform docs: Apify MCP server and apify.com/agents.md.

This is the map of what $10 buys in B2B data with the b2bsearch Actors, and then, for each one, what you send, what comes back, why the columns matter and which Actor to run next.

The quantities are Starter-plan prices rounded down; on the free plan the same ten dollars is two months of credit and buys about as much, a little less on the leads and phone finders. No hit rates and no benchmarks today; those are in the posts linked along the way.

In one paragraph

b2bsearch on Apify is a family of pay-per-row Actors over one database: 1B+ professional profiles, 115M companies, 50M+ job postings.

A filter, a list of domains, profile URLs, emails or a CSV goes in; a flat table comes out, with emails and phones where they are on record. Misses, counts and repeats are free. No cookies, no login, no proxies, and every Actor is an MCP tool for Claude Code and other agents.

What $10 buys

B2B Leads Finder4,000 leads, each with a live email

Company Employees1,100+ employees of your target accounts, with emails and phones

Decision Maker Email Finder by Domain3,100 founders, C-level and VPs with their emails

Company Search6,600 companies by industry, headcount, HQ and last round

Company Enrichment by Domain1,800 company cards for a list of domains

People Search5,000 people rows from 35+ filters, count and market shape free

Email Finder1,250 emails at the current employer for profile URLs you hold

Phone Number Finder900 verified US mobile numbers

Profile Lookup and Bulk People Enrichment3,100 full career records, or rows of a CSV resolved by any key

Reverse Email Lookup3,100 people behind email addresses

Companies Hiring Now4,100 employers hiring for a role, with their hiring pace

Jobs Scraper and Jobs Database API12,500 job postings with the company card, or 6,200 with the named recruiter and the employer's pace

Misses are free rows on every one of them, so the budget goes to answers, not attempts.

How to make the credit go far

Five habits, all of them free:

• Count before you buy. Company Search and the jobs Actors have previewOnly; People Search has mode: "count" and mode: "market". A count tells you the size of a segment, a market run tells you its shape, and neither charges a row.
• Let the misses be free. A person with no email, a domain nobody claims, a namesake with five holders: each comes back as a row with a _status and a note, and no charge. Read the notes; they are the autopsy of your list.
• Say what a row must have. mustHave (currentWorkEmail, personalEmail, phone, github and so on) means a row without it is skipped free and counted in one note row, instead of delivered and paid for.
• Never pay for the same person twice. excludeDatasets on the search Actors takes the datasets of earlier runs and leaves everyone in them out. A weekly rerun costs only the new people.
• Cap the run. maxResults, maxRows, maxPerCompany, and callOptions.maxTotalChargeUsd when an agent is doing the calling.

The free plan returns up to a hundred results per run, with a monthly allowance per Actor; counts and previews sit outside it, and any paid plan lifts it. The rows themselves are the same on every plan.

Start from a filter: you have an ICP, not a list

B2B Leads Finder

B2B Leads Finder is the one to open when the brief reads "VPs of sales at US software companies with 50 to 500 people", and the Apollo alternative in the family.

Job titles, seniority buckets, countries or regions (dach, nordics, latam), cities, company size, industries, headline keywords, account domains, past employers, a refresh date. Or paste an Apollo people-search URL and let the Actor read the filters out of it.

{
  "jobTitles": ["vp sales", "head of sales"],
  "countries": ["us"],
  "companySizeMin": 50, "companySizeMax": 500,
  "industries": ["Software Development"],
  "emailType": "work",
  "maxPerCompany": 2,
  "maxResults": 200
}

Every row is a person with a live email: name, title, headline, the address and whether it is work or personal, both when both exist, company name, domain, size and industry, location, the profile URL, X, GitHub and Facebook links where on record, a phoneOnRecord flag (switch on includePhones for the number itself), a stable personId and a _freshness bucket. People without an email are not delivered and not charged; the note rows say how many, and why.

That is a send-ready list, and the reason the family exists. Next: excludeDatasets for next week's delta, Profile Lookup when you want the whole career behind a lead, Phone Number Finder for the call list. The deep dive: Apollo alternative in Claude Code: 7 lead lists from one Apify Actor.

People Search

People Search is the same database with every filter exposed, 35+ of them. Title and headline keywords with AND lists, seniority, employer domains, industries and headcount, employer HQ country, past employer and the year they left, past titles, career start year, tenure, city, languages, connection count, people between jobs, records refreshed after a date.

Three modes. count answers with one number. market answers with the shape, countries, seniority, employer size, industries, top titles, top employers, how many have a personal or a work address, one row per bucket; segments compares up to ten variants in one run. people returns the rows at the tier you choose: row (name, title, employer, location, email flags), profile (the career record) or contacts (plus emails and phones), with compact for agents.

This is where the signals live: who left a competitor since last year (pastEmployerDomains plus leftPastEmployerAfterYear), who started a role this quarter (currentRoleStartedAfterDate), fractional execs by headline. Two worked examples: the warmest cold list, people who left one company since 2025 and fractional CFOs by headline.

Company Search

Company Search builds the account list: countries or groups, industries (a sector covers everything under it), HQ city or state, founding year, headcount band, and funding: hasFunding, last round after or before a date, the stage of the last round, the amount. previewOnly: true first.

{
  "countries": ["gb"],
  "industries": ["Financial Services"],
  "hqLocations": ["London"],
  "employeesMin": 51, "employeesMax": 200,
  "fundedAfter": "2024-01-01",
  "previewOnly": true
}

A company row: name, primary domain, website, company page URL, headcount, industry with its taxonomy id, last round type, date and amount, founding year, description, country and HQ. Unknown facts are left out, never shipped as empty strings; a company the store holds twice comes back once, the duplicate as a free row.

The domain column is the handle for everything below: paste it into Company Employees, Decision Makers or Lookalike Company Finder.

Companies Hiring Now

Companies Hiring Now turns a job search into the employers behind it. Job titles as boolean lines ("account executive" OR "sales development"), countries, states or cities, how far back, experience level, employment type, industries, agencies out. Turn on decisionMakers with roles, a per-company cap and title keywords, and each employer comes with the people who own the budget.

One row per employer: the company card (domain, industry, headcount, country, HQ, funding), how many postings matched and how many are still open, first and last posting dates, open postings in total, postings in the last 7, 30 and 90 days, the seniority mix and the most posted titles of the last month.

Then one row per decision maker: name, title, seniority, profile URL, freshness.

A company hiring three account executives this month has a sales budget and a sales leader under pressure. That is a better trigger than any firmographic. Next: Company Employees for the rest of the team, Email Finder for the addresses.

Jobs Database API

Jobs Database API is the posting-level search over 50M+ job postings from the last 180 days. Boolean title and description search with exclusions, location, employer size and industry, agencies out.

Then seniority, employment type, salary stated or above a floor, an applicant-count ceiling, posted after a date, open or expired, and the people behind the job: the named recruiter, the employer's hiring pace, the employer's decision makers. previewOnly gives the market breakdown free; compact keeps rows short.

A job row: title, URL, posted date, the company card, location, seniority, employment type, salary text and parsed range, applicant range, recruiter name and profile URL, the employer's open postings and 7, 30 and 90-day pace with its top titles, whether the posting is still open and until when, the description as text or markdown.

Recruiters use it for market maps, sales teams for "who just posted for the role my product replaces", developers for a job search without the duplicates. Two posts came out of it: half of US backend postings were copies and ghost jobs, measured.

Start from domains: you have the accounts

Company Enrichment by Domain

Company Enrichment by Domain takes a column of websites in any form (acme.com, a URL with a path, www) and returns one card per domain: company name, company page URL, website, industry, headcount and range, country, HQ city and region, founding year, description, last funding round with date and amount.

{ "domains": ["acme-robotics.com", "https://www.northwind-logistics.co.uk/about"] }

Three statuses. found is the card. not_found means no company lists this domain as its site, free. ambiguous means several unrelated pages claim it, or it is a shared host like github.io, also free, and never a guess. Use it to qualify inbound (a form fill with a company domain becomes a size, an industry and a funding stage in one call), to clean a CRM, or to feed the two Actors below.

Decision Maker Email Finder by Domain

Decision Maker Email Finder by Domain answers the question every account list ends with: who runs this place. Domains in, up to five hundred per run, roles to pick from founders, C-level, VPs and directors, maxPerCompany in rank order, titleKeywords to keep only marketing, finance or engineering.

A row per person: rank, company name and headcount, full name, job title, seniority bucket, headline, profile URL, location, in-role-since year, email flags, and email with its type: a work address on the company's own domain when one reaches the person today, else a personal one, at no extra charge. A domain with nobody on record comes back free, with a hint about brand domains.

This is the ten-accounts-by-Friday Actor. Next: Phone Number Finder on the profile URLs for the call list, Company Employees when you need the layer below the leadership.

Company Employees

Company Employees is the org map. Domains in, and profileDetail decides the depth: roster for the staff list (name, title, seniority, headline, city, email flags, profile URL, freshness stamps), profile for the career record of each person, contacts for emails, phones and social links. roles keeps seniority buckets, titleContains and titleExcludes pick departments, mustHave keeps only people you can reach, excludeLowSignal drops self-declared profiles, compact keeps rows short for agents.

{
  "companies": ["acme.com"],
  "roles": ["vp", "director"],
  "titleContains": ["sales", "revenue"],
  "profileDetail": "contacts",
  "mustHave": ["email"],
  "compact": true
}

Why the roster first: it is the cheapest tier and it carries hasWorkEmail and hasPersonalEmail per person, so you can pick the twelve people who matter and send only those to the contacts tier or to the Email Finder.

A repeat of an employee already delivered never charges, so re-running an account next month costs only the new hires. Full walk-through: account mapping by company domain.

Start from people you already have

Email Finder

Email Finder takes profile URLs or bare handles, up to a thousand per run, and returns the addresses on record, never a pattern guess.

Each row is labelled: work_current for the current employer's domain, work_other for an older company address, personal when includePersonalEmails is on, with the whole workEmails list and a count. A profile with nothing on record is a free no_email row that still names the person and says when a personal mailbox exists.

The labels are the product. A list of two hundred URLs becomes three piles, send now, verify first, skip, in one run: bulk email finder in Claude Code. For the "verify first" pile, Work Email Finder takes name plus domain, ranks candidates and checks the best one against the mail domain.

Phone Number Finder

Phone Number Finder accepts a profile URL, an email, or "Jane Smith, acme.com" per line, up to 20,000 a run, and returns verified mobile numbers: direct dials, never a switchboard, with name, title, company, location and a _freshness bucket.

A known profile without a number is a free no_phone row. It is US-centric by design, so run it on US rows and expect little elsewhere. The call-list recipes: Lusha and ZoomInfo alternative in Claude Code.

Profile Lookup and Bulk People Enrichment

Profile Lookup is the full record for a list of profile URLs: headline, current title and company, location, industry, connection count, tenure and total experience in years, every position with dates and descriptions, education, skills, languages, certifications, patents and publications when the profile has them, updatedAt for the record's age, and with contacts on, the emails and phones.

It also reads the input names other profile scrapers use (urls, publicIdentifiers), so an existing integration only changes the Actor id.

Bulk People Enrichment is the same record for a CSV of up to 50,000 rows, each resolved by the strongest key it carries: email, profile URL, GitHub, X or Facebook handle, or a full name with a company domain. Namesakes come back as a free ambiguous row with the holder count, never a guess, and rows stream into the dataset as they resolve.

This is the fifty-columns pair, and the reason to pull the full record even when you only need a name: once the table is on your machine you can filter by anything in it. More on that below.

From an email, a name or a handle

Reverse Email Lookup turns any email into the person's full career row.

Email to Profile Finder is the lighter version: profile URL, name, headline, title, company and location, with a name beside a work address to find more. Name to Profile resolves "Jane Smith, acme.com" to the profile and career.

Social Handle Lookup does the same from a GitHub, X or Facebook handle. All four: an invalid or unmatched entry is a free row that says so.

The rest of the family, one line each

Work the table on your machine

Every run writes a dataset, and a dataset exports as JSON, CSV or XLSX from the Console or from one URL:

https://api.apify.com/v2/datasets/<DATASET_ID>/items?format=csv&clean=true&token=<APIFY_TOKEN>

Pull the profile tiers and you have fifty-plus columns per person: every position with dates, the employer card behind each one, education, skills, languages, email flags, freshness. That is where the "exactly the leads you need" part happens, after the pull and for free: people who were at a competitor before this job, who started this year, whose record was refreshed since spring, who list a language your rep speaks. One query over the CSV in DuckDB, a filter in Sheets, a WHERE in pandas.

SELECT fullName, jobTitle, companyName, email
FROM 'leads.csv'
WHERE emailType = 'work' AND _freshness IN ('fresh_90d', 'updated_1y')

Join on companyDomain to the company cards, dedupe on personId, and feed the survivors to the next Actor by their profile URL. The database answers in seconds; the thinking happens locally, on columns you paid for once.

Four combinations worth stealing

• Hiring signal to inbox. Companies Hiring Now (the titles your product serves, agencies out, decision makers on), then Company Employees (roles: ["vp", "director"], titleContains for the function), then Email Finder on the rows you picked.
• Inbound in one minute. Email to Profile Finder on the form-fill address, Company Enrichment by Domain on its company domain, Decision Maker Email Finder for the two people above the one who filled the form. The write-up.
• Competitor alumni. People Search with pastEmployerDomains and leftPastEmployerAfterYear, market first to see where they went, then people with mustHave: ["email"].
• CRM refresh. Bulk People Enrichment on the CRM export; rows whose current employer no longer matches the CRM, or whose updatedAt is old, are the ones to re-check, and Company Employees on the old domain tells you who replaced them.

Wiring: Claude Code, MCP, REST, n8n

Pin the Actors you use in the server URL, so an agent loads only those definitions:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/people-database-search,b2bsearch/company-database-search,b2bsearch/domain-to-company,b2bsearch/domain-to-decision-makers,b2bsearch/company-employees,b2bsearch/linkedin-email-finder,b2bsearch/linkedin-to-phone,b2bsearch/hiring-companies-finder,b2bsearch/linkedin-job-search-api" --header "Authorization: Bearer <APIFY_TOKEN>"

{
  "mcpServers": {
    "apify": {
      "type": "http",
      "url": "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/company-employees,b2bsearch/domain-to-company",
      "headers": { "Authorization": "Bearer <APIFY_TOKEN>" }
    }
  }
}

Tool names use a double hyphen (b2bsearch--company-employees). Any Actor is also one REST call that returns the rows in the response:

curl -X POST "https://api.apify.com/v2/acts/b2bsearch~domain-to-decision-makers/run-sync-get-dataset-items?token=<APIFY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"domains": ["acme.com"], "roles": ["founder", "cxo"], "maxPerCompany": 3}'

And a step in n8n, Make and Zapier through the Apify integrations, or a tool in LangChain, CrewAI and the OpenAI Agents SDK through the same MCP server.

FAQ

Is any of this scraped when I run it? No. The Actors answer from a database of publicly available professional data; nothing is crawled at run time, and no account of yours is involved.

Which Actor first? A filter: B2B Leads Finder for people, Company Search for accounts. A domain: Company Enrichment by Domain, then Decision Makers or Company Employees. URLs, emails, names or a CSV: the finders and Bulk People Enrichment. A job title: Companies Hiring Now.

What happens on a miss? A free row with _status and a note. Not found, no email, ambiguous domain, namesake, skipped by mustHave: each has a name, and none is charged.

How fresh is the data? Rows carry _freshness and updatedAt, and the search Actors take updatedAfter. It is a database, so a record can be months old, and it tells you when.

Does the free plan get the same rows? Yes, with a cap per run and a monthly allowance per Actor; counts and previews are outside both.

For AI agents reading this

The b2bsearch Actors run as tools over the hosted Apify MCP server with the tools pinned in the URL (above). Pick by the key the user holds:

• filters: b2bsearch--b2b-leads-finder, b2bsearch--people-database-search (mode: "count" first), b2bsearch--company-database-search (previewOnly: true first)
• domains: b2bsearch--domain-to-company, b2bsearch--domain-to-decision-makers, b2bsearch--company-employees (compact: true)
• profile URLs: b2bsearch--linkedin-email-finder, b2bsearch--linkedin-to-phone, b2bsearch--profile-lookup
• emails: b2bsearch--email-to-linkedin, b2bsearch--reverse-email-lookup; a CSV: b2bsearch--bulk-people-enrichment
• job titles: b2bsearch--hiring-companies-finder, b2bsearch--linkedin-job-search-api (previewOnly: true first)

Every row has _status; rows other than found are free and explain themselves in _note or _error. Read results with get-dataset-items and a fields list. Set callOptions.maxTotalChargeUsd on every paid run; per-plan pricing is on each Actor page. Platform docs: Apify MCP server and apify.com/agents.md.

So I saved the combinations people actually ask for as ready-made tasks. A task page shows the input already filled in, the columns you will get and a Try for free button. The button copies the task into your Apify account, you change a field or two and press start

Below are thirty of those jobs, grouped by the problem you walk in with. For each one: the link, the input, what comes back and what to run next. The counts were taken with free previews on 31 October 2026

How to use a task

Open the link, press Try for free, change what you need, press Start. The input on the page is plain JSON, so the same object works from the API, from Make or n8n, and from an agent over MCP.

Two habits save most of the budget. Count first wherever the Actor has a free count or preview. And cap the run with maxResults or maxRows until you like what comes back.

You have an ICP and no list

This is where B2B Leads Finder lives. You describe the people, it returns one row per person, and every row has a live email.

1. Sales leaders at mid-size US companies. Open the task.

{"jobTitles": ["vp sales", "head of sales", "chief revenue officer"], "countries": ["us"], "companySizeMin": 50, "companySizeMax": 1000, "emailType": "any", "maxResults": 100}

Each row brings fullName, jobTitle, email with emailType set to work or personal, the company name, domain, size and industry, location and the profile link. phoneOnRecord tells you for free whether a mobile number exists. People with no live email are skipped and counted in a note row, not charged.

Two fields worth knowing here. maxPerCompany stops one big employer from eating the list. excludeDatasets takes the dataset of last week's run and leaves those people out, so a weekly rerun only brings new names.

2. Small business owners. Open the task. The trick is in one field: "owner" also matches product owners and process owners, so the task excludes them.

{"jobTitles": ["owner", "founder", "ceo"], "excludeJobTitles": ["product owner", "process owner"], "countries": ["us"], "companySizeMin": 1, "companySizeMax": 50, "emailType": "any", "maxResults": 100}

3. Managing directors in Germany. Open the task. Local markets write titles in the local language, so search in it.

{"jobTitles": ["geschäftsführer", "inhaber", "managing director", "ceo"], "countries": ["de"], "companySizeMin": 10, "companySizeMax": 250, "emailType": "any", "maxResults": 100}

4. HR and talent leaders, or procurement managers. Same Actor, different titles. The HR task asks for work addresses only with "emailType": "work", which is what you want when you sell to a company and not to a person. The procurement task adds "industries": ["Manufacturing"] and a seniority floor so buyers come without interns.

5. You already built the search in Apollo. Open the task. Paste the people-search URL into apolloUrl and the Actor reads the filters out of it. No Apollo login and no credits.

6. You need people you can call, not just email. Leads with Phones takes the same filters and only returns people who have both a verified mobile and a live email. Sales leaders with mobiles and real estate agents and brokers are ready to run.

{"jobTitles": ["realtor", "real estate agent", "real estate broker", "broker associate"], "industries": ["Real Estate"], "countries": ["us"], "maxResults": 50}

Rows carry phone in E.164, every number in phones, the email and the company. A skipped_no_contact note row says how many matching people had no mobile or no email. Those cost nothing.

Count before you pay for a single row

People Search has a count mode and a market mode. Neither charges per row, and they answer the question you should ask before any list: how big is this, really.

7. How many software engineers per country. Open the task.

{"mode": "count", "titleKeywords": ["software engineer", "software developer"], "segments": [{"name": "United Kingdom", "countries": ["gb"]}, {"name": "Germany", "countries": ["de"]}, {"name": "Canada", "countries": ["ca"]}]}

One row per segment with _total. Today the UK came back with about 186 thousand, Canada 166 thousand and Germany 116 thousand. The US and India stop at the count ceiling of a million, which tells you to narrow before you pull.

8. Compare sales team size across companies. Open the task. Each segment is a company domain, the titles are account executives, SDRs and sales managers. Handy for sizing a territory or for a competitor slide.

9. Count a Sales Navigator search before exporting it. Open the task. Paste the search URL, get the count, then run the export task with the same URL. The sample search for US heads of growth counted 1,278 people. No seat and no cookies.

Then switch mode to people and you get rows. Two filters people rarely find on their own: onlyBetweenJobs for people with no current position, and careerStartYearMin for engineers early in their career.

You hold profile URLs or emails

The two most used Actors in the family live here. The tasks use placeholder inputs, so replace them with your own list.

10. Profile URLs to mobile numbers. Open the task on Phone Number Finder.

{"profileUrls": ["https://www.linkedin.com/in/jane-doe-example", "jane.example@example.com", "Jane Example, example.com"]}

The field takes profile links, email addresses and "Name, domain" lines in one list, mixed freely. A found row has primaryPhone, all numbers in phones, phoneCount, the name, title, company and location. no_phone, not_found and profile_removed are free rows that tell you why.

11. CRM contacts with an email and no number. Open the task. Same Actor, the list is just emails. Export the column from the CRM and paste it.

12. Profile URLs to work emails. Open the task on Email Finder.

{"profileUrls": ["https://www.linkedin.com/in/jane-doe-example"], "includePersonalEmails": false}

The row gives email, every company address on record in workEmails, and emailType. That last field is the one to read. work_current is an address at today's employer. work_other is an address from somewhere else, usually an old job.

13. Find the CRM contacts who will bounce. Open the task. Same input, different reading. Every work_other row is a contact whose address in your CRM probably points at a former employer. Fix those before the next sequence, not after the bounce report.

14. Personal emails for recruiting. Open the task. Flip includePersonalEmails to true and gmail or outlook addresses come back too, which is what a recruiter needs for someone who should not get a job offer at their work address.

You have a list of companies

Company Employees and Decision Maker Email Finder by Domain both start from a website domain.

15. The leadership team of one company. Open the task.

{"companies": ["hubspot.com"], "roles": ["cxo", "vp", "director"], "titleExcludes": ["assistant", "office of", "executive operations", "chief of staff"], "excludeLowSignal": true, "maxRows": 200}

Rows carry fullName, title, seniority, location, positionStartYear, hasWorkEmail, hasPersonalEmail and the profile link. The titleExcludes list is there because executive assistants love titles like "Office of the CEO".

16. Every employee, then contacts only for the ones you need. The roster task uses "profileDetail": "roster", the light tier, to list the whole company. The contacts task switches to "profileDetail": "contacts" with "mustHave": ["email"], so anyone without an address is skipped for free.

17. Engineers at a company you recruit from. Open the task. titleContains takes engineer and developer, titleExcludes drops sales engineers and solutions engineers.

18. The CEO and founders of a list of companies. Open the task.

{"domains": ["linear.app", "vercel.com", "supabase.com", "posthog.com", "retool.com"], "roles": ["founder", "cxo"], "maxPerCompany": 3}

Rows come ranked per company in _rank, with the title, seniority, profile link and an email that reaches the person today. That means an address on the company domain, else a personal one, never one at a past employer. There are ready versions for marketing leaders and CTOs and engineering leaders.

19. The email format of a domain. Open the task on Company Email Format Finder. Send domains and get pattern like first.last, how many real addresses confirm it, how strongly they agree, and a few masked samples. Useful when you have a name and a company and nothing else.

You want a reason to reach out

A list is cold until something happens at the company. These tasks start from the something.

20. Companies hiring account executives right now. Open the task on Companies Hiring Now.

{"jobTitles": ["account executive"], "locations": ["United States"], "postedLimit": "month", "excludeAgencies": true, "maxCompanies": 25, "decisionMakers": true, "decisionMakerTitleKeywords": ["chief revenue", "head of sales", "vp sales"], "decisionMakersPerCompany": 2}

The free preview counted 3,344 employers with 12,279 matching postings in the last month. Each company row carries matchingJobs, the job titles, jobs30d and jobs90d for the hiring pace, and the company card. With decisionMakers on, the people who own the hire follow as rows of _type decision_maker.

A team hiring five AEs is probably shopping for sales tools too. The engineering version does the same for German companies hiring developers, with the CTO.

21. New senior hires at your target accounts. Open the task on New Hires Finder. New leaders tend to pick their vendors in the first months.

{"companyDomains": ["hubspot.com", "zendesk.com", "asana.com"], "sinceMonths": 12, "seniority": ["director", "vp", "cxo"], "maxPerCompany": 20}

Rows bring startedAt, previousCompany and previousTitle, which is the opening line of the email.

22. Former employees of a company and where they are now. Open the task on Former Employees Finder. Point it at a customer and you find champions who moved to new companies. Point it at a competitor and you find people who already know the problem. leftAfterYear keeps it recent, and each row has currentCompany, currentTitle and currentRoleStartYear.

23. New VPs of sales since last October. Open the task. People Search with currentRoleStartedAfterDate set to 2025-10. Change the titles and you have new CFOs, new heads of people, new anything.

24. Who hires for Kubernetes in Berlin. Open the task on Jobs Database API. It searches the job description, not the title, so a platform engineer posting that mentions Kubernetes counts. Today: 96 open postings at 65 employers, data through 21 October.

{"titleSearch": ["devops engineer", "platform engineer", "site reliability engineer"], "descriptionSearch": ["kubernetes"], "locationSearch": ["Berlin, Germany"], "timeRange": "30d", "removeAgency": true, "previewOnly": true}

Write the city with its country. A bare "Berlin" is refused, "Berlin, Germany" works.

You need companies, not people

25. Seed startups in Europe funded since 2025. Open the task on Company Search.

{"countryGroups": ["eu"], "hasFunding": true, "fundingRounds": ["pre_seed", "seed"], "fundedAfter": "2025-01-01", "employeesMax": 50, "previewOnly": true}

The preview counted 1,650 companies. Turn previewOnly off and each row is a company card: name, domain, headcount, industry, HQ and a funding block with the last round type and date. The Series A and B task and German manufacturers work the same way.

26. Companies like your best customers. Open the task on Lookalike Company Finder. Give it two or three customer domains in seedDomains. Every row says what it matched on in matchedOn, so you can see why a company is there instead of trusting a score.

27. Clean up a column of messy domains. Open the task on Company Enrichment by Domain. It takes https://www.notion.so/product, WWW.GONG.IO and linear.app/features as they come from a spreadsheet and returns one card per domain. When two companies claim a domain, the row says so and costs nothing instead of guessing.

You have a mess to clean

28. Qualify inbound sign-ups by email. Open the task on Reverse Email Lookup. Paste the emails from your sign-up form and get back the person, title and company with "compact": true. Now you know which trial is a VP at a real company and which is a student.

29. Where do your customer contacts work now. Open the task on Profile Lookup. Feed it the profile URLs of the people who signed your contracts. A changed companyName is either a churn risk or a new account, sometimes both.

30. A CRM export with a bit of everything. Open the task on Waterfall Lead Enrichment. Each row of the CSV can carry a different key: an email, a profile URL, a name with a company. The Actor resolves whatever is there to a profile and adds contacts with "contacts": true. For people files there is also Bulk People Enrichment.

Chains that work

One task rarely finishes the job. These are the chains I run most:

• Companies Hiring Now for the employers, then the domain column into Decision Maker Email Finder, then the profile links into Phone Number Finder for the ones worth a call.
• People Search in count mode to size the box, B2B Leads Finder to pull it, and the same input every Monday with excludeDatasets pointing at last week.
• Former Employees Finder on your best customer, then Email Finder on the profile links, and keep only work_current.
• Reverse Email Lookup on a new sign-up, Company Enrichment by Domain on the company, Decision Maker Email Finder for the person who signs.

Running them from an agent

Every Actor here is also an MCP tool. Pin the ones you need so the agent does not load the whole Store:

claude mcp add --transport http apify "https://mcp.apify.com?tools=b2bsearch/b2b-leads-finder,b2bsearch/people-database-search,b2bsearch/company-employees,b2bsearch/linkedin-to-phone" --header "Authorization: Bearer <APIFY_TOKEN>"

The task inputs above are exactly what the agent sends. Ask it to count first and to cap each call with maxResults, and it will usually do both.

FAQ

What does Try for free do? It copies the task into your Apify account with the input filled in. You run it on your own account and can change any field first.

Do I pay for misses? No. A person with no email, a domain nobody claims or a profile that was removed comes back as a free row with a _status that says why.

Does it scrape anything or need my login? No. The answers come from a database, so there are no cookies, sessions or proxies on your side.

Can I use these from the API? Yes. POST the same JSON to the Actor's run endpoint, or run the task by its id.

If the job you have is not on this list, tell me in the comments. The good ones become task number thirty-one.