The direct answer
Claude Code or Codex can orchestrate B2B phone lookup, but the model should not guess a number or indiscriminately scrape profiles. Start with an accepted company, a reviewed role hypothesis, the person's name, and a canonical LinkedIn profile URL used only as an identity key. Connect Leadbase's approved MCP server, submit a small batch when phone lookup is enabled for the workspace, and preserve every outcome: found, not_found, pending, or failed.
Then review three separate questions: is this the intended person, what kind of number was returned, and may your team use it for the planned country and channel? A found result is availability—not proof of current ownership, role relevance, consent, or permission to call. Measure returned coverage, confirmed accuracy, call-ready yield, right-person connections, credits, and reviewer time before expanding the workflow.
1. Define the job precisely
This Guide covers one narrow job: use Claude Code or Codex to request direct-phone data for already qualified B2B people, review the results, and decide which records may proceed to a separate calling-eligibility check. It begins after account discovery and role research. If you still need to decide which companies fit, start with the ICP account-list Guide. If you do not yet know which role matters, use the buying-committee hypothesis Guide.
Four terms must remain separate:
The agent is useful because it can apply a contract consistently, call a tool, retain structured states, and prepare exceptions for review. It is not the source of the phone data and should not be asked to invent missing values. Both Claude Code and Codex document MCP connections to external tools and data. MCP makes the operation available to the agent; it does not make the underlying result true.
2. Start with an eligibility packet, not a name list
A person should enter the lookup queue only when the team can explain why that person is being researched. Build a compact eligibility packet before the agent calls any phone tool:
- stable row ID and current pilot or batch ID;
- accepted company name, canonical domain, and the version of the account decision;
- role hypothesis, review state, and the evidence behind relevance;
- person's name and canonical
linkedin.com/in/...profile URL; - corroborating company name, company domain, title, and country when known;
- intended channel and the reviewer responsible for the next decision;
- a fresh idempotency key for a new lookup batch.
The canonical profile URL is an identity key for the data service. It is not an instruction to crawl LinkedIn. LinkedIn's current crawling terms prohibit automated crawling without express permission and require authorised crawlers to respect access and robot controls. Do not give an agent session cookies, tell it to evade access restrictions, or treat a visible profile as permission to collect every available field.
Reject or hold a row before lookup when the company decision is stale, the role is merely guessed from seniority, the profile could refer to more than one person, the person appears to have left, or the intended use has no owner. These are cheaper failures to resolve before paying for contact data.
3. Choose the right acquisition route
An agent-driven structured lookup is not always the best route. Choose based on the costly failure you need to prevent.
Do not turn this table into a universal ranking. A switchboard can outperform a direct-dial database in a market where mobile coverage is weak. A human-verified subset can be preferable when a call confirmation is a mandatory control. A large suite can be the right choice when the phone lookup is only one part of an enterprise operating model.
Leadbase is a strong fit for the narrower case in this Guide because the phone tool is not isolated from list building. The same system can help define the market, qualify the account and role, and then let Claude Code or Codex execute direct-phone lookup across the resulting people list. The bounded, metered capability and explicit states keep that end-to-end operation controlled.
4. Connect Claude Code or Codex through MCP
MCP is the connection layer between the AI client and Leadbase's tool catalogue. Configure it once using the current Leadbase MCP instructions, then verify the connection inside the client before using any customer data. The setup page contains current commands for both Claude Code and Codex; use those commands rather than copying a stale configuration from a third-party tutorial.
After connection, ask the client to list available tools and confirm that prospects.find_phone is present. The contact lookup needs mcp:write; a read-only authorization may not expose it. Do not begin a batch merely because the MCP server responds. Confirm the capability name, input requirements, live batch ceiling, output states, and current credit rule in the same environment you will test.
As documented on 9 August 2026, the MCP schema accepts one to fifty identities per request. This is the maximum payload of one low-level call, not the maximum size of a Sheet or end-to-end run. For 5,000 eligible people, the orchestrator can page the Sheet and submit at least 100 calls of 50; a lower live ceiling creates more calls. A workspace's enabled status, active phone route, available credits, rate limits, and configured agent batch-credit ceiling can impose a lower executable limit. A workspace owner or admin must enable Direct phone numbers, acknowledge lawful business use, set the ceiling, and confirm availability before the run. Listing the tool is not proof that a request can execute.
Scale from a ten-person proof to 5,000 Sheet rows
The ten-person CTA in this Guide is a proof step, not a volume ceiling. After the identity, policy, result-state, and cost rules survive that proof, keep the same contract and change only the queue size. A reliable large run has five layers:
- Page the Sheet with a deterministic order and select only rows that pass the written eligibility rule.
- Freeze the input snapshot for the next group of at most 50 people, or the lower live limit.
- Create one fresh idempotency key, submit the call, and retain its request and batch sequence.
- Write
found,not_found,pending, orfailedback to every original row without deleting failures. - Poll only pending items with the identical input and key, then resume from the next unprocessed row.
Do not call this one request. At a 50-person payload, 5,000 eligible rows create at least 100 capability calls. Duplicate or ineligible rows should be removed before that numerator, while retries and a lower live limit may increase the actual call count. The row ledger—not the number of calls—is the commercial unit you review: all eligible people should end in a visible terminal state or an explicitly reported pending state at cutoff.
Each identity requires a canonical LinkedIn profile URL. The response preserves input order and can return found, not_found, pending, or failed. A found phone currently consumes five Leadbase credits; exact replay, no-result, pending, and failed outcomes consume none under the current capability contract. Treat pricing and contracts as versioned product facts: recheck the documentation and workspace policy before every formal comparison.
For a new batch, create a fresh UUID or ULID idempotency key. If the result is pending, poll with the identical input and identical key. Do not create a new key for each poll: that can turn one operation into multiple operations and destroy your audit trail. Do not reuse the key for different identities either.
5. Give the agent a non-guessing instruction
The prompt should define eligibility, tool choice, batching, idempotency, output fields, and stop conditions. It should also say what the agent must not infer. The following prompt is deliberately strict; adapt field names to your Sheet or ledger.
This prompt does not ask the model to decide whether a phone is legally usable. It asks the model to execute a defined retrieval operation and prepare a structured review queue. Keep the eligibility rule in data fields, not only prose, so the reviewer can see why a row entered or missed the batch.
For the first run, ask the agent to show the planned row count and redacted input summary before it invokes the tool. That gives you a final check for accidental broad selection, missing country context, or repeated identities. A fully autonomous bulk run is a poor first test because a technically valid call can still process the wrong queue.
6. Plan a bounded pilot before lookup
Use five to forty accepted identities for the first operational pilot only when that number fits the workspace's confirmed credit ceiling and other live limits. Otherwise use the lower allowed batch. Do not start from an arbitrary export of every person found. Include a mixture of target countries and role types only when you will report them separately. If you mix markets but only publish one aggregate rate, a strong segment can hide a weak one.
The planning model below compares two user-defined scenarios: lookup every candidate, or qualify the account and role first. Its found rate is an assumption, not a Leadbase benchmark. Its credit calculation uses the current default of five credits per found phone, which you can change if the product contract changes.
Plan a qualification-first phone lookup workload
Estimate the lookup volume and credit exposure when an agent submits every candidate versus only people who passed account and role review.
The found rate is an assumption, not a Leadbase benchmark. Qualification may change the real found rate, and a found result can still be irrelevant, incorrect, or unusable for the intended call.
Under these assumptions, 2,000 people reach phone lookup and approximately 1,200 results are found. The scenario avoids 9,000 credits compared with submitting every candidate.
| Metric | Lookup every candidate | Qualify before lookup |
|---|---|---|
| Expected phone lookups submitted | 5,000 | 2,000 |
| Estimated found results | 3,000 | 1,200 |
| Estimated credits | 15,000 | 6,000 |
Both scenarios use the same assumed found rate and credits per found result. Only the number of people submitted changes.
Lookup-first uses every candidate person. Qualification-first multiplies candidates by the account-and-role approval rate. Expected submissions, found results, and credits retain one decimal instead of rounding between steps. One capability call contains at most 50 whole people, but a Sheet workflow can repeat bounded calls across the full queue. At 50 per call, 5,000 eligible people require at least 100 calls.
This is planning arithmetic, not measured coverage, accuracy, savings, or permission to call. Use a frozen pilot and the post-run scorecard to replace every assumption with observed counts.
The planner estimates workload; it cannot predict data accuracy, call eligibility, or connections. Use it to size the queue and review capacity. Do not publish the estimated found count as a product result.
Before execution, freeze these pilot decisions:
- the eligible countries, company segments, and role families;
- the exact person-identity fields required;
- the lookup start and end dates;
- the reviewer and the evidence allowed for identity adjudication;
- the call-eligibility owner and suppression process;
- the maximum credits and reviewer hours;
- the minimum sample needed before you will make a decision;
- the retest trigger and date.
A pilot without a fixed denominator is easy to game. Preserve every submitted identity, including no-results and failures. Removing them after the fact inflates coverage and understates cost per usable record.
7. Interpret the four lookup states correctly
The response state tells you what the operation returned, not what the world contains.
Never merge not_found and failed. They answer different questions and create different remediation work. Likewise, do not count a pending result as a found record in a time-limited pilot. Report it as unresolved at the decision date.
If a batch contains a mixture of terminal and pending items, preserve item-level states. Do not block review of valid found items while waiting indefinitely for the rest, and do not close pending rows merely to make the table add up. State the observation window in the pilot report.
8. Review identity, number type, and quality separately
The public Leadbase result schema supports an E.164-formatted number, a type of mobile, direct, work, or unknown, and a quality label of verified, likely, or unknown. Inspect the values the active route actually returns; schema-supported variety is not a claim that every route or pilot will contain every type. These fields are useful, but they are not interchangeable.
First review identity: does the returned record correspond to the intended person at the accepted company and relevant role? Use the submitted profile URL and current corroborators. A correct number for a former employee is not a correct result for the workflow.
Then review number type: a mobile number, direct work line, company work number, and unknown type create different expectations and may fall under different internal policies. Do not silently relabel an unknown number as mobile because it looks like a mobile prefix; number plans and portability complicate that inference.
Finally review quality: treat the returned label as an input to adjudication, not a guarantee. Ask what the label covers and when the supporting check occurred. “Verified” does not by itself prove present ownership, the intended person's current role, permission to call, or a right-person connection.
Use at least four review outcomes for found results:
- confirmed correct: evidence supports the intended identity and number relationship under the test definition;
- confirmed incorrect: evidence establishes the wrong person, wrong company, or wrong number relationship;
- inconclusive: the reviewer cannot confirm or disprove it within the allowed method;
- not reviewed: a found result has not yet entered adjudication and must not be counted as correct.
Confirmed accuracy should use confirmed correct divided by confirmed correct plus confirmed incorrect. Keep inconclusive results visible beside it. Counting every non-disproved result as correct rewards weak review.
9. Work a fictional batch from input to decision
The following example is fictional. It demonstrates states and decisions, not Leadbase performance.
Suppose a team has forty plausible people across twenty accepted accounts. Account and role review allows twenty-four people into phone lookup. The agent submits them in one bounded batch with a fresh idempotency key. Fourteen return found, six return not-found, two remain pending at the review cutoff, and two fail.
Review establishes nine correct identities, two incorrect identities, and three inconclusive found results. Seven of the nine correct records pass the separate country, channel, purpose, and suppression check. The team attempts six calls and reaches the intended person twice.
The correct report does not say “58% accurate” because fourteen of twenty-four returned a number. That is returned coverage: 14 / 24. Confirmed accuracy is 9 / (9 + 2). Inconclusive found share is 3 / 14. Call-ready yield is 7 / 24. Right-person connection rate among attempts is 2 / 6. Each metric answers a different operational question. Operationally unresolved work is broader: it also includes pending and not-reviewed records.
The two failed records remain failures. The pending records remain pending at the cutoff. The three inconclusive found records remain unresolved. This is less flattering than converting everything into a single “success rate,” but it tells the team which part of the workflow needs repair.
10. A found B2B number is not automatically callable
Phone availability and permitted use are separate decisions. This Guide cannot determine your lawful basis, consent position, local marketing rules, suppression obligations, or whether a particular call is appropriate. Your legal or privacy owner must define those rules for the actual country, recipient, purpose, and channel.
At minimum, the review should retain purpose, data source category, country, intended channel, suppression result, owner, and decision date. GDPR Article 5 requires lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, and accountability when personal data is processed. The official Article 5 text is a principle-level source; it does not grant permission for a specific call.
Country rules can add narrower gates. In Germany, § 7 UWG treats telephone advertising to other market participants as unreasonable harassment without at least presumed consent. Finding a business number does not establish that fact-specific presumption. In the UK, the ICO's B2B marketing guidance explains screening obligations for live calls, including TPS/CTPS and the caller's own do-not-call list, plus identification and contact-detail requirements.
These examples show why one global callable=true rule is unsafe. A good system hands a found result to a country-aware decision process. It does not infer permission from availability. Use the GDPR-aware outbound Guide for the broader operating model, then have qualified counsel review material uncertainty.
11. “Scrape leads with Claude Code” is the wrong operating contract
People search for phrases such as “scrape leads with Claude Code” or “scrape LinkedIn leads with Codex,” but the phrase combines several different jobs: discover accounts, identify roles, retrieve contact data, and activate outreach. A reliable workflow separates them.
Claude Code and Codex can call approved tools, transform authorised files, and prepare review queues. That does not authorise the agent to bypass a website's access controls, automate an authenticated session, ignore a source's terms, or collect more personal data than the purpose requires. If the source does not permit automated collection, adding an AI agent does not change the boundary.
The safer prompt is not “scrape every decision-maker and mobile number.” It is “for these accepted rows, use this approved phone-lookup capability, preserve explicit states, and stop before activation.” This is also technically better: the structured contract produces replayable inputs, bounded batches, machine-readable exceptions, and measurable cost.
12. Keep a ledger that can survive review
Download the B2B agent phone-lookup ledger. It includes fictional rows for found, not-found, pending, failed, wrong-person, and inconclusive cases. Replace the examples with your test data and retain the original denominator.
The ledger deliberately separates:
- account and role eligibility from phone availability;
- submitted identity from returned phone fields;
- lookup status from human identity and number review;
- a controlled
adjudication_outcome—confirmed correct, confirmed incorrect, inconclusive, not reviewed, or not applicable—from its underlying identity and returned-number checks; - found data from call eligibility and suppression state;
- lookup credits from reviewer minutes;
- call attempt from right-person connection.
Use one row per submitted identity and keep the stable row ID across the workflow. The idempotency key belongs to the exact lookup batch; it is not the permanent person identifier. Restrict access to returned phone fields and do not place real personal data in public examples, tickets, or prompts sent to unapproved systems.
For a formal comparison, add the provider/product/tier, test dates, and frozen acceptance definition to a separate pilot summary. Do not compare one tool's raw found rate with another tool's confirmed accuracy. Run the same identities, review method, observation window, and cost model.
13. Score the result that sales can actually use
The interactive scorecard below uses your observed counts. It checks that found, not-found, pending, and failed add up to submitted; that found equals correct plus incorrect plus inconclusive plus not reviewed; that call-eligible records do not exceed confirmed-correct records; and that connections do not exceed attempts. Use the ledger's composite adjudication_outcome as the sole source for those four found-result counts. The cost metric includes lookup credits and reviewer time, not downstream calling operations.
Score a direct-phone lookup pilot
Enter observed pilot counts to separate returned coverage, right-person accuracy, unresolved results, call eligibility, connection outcomes, and lookup-and-review cost.
The accounting value per credit is your input. Included-plan credits, marginal overage credits, reviewer time, and downstream calling cost are different economic categories.
Returned coverage is 62.5%; confirmed right-person accuracy is 85.7%. 15 records passed the separate call-eligibility review, and 7 attempts reached the right person.
| Metric | Result | Definition |
|---|---|---|
| Returned coverage | 62.5% | Found results ÷ submitted lookups |
| Confirmed right-person accuracy | 85.7% | Confirmed correct ÷ (confirmed correct + confirmed incorrect) |
| Inconclusive found share | 16% | Inconclusive found results ÷ found results |
| Call-ready yield | 37.5% | Call-eligible ÷ submitted lookups |
| Right-person connection rate | 58.3% | Right-person connections ÷ call attempts |
| Lookup-and-review pilot cost | €98.75 | Credits × credit value + review minutes ÷ 60 × hourly cost |
| Lookup-and-review cost per call-eligible record | €6.58 | Lookup-and-review pilot cost ÷ call-eligible records |
| Lookup-and-review cost per right-person connection | €14.11 | Lookup-and-review pilot cost ÷ right-person connections |
Every submitted lookup remains visible as found and reviewed, found but not reviewed, not found, pending, or failed. A found result is not treated as correct until the identity review decides it.
Coverage uses submitted lookups. Confirmed accuracy excludes inconclusive and not-reviewed results but keeps both visible separately. Call-ready yield uses every submitted lookup. Connection rate uses actual call attempts. Lookup-and-review pilot cost equals credits multiplied by the entered credit value plus reviewer minutes multiplied by the hourly cost divided by 60; it excludes calling operations and other downstream costs.
The scorecard does not establish statistical significance, data freshness, legal permission, consent, presumed consent, or vendor superiority. Retain row-level evidence and report the segment, dates, definitions, and unresolved cases beside these metrics.
Use these formulas in the written pilot report:
- returned coverage = found / submitted;
- confirmed accuracy = confirmed correct / (confirmed correct + confirmed incorrect);
- inconclusive found share = inconclusive / found;
- call-ready yield = call-eligible / submitted;
- right-person connection rate = connected / attempted;
- lookup-and-review pilot cost = consumed credits × internal credit value + reviewer hours × loaded hourly cost;
- lookup-and-review cost per call-eligible record = lookup-and-review pilot cost / call-eligible;
- lookup-and-review cost per right-person connection = lookup-and-review pilot cost / connected.
If a denominator is zero, report “not available,” not zero percent. A campaign with no attempted calls has no observed connection rate. A pilot with no confirmed-correct or confirmed-incorrect records has no confirmed accuracy. This distinction prevents missing evidence from looking like poor or perfect performance.
Break results down by country, role family, and number type only when each segment has enough observations to be interpretable. Otherwise label the view exploratory. Avoid claiming that a small pilot predicts future campaign outcomes.
14. Use failure analysis to improve the next batch
Every weak outcome should lead to a different repair:
Do not “fix” a disappointing pilot by deleting difficult rows or expanding the definition of correct. Record the failure, change one material variable, and rerun a new versioned batch. Preserve the old result so the team can see whether the intervention helped.
Set a retest trigger rather than a universal expiry promise. A new country, changed role family, material product-contract change, stale person identity, or repeated wrong-person result should create a new test. The appropriate interval depends on the volatility and cost of the decision.
Give the agent a tool contract, not a blank cheque
“Find phone numbers on the web” is an unsafe and unreproducible agent brief. Leadbase changes the job. Claude Code or Codex receives a narrow MCP capability for identified people, a bounded batch, explicit result states, replay rules, and metered found outcomes. The AI client coordinates the operation; it does not get permission to invent identities or turn a plausible number into an outbound action.
The control layer: Leadbase makes direct-phone lookup a typed operation your agent can execute and your team can audit—not an open-ended scraping task.
The commercial advantage is not an unsupported promise that Leadbase always has the most phone numbers. It is that your agent can execute the full move from a qualified people queue to direct-phone outcomes across thousands of rows, rather than explaining the process or handing you another vendor workflow. Known identity in, one explicit state per person out, and cost tied to found outcomes are the controls underneath that result. Your queue rule and human review still decide who may progress; Leadbase has no outbound-call action in this workflow.
Create a workspace and confirm phone-lookup availability if that boundary matches your workflow. Talk to sales before promising a batch if you need to confirm enablement, live ceilings, country-specific review fields, or a handoff that fits your existing system of record.
When Leadbase is not the better fit
Choose another route when the actual requirement falls outside this workflow:
- choose a human phone-verification service when a documented right-person phone check is mandatory before delivery;
- choose a mature enterprise GTM suite when native CRM governance, proprietary intent, broad integrations, procurement evidence, and central administration outweigh a focused MCP workflow;
- choose a browser extension when one researcher needs only occasional one-record reveal and does not require a repeatable agent ledger;
- use an official company switchboard or local research route when direct-phone coverage is sparse or the company-level route is more appropriate;
- do not run phone lookup at all when the account, role, purpose, or permitted-use decision is not ready.
This contrary-fit test is part of the buying decision. A focused tool is only valuable when the focused job is the real bottleneck.
What this Guide does not claim
This Guide does not claim that Leadbase has the largest database, highest coverage, best accuracy, lowest total cost, or exclusive access to MCP or direct phones. It does not claim every returned number is mobile, human-verified, currently owned by the intended person, or lawful to call. The fictional examples are not performance evidence.
It also does not claim that Claude Code or Codex independently discovers private phone data. The AI client coordinates a documented external tool. The quality of the result depends on the submitted identity, provider coverage, current product contract, review definition, observation date, and activation policy.
Facts and links in this Guide were reviewed on 9 August 2026. Recheck the MCP setup, prospects.find_phone contract, credit rule, platform terms, and country guidance before a material rollout.
Final checklist
- The account is accepted under a written and current rule.
- The role is supported by account-specific evidence.
- The canonical profile identifies the intended person.
- A fresh UUID or ULID is used for each new batch.
- Pending is polled only with identical input and key.
- Found, not-found, pending, and failed remain separate.
- Identity, number type, and quality receive separate review.
- A found number never becomes automatically call-eligible.
- Country, channel, purpose, and suppression checks have an owner.
- Coverage, confirmed accuracy, inconclusive found share, pending and not-reviewed counts, call-ready yield, connections, credits, and reviewer time are reported separately.
- Rejected and unresolved rows stay in the denominator and ledger.
- The next batch changes one documented variable and keeps the prior result.
