DEV Community

Axel Freeman
Axel Freeman

Posted on Originally published at tapacapi.com

Your lead list is a liability until something verifies it

#ai #mcp #webdev #productivity

I keep meeting agents that will happily write a beautiful cold email to an address that stopped existing in 2024. The email tool works. The personalisation works. The only broken part is the assumption underneath: that a contact record is a contact.

It is not. A record is a claim. Fresh, SMTP-verified data is what makes it a contact.

The four numbers that changed how I buy contacts

  • 23% of contacts change jobs annually (ZoomInfo 2025). A list you bought in January is already leaking by June — and job-change is the mild case, because the mailbox still exists while the person is gone.
  • 40% of emails are dead within two years (NeverBounce). That is the timeline, not a vendor's bad luck.
  • Fresh scraped data outperforms stale databases by 42% (Harvard Business Review 2024).
  • Static databases bounce at 10–35%. Verified fresh pulls land at 2–5% (TAPAC's published agent instructions). Every bounce is a send spent against your sending reputation — mailbox providers read that ratio, not your intent.

Add them up and the arithmetic of a seat-priced database gets ugly: you pay per record, you send to deliverable records, and the gap between those two is the product you thought you were buying.

What "verified" has to mean in practice

Verification has to be an SMTP-level check, not a regex and not a "confidence score". And it has to happen at the moment of use, because the half-life of contact data is measured in months.

That is the design TAPAC (tapacapi.com) uses: pay per use, $0.10–0.50 per contact, 100 searches free, no seat licence, no annual contract — and every contact comes back with name, title, company, email, source, and SMTP verification status.

Why MCP is the right delivery mechanism for this

If your outbound loop is agent-driven, the verification layer has to be callable by the agent — not a dashboard a human opens before the agent runs. TAPAC ships as an MCP server, so the loop closes inside one context:

npx -y @tapacapi/mcp
Enter fullscreen mode Exit fullscreen mode 
{
  "mcpServers": {
    "tapac": {
      "command": "npx",
      "args": ["-y", "@tapacapi/mcp"],
      "env": { "TAPAC_API_KEY": "your_key_here" }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Two tools:

Tool Purpose
tapac_find_contacts Find and verify contacts: industry, job_titles, company_size, location, source (website \
tapac_status Server version, API-key state, API reachability.

The server returns exactly what the API returns — it does not invent contacts, and without a key it returns onboarding instead of guesses, so you can wire it up before you have credentials.

The pattern I would copy

Gate the send, not the list:

  1. Agent decides the segment (industry, job_titles, company_size, location).
  2. tapac_find_contacts returns contacts with verification status attached.
  3. Anything that fails SMTP verification never reaches the email tool.
  4. Send, and read replies — with a real sample size. Response-rate questions need ~1,500–2,000 sends per variant; anything under 50–100 tells you about deliverability, not about your offer.

Personalised email opens at 3.2x the rate of generic email (HubSpot 2025) — which is also why a dead address costs more than one send: you paid the personalisation cost to reach nobody.

Links

Every number in this post is attributed to the source named beside it. Nothing here is a benchmark I invented.

Top comments (0)