@proofwire/mcp

Email, phone and IP validation for AI assistants, over the Model Context Protocol.

{
  "mcpServers": {
    "proofwire": {
      "command": "npx",
      "args": ["-y", "@proofwire/mcp"]
    }
  }
}

That much works with no account: twenty checks that read public records — MX, SPF, DMARC, DKIM, disposable domains, number formatting, datacentre ranges. Add PROOFWIRE_API_KEY to reach live mail servers and carrier networks.

Why this rather than any validator with an API

An autonomous agent is the worst possible consumer of a binary validator.

A person told an address is valid still hesitates before sending. An agent does not — that is the entire point of it. So the standard failure of every validator that answers valid-or-invalid stops being a bad row in a spreadsheet and becomes mail actually sent.

The specific failure is catch-all domains. A large minority of business mail servers accept every address you ask about, existing or not, and resolve the question of whether a particular mailbox exists into a shrug. Most validators return "valid" for those and invoice you. Your agent then writes to [email protected] because a tool said it was fine, and you find out when it bounces.

Proofwire answers in three states. unknown means the evidence does not settle it, comes with the reason, and is never billed. This server is written so a model cannot round that off into "valid": the verdict arrives as an instruction rather than a state, with the evidence that produced it.

UNKNOWN - [email protected]
INCONCLUSIVE - do not treat this as valid, and do not treat it as invalid
either. The evidence does not settle whether this email address works...

Confidence: 52%   Risk: 10/100
Charged: 0 credits - inconclusive verdicts are not billed

Evidence, and how much each signal moved the verdict:
  [syntax] Address is syntactically well formed. (+0.80)
  [mx] 1 MX record published. (+1.90)
  [smtp] Control probe: the server also accepted an address that cannot
         exist, so its acceptance carries no information. (-1.40)

The control probe is the part worth noticing. Before trusting an acceptance, the server is asked about an address that cannot exist. If that is accepted too, the acceptance of the real one means nothing, and the verdict says so.

Tools

| Tool | Needs a key | What it does | |---|---|---| | proofwire_verify_email | yes | Syntax, domain records, live mailbox probe | | proofwire_verify_phone | yes | Numbering plan, line type, live carrier query | | proofwire_verify_ip | yes | Operator, datacentre, Tor exit, from published ranges | | proofwire_free_check | no | Any of the twenty public-record checks | | proofwire_list_free_checks | no | The catalogue, with example inputs | | proofwire_account | no | Balance, plan, and what is configured |

With a key

{
  "mcpServers": {
    "proofwire": {
      "command": "npx",
      "args": ["-y", "@proofwire/mcp"],
      "env": { "PROOFWIRE_API_KEY": "pk_live_..." }
    }
  }
}

Get one at proofwire.app/signup: 100 credits, no card, no expiry. A pk_test_ key answers from fixed sandbox fixtures and is never billed, which is what makes it usable in a test suite.

What it costs

Credits, and only for answers. Inconclusive verdicts are free. Repeats inside the cache window are free. A landline is never billed for a mobile-network query it could not have been in. The response says what it charged and why, every time.

Configuration

| Variable | Default | | |---|---|---| | PROOFWIRE_API_KEY | none | Without it, free checks only | | PROOFWIRE_API_URL | https://api.proofwire.app | Point at a local API for development |

Links

• Documentation
• Published accuracy benchmark, with the dataset downloadable so you can rerun it
• Source and issues

MIT.