Email Verification for AI Agents: MCP Integration Guide (2026)

Where agents actually need verification

Two use cases dominate production deployments. In signup screening, the agent sits behind a registration or demo-request form: it validates the address, blocks disposables, asks for a correction when the domain looks like a typo, and approves or flags the account in one pass. In CRM hygiene, a scheduled agent re-validates contacts modified since the last run, writes verification status back to the record, and reports which domains fail most — work that used to be a quarterly spreadsheet project.

Both patterns share one requirement: the agent needs structured evidence, not prose. That is exactly what the tool returns.

What the hosted server exposes

Email-Check.app serves MCP at https://api.email-check.app/mcp over Streamable HTTP — every call is a POST with a JSON-RPC 2.0 body and the header Accept: application/json, text/event-stream. Authentication uses your existing API key in the x-api-key header (create one under Account → API keys; keys are host-scoped). Two tools are listed:

Probes are opt-in through arguments: verifyMx, verifySmtp, detectName, suggestDomain, checkDomainAge, checkDomainRegistration, smtpDebug, and a per-check timeout in milliseconds (default 2000, max 10000). A latency-sensitive signup screen can run format and MX checks; a nightly hygiene job can pay for the slower SMTP probe only where the answer changes the decision. The full argument reference lives in the MCP server guide.

Client setup: three fields and you are connected

Claude Desktop, Cursor, Windsurf, and custom runtimes all speak Streamable HTTP, so the same entry works everywhere. Add it to your MCP client configuration and restart the client:

{
  "mcpServers": {
    "email-check": {
      "type": "http",
      "url": "https://api.email-check.app/mcp",
      "headers": {
        "x-api-key": "YOUR_API_KEY"
      }
    }
  }
}

Replace YOUR_API_KEY with a real key. Give each agent pipeline its own key so usage stays attributable — usage from MCP calls appears in your account usage reporting like any other API call.

Manually initializing a session shows what clients do on connect — and what your agent learns from the response:

curl -X POST 'https://api.email-check.app/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2025-06-18",
      "capabilities": {},
      "clientInfo": { "name": "signup-agent", "version": "1.0.0" }
    }
  }'

The initialize result carries server instructions that spell out the auth and billing contract: send the key on every request, each tool call costs 1 credit except account_whoami, and an HTTP 402 means the account is out of credits with a link to pricing. Well-behaved clients read this once instead of guessing.

Walking through an email_validate call

A CRM hygiene agent processes a new lead. It asks the server to validate the address with MX and SMTP probes, name detection, and typo suggestions:

curl -X POST 'https://api.email-check.app/mcp' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'x-api-key: YOUR_API_KEY' \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "email_validate",
      "arguments": {
        "email": "sarah.jordan@northwind-supply.com",
        "verifyMx": true,
        "verifySmtp": true,
        "detectName": true,
        "suggestDomain": true,
        "timeout": 5000
      }
    }
  }'

The response returns a machine-readable structuredContent object plus a text mirror:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "..." }],
    "structuredContent": {
      "email": "sarah.jordan@northwind-supply.com",
      "validFormat": true,
      "validMx": true,
      "validSmtp": true,
      "isDisposable": false,
      "isFree": false,
      "detectedName": {
        "firstName": "Sarah",
        "lastName": "Jordan",
        "confidence": 0.92
      },
      "domainSuggestion": null,
      "smtpDebug": {
        "responseCode": 250,
        "isCatchAll": false
      }
    }
  }
}

Read the evidence the way the schema intends it. validFormat is a hard verdict on syntax. validMx and validSmtp are nullable: null means the probe was not requested or could not conclude — never collapse it into a failure. isDisposable and isFree describe the provider, not the person. domainSuggestion appears when the domain looks like a common typo, and smtpDebug (opt-in) adds the SMTP response code and catch-all evidence for diagnostics.

The decision labels are yours, not the API's. A small policy function keeps them consistent across runs:

// Policy the agent applies to each email_validate result.
// Your labels, not API statuses — the API returns evidence.
function decide(record) {
  if (record.validFormat === false) return 'request_correction';
  if (record.isDisposable === true) return 'block';
  if (record.domainSuggestion?.suggested) return 'confirm_suggestion';
  if (record.validSmtp === false) return 'flag_invalid';
  if (record.validSmtp === null) return 'review_and_retry_once';
  if (record.validMx === true && record.isFree === false) return 'approve';
  return 'review';
}

// Catch HTTP 402 before parsing: it means the account is out
// of credits. Stop the batch, surface the pricing URL, and
// resume after a top-up — do not retry the same call.

Inconclusive results deserve their own handling — see the unknown-status playbook for bounded retry patterns that recover good leads without approving risky ones.

Two agent pipelines in practice

Signup screening

The agent receives each new registration, calls email_validate with verifyMx and suggestDomain, and acts on evidence: block on disposable, ask for correction on a suggested domain, approve on clean MX plus format, and hold anything inconclusive. Add checkDomainAge to flag brand-new domains for review — a strong fake-signup signal covered in the disposable detection guide.

CRM hygiene

A scheduled agent pulls contacts modified since the last run, validates each with the full probe set, and writes a verification status back to the record: verified, invalid, flagged, or needs-retry with a scheduled second pass. It closes with a summary — pass rate, domains failing most, records awaiting review — so operations sees trend, not just counts.

For lists in the tens of thousands, skip per-address agent calls entirely: the bulk CSV checker validates the same addresses as a batch job, and the agent handles only the review queue it produces.

The billing contract agents must respect

Every successful tool call consumes 1 credit; account_whoami is free and doubles as a connectivity check. Two responses need explicit handling in agent code. An HTTP 402 means the account is out of credits: stop the batch, tell the operator to top up at email-check.app/pricing, and resume after — retrying the same call cannot succeed. Schema-invalid arguments return a structured error listing the offending fields; surface that message to the operator instead of silently retrying.

Rate limits apply per key. Batch address work in modest groups with short pauses, back off on 429s, and let the very large jobs run through the bulk checker instead.

Ship it in four steps

MCP integration FAQ