AISDRToolsAreOnlyasGoodastheContactDataTheyGet

Every AI SDR tool on the market makes the same pitch: research the account, write the message, send it, handle the reply, book the meeting, all without a human in the loop. The demos are good. The category is real.

What the demos skip is where the contact data came from. An AI SDR does not source its own list, and it has no way to tell a working inbox from a spam trap. It just sends. So the failure mode of this category is not bad copy. It is a machine sending confidently to addresses that were never checked, at a rate no human could match.

That is a data problem sitting in front of a sending problem, and it is fixable in one step.

What actually breaks

A human SDR working a rotten list finds out slowly. They send forty emails a day, watch bounces come back, and start pruning by the second morning. The feedback loop is short enough that the damage stays small.

An autonomous agent has no such loop. It sends at whatever rate you allow, and every bad address is a hard bounce. Three things go wrong at once:

Your sending domain takes the hit. Mailbox providers treat a rising hard-bounce rate as a signal that you do not know who you are emailing, which is exactly what spammers look like. The reputation damage is not confined to the campaign. It follows the domain, and it lands on the email your account executives send from that same domain.

Spam traps are invisible to the agent. A recycled or pristine trap address looks like a normal address to a language model. It will write a perfectly good personalized email to it. Traps exist specifically to catch senders who mail unverified lists.

Role-based addresses generate work, not pipeline. info@, sales@, and support@ route to shared inboxes. An AI SDR that gets a reply from one will happily start a conversation with someone who has no authority and no interest, and it will keep following up.

The pattern underneath all three: an agent's speed is only an asset once the list is clean. Before that, speed is the thing making it worse.

The three checks that matter before a send

You do not need a data warehouse. You need three answers per address, and they come from one call.

Does the mailbox exist and can it receive mail? This is deliverability, and it is the check that stops hard bounces. Everything else is secondary to it.

Is it disposable? Throwaway domains show up in bought lists and in self-serve signup exports more often than people expect. An address that expires in ten minutes is not a prospect. Our guide on detecting disposable email addresses covers how these domains behave and why a static blocklist stops working within weeks.

Is it role-based? Shared-inbox addresses should be routed differently or dropped, not sequenced.

The 1Lookup email validation endpoint returns all three in a single lookup. Its tool description, which is what an agent sees, reads:

Verify an email address: checks that it exists and is deliverable, and flags disposable, role-based, and risky addresses. Spends 1 credit.

If your AI SDR also dials, phone validation is the same shape of check: it confirms a number is real and active and returns line type, carrier, DNC status, and a fraud and risk score. Line type matters most for an agent, since texting a landline fails silently and burns the touch.

Where to put the check

There are two places, and the right answer depends on whether the list exists before the agent runs.

Option A: in the pipeline, before the agent

If you are loading a list, scrub it on the way in. Verify every address at import, drop the undeliverable ones, tag the role-based ones, and only then hand the agent a sequence to run.

This is the right default. It is deterministic, it happens once per contact, it is easy to audit, and the agent never sees an address it should not have. Nothing about it is probabilistic: the check is a line of code that runs every time, not a judgment a model made.

For large imports, bulk_verify handles up to 50 values per call and returns a per-item result array with totals for succeeded and failed, so a single malformed row does not cost you the other 49 results. For lists past that scale, loop the REST API with controlled concurrency, as covered in our bulk email validation guide.

Option B: as a tool the agent calls itself

When the agent is sourcing contacts mid-run, a pre-scrub is not possible. There is no list yet. In that case the verification has to be something the agent can call before it commits to a send.

That is what the 1Lookup MCP server is for. It is one URL, https://app.1lookup.io/api/mcp, over streamable HTTP with OAuth 2.1, and it puts five tools inside any MCP client: validate_phone, verify_email, ip_lookup, bulk_verify, and get_account. There is no API key to paste into a config file, because authorization happens in a browser consent step instead. Setup runs about two minutes in Claude or Cursor.

Two things make this work in practice rather than in theory.

The cost is in the tool description. Every paid tool says "Spends 1 credit" in the text the model reads, and get_account is free and says so, with an explicit instruction to call it before a large run. An agent that can see its own balance behaves very differently from one that cannot.

The errors tell the agent what to do. Out of credits does not come back as a 402. It comes back as "Insufficient credits. Call get_account to check the balance, or ask the account owner to top up." A rate limit returns "Rate limited. Retry shortly." That distinction is the difference between an agent that recovers and an agent that retries the same failing call until you notice.

The honest answer: do both

Scrub the list on import, and give the agent the tool anyway. The pipeline check handles the bulk cheaply. The tool handles everything the pipeline could not have known about, which for an agent sourcing its own contacts is most of it.

What it costs, and why retries matter

Pricing an agent workflow is different from pricing a human one, because an agent will retry. If a step costs money on every attempt, a confused agent in a loop is a bill.

Here is how the relevant checks are priced on 1Lookup:

• Email verification, phone validation, IP lookup: 1 credit each, whether the call comes from your code or from an MCP tool call. There is no separate MCP fee, and both paths draw on the same universal credits.
• bulk_verify: 1 credit per record.
• get_account: free, spends no credits.
• B2B contact append: 75 credits per successful match, and zero credits when no contact is found.
• Email enrichment: only charged when an email is actually found.

Note the pattern on the last two. Enrichment products bill on a match, so an agent that searches for a contact who does not exist costs nothing. That is the property you want anywhere an agent is exploring rather than executing.

Two more numbers that shape agent behavior:

• Identical lookups return from cache for 7 days. An agent that re-checks the same address inside a long session stays fast and consistent instead of paying the full lookup cost again.
• Both API keys and MCP tokens run under the same 1,000 requests per minute limit. An agent looping too fast gets throttled rather than cut off.

Wiring it up

Whichever path you pick, the order is the same:

1. Verify at the boundary. Every address entering the system gets checked once, before it can reach a sequence.
2. Drop hard bounces, tag the rest. Undeliverable is a delete. Disposable is a delete. Role-based is a routing decision, not necessarily a delete.
3. Give the agent get_account and let it check itself. A cheap status call is the safety valve on an expensive loop.
4. Keep compliance in code. DNC and consent checks should not be a judgment a model made. Put them in the pipeline. Our TCPA compliance guide covers where those lines fall for outbound dialing.
5. Re-verify periodically. Contact data decays. A list verified nine months ago is not a verified list.

None of this makes an AI SDR write better email. It stops a good one from burning the domain it sends from.

To wire it into an agent, connect Claude to 1Lookup or Cursor, or read the MCP vs API comparison if you are deciding which entry point fits your stack. Programmatic access needs a paid plan; a 7-day trial covers testing. Create an account or compare plans to size the right tier against your send volume.