ChecktheNumberBeforeYourAIVoiceAgentDialsIt

An AI voice agent will dial whatever you give it. That is the point, and it is also the problem. Hand it a list and it works the list, patiently, at a rate no human team could sustain, with no instinct at all for the number it is about to call.

A human dialer glances at a record and sometimes hesitates. That is a landline. That area code is wrong for the timezone. That one looks like a burner. The hesitation is not reliable, but it is not zero either. An agent has none of it. It calls the disconnected number with the same confidence it calls the good one, and it will call the DNC-registered cell too.

Everything below is about the check that goes in front of the dial.

What a wasted dial actually costs

Three separate costs, and only the first one is obvious.

Telephony spend and agent time. Every attempt is a call setup, a ring-out, and a slot in the concurrency budget you are paying for. Across a list that is mostly dead numbers, most of your capacity is spent producing nothing.

Connect rate, which is the metric everything else keys off. Voice agent performance is usually judged on connects and outcomes per hour. Dead numbers depress that number without telling you why, so the diagnosis lands on the script or the voice or the calling window, and you spend weeks tuning things that were never broken. A dirty list looks exactly like a bad agent.

Compliance exposure, which is the one that matters. Dialing a number on the Do Not Call registry is a violation whether a human or a machine placed the call, and automated dialing at volume is precisely the pattern that draws attention. An agent that never checks DNC status is not a faster dialer. It is a faster way to accumulate violations. Our TCPA compliance guide covers where those lines fall in more detail.

There is a fourth, quieter one: reassigned numbers. A cell that belonged to your lead last year may belong to a stranger now, and an AI agent will hold a warm, personalized conversation with the wrong person before anyone notices.

The four signals to check first

One lookup answers all four. Here is what each one changes about the dial.

Line type. Mobile, landline, VoIP, or toll-free. This decides the channel more than anything else. Texting a landline fails silently and burns the touch. A VoIP number on a consumer list is a fraud signal worth pausing on, not just a routing detail.

Carrier. The current network operator, read from network data rather than guessed from the area code prefix. Prefix guessing breaks the moment a number is ported, and it breaks permanently, because the prefix never changes after a port. If your list is old, prefix-derived carrier data on it is wrong and confidently so. Our carrier lookup guide goes deeper on why this fails the way it does.

Live reachability. Whether the handset is actually in service right now. Carrier data tells you which network the number is on. It does not tell you whether the phone exists. For that you need a query against the operator's own subscriber register, which is what an HLR lookup does. The two get used interchangeably and they answer different questions, as our reverse phone lookup and HLR explainer sets out.

DNC status. Whether the number sits on the Do Not Call registry. This is a hard stop, not a score. A phone scrub returns DNC status alongside line type and risk flags for exactly this purpose.

The 1Lookup phone validation endpoint returns line type, carrier, DNC status, and a fraud and risk score in one call, and confirms the number is real and active. That is the description an agent sees when the same check is exposed as a tool:

Validate a phone number: confirms it is real and active, and returns line type, carrier, DNC status, and a fraud/risk score. Spends 1 credit.

If your use case is inbound rather than outbound, the same data screens the caller: a phone spam check scores a number for robocall and fraud patterns before you route it to an agent at all.

Inline check or pre-scrub: pick per flow

Two placements, and the right one depends on whether the list exists before the agent runs.

Pre-scrub the list

If you are loading a campaign list, verify it on the way in. Validate every number at import, drop the dead ones, tag line type, and remove DNC hits before a single record reaches the dialer.

This should be your default for campaign dialing. It is deterministic, it happens once per number, it is auditable after the fact, and the agent never gets a chance to call something it should not have. Compliance checks in particular belong here rather than in the prompt: you do not want "did we check DNC" to be a judgment a model made on that turn.

For batches, bulk_verify takes up to 50 numbers per call and returns a per-item array with totals for succeeded and failed, so one malformed row does not cost you the other 49 results. Past that scale, loop the REST API with controlled concurrency, which our bulk phone validation guide covers including retries and cost control.

Check inline, at dial time

Some flows have no list. The agent is following up on a form submission, a number a caller just read out, or a record it pulled mid-conversation. There is nothing to pre-scrub.

Inline works because the check is fast: validation lookups answer in under 0.3 seconds, which fits inside the moment before a dial without a human noticing. Two details make it hold up in production:

• Identical lookups return from cache for 7 days. An agent working the same record across several attempts is not paying full price each time, and it gets a consistent answer rather than a flapping one.
• Both API keys and MCP tokens run under the same 1,000 requests per minute limit, so a dialer ramping up concurrency gets throttled rather than cut off.

Give the agent the tool as well

When the agent is doing the reasoning, not just executing a list, it should be able to run the check itself. That is what the 1Lookup MCP server is for: one URL, https://app.1lookup.io/api/mcp, over streamable HTTP with OAuth 2.1, exposing validate_phone, verify_email, ip_lookup, bulk_verify, and get_account inside any MCP client. No API key goes into a config file, because authorization runs through a browser consent step instead. Setup takes a couple of minutes in Claude or Cursor.

Two properties matter for a dialing workflow specifically. Every paid tool states "Spends 1 credit" in the text the model reads, so cost is visible at decision time rather than at invoice time. And get_account is free and explicitly tells the agent to call it before a large run, which is the cheapest possible guard on an agent about to work a long list.

One constraint to design around: the MCP endpoint runs with a 60 second maximum duration per request. That is fine for a check in front of a dial and wrong for anything long-running. Scrubbing 200,000 records is a job for the REST API behind your own queue, not a tool call.

What each check costs

Sizing this is simple, because there is one rate:

• Phone validation, email verification, IP lookup: 1 credit each, from your code or from an MCP tool call. There is no separate MCP fee, and both draw on the same universal credits.
• bulk_verify: 1 credit per record, up to 50 records per call, one type per call.
• get_account: free, spends no credits.

Set that against a dial. A validation call costs one credit and takes under 0.3 seconds. A call attempt costs telephony spend, a concurrency slot, and, if the number is on the DNC registry, a compliance problem. The check is cheaper than the dial in every flow we have seen, which is why it belongs in front of it.

The order to build it in

1. Scrub every list at import. Drop disconnected numbers, tag line type, remove DNC hits. Nothing reaches the dialer unchecked.
2. Treat DNC as a hard stop in code. Not a score, not a prompt instruction, not something the agent weighs. A branch that runs every time.
3. Route by line type. Mobiles can take an SMS follow-up. Landlines cannot, and an agent that assumes otherwise will silently lose the thread.
4. Add an inline check for anything not pre-scrubbed. Inbound numbers, form fills, and records the agent found itself.
5. Give the agent get_account. A free status call is the safety valve on a long autonomous run.
6. Re-verify on a schedule. Phone data decays. A list validated last quarter is not a validated list.

None of this makes an AI voice agent more persuasive. It stops a good one from spending its day on numbers that were never going to answer, and it keeps automated dialing on the right side of a rule that does not care whether a human or a machine placed the call.

If you are calling the REST API directly, start from the five-minute phone validation walkthrough. If the agent should run the check itself, set it up in Cursor or Claude. Programmatic access needs a paid plan; a 7-day trial covers testing. Create an account or compare plans against your dial volume.