uChecker MCP Server

uChecker supports the Model Context Protocol an open standard for connecting tools to AI agents. Add our MCP server to Claude Code, Cursor or any other MCP-compatible client and your agent can validate email addresses, track task progress and export clean lists, with no REST API integration code required.

Setup

Endpoint: https://api.uchecker.net/mcp (streamable HTTP). Authentication uses your API key in the x-api-key header. Find the key in your dashboard.

Claude Code (CLI):

claude mcp add --transport http uchecker https://api.uchecker.net/mcp \
  --header "x-api-key: uk_YOUR_KEY"

Cursor, VS Code and other clients (JSON config):

{
  "mcpServers": {
    "uchecker": {
      "type": "http",
      "url": "https://api.uchecker.net/mcp",
      "headers": { "x-api-key": "uk_YOUR_KEY" }
    }
  }
}

Available tools

validate_email	Validate a single email address
validate_emails	Bulk-validate a list (up to 10,000 per call)
wait_for_task	Wait until a validation task completes
get_task_status	Task status and progress
get_task_results	Paged results with good/bad filtering
get_task_analytics	Deliverability and rejection reasons
export_results	Export results (CSV, good/bad lists)
list_tasks	Task history
get_account_balance	Credits balance
get_account_stats	Account-wide statistics

Example usage

Ask your agent: “Validate the email addresses from subscribers.csv and save the valid ones to clean.txt”. The agent will call validate_emails, wait for completion via wait_for_task and export the clean list with export_results. Pricing matches the API: 1 email = 1 credit; syntactically invalid addresses are free.

Why an agent needs validation

A language model has no way to tell a real address from an invented one: john@exampel.com looks exactly as plausible as john@example.com. So an agent that collects contacts, parses correspondence or fills a CRM reliably produces rubbish, typo domains, disposable mailboxes, role addresses like info@, spam traps.

The MCP server closes that gap: the agent calls a check and gets back an SMTP verification result, the state of the MX records and a disposable-domain flag rather than a guess. From there it can decide for itself whether to store the contact or ask for clarification.

Where this gets used

Three scenarios come up more than the rest. Enriching a CRM: the agent walks fresh leads and flags the ones not worth writing to before a salesperson spends time on them. Triaging inbound requests, where the address was typed by hand and a typo in the domain means a lost customer. And preparing a campaign, where checks run in bulk and remove dead addresses before they damage sender reputation.

What a check returns

The answer is not a simple valid or invalid, because that tells an agent nothing about what to do next. What comes back is a breakdown: did the syntax check pass, does the domain have MX records, what did the mail server say to an SMTP probe of that specific mailbox, is the domain disposable or catch-all, does the address look role-based.

The distinction matters in practice. An address on a catch-all domain is confirmed by the server while the mailbox behind it may not exist, so that contact deserves a flag rather than deletion. A role address like support@ exists, but cold-mailing it is pointless. A disposable mailbox exists right now and will stop existing within the hour.

Limits worth knowing about

An SMTP check is a conversation with the recipient's mail server, so it takes time and runs into the receiving side's limits. Large providers apply greylisting and per-source rate limits, so some answers arrive late or come back as indeterminate. For an agent that means a check belongs in a background task rather than a synchronous step in a user-facing exchange.

REST API

For direct integration without MCP, use our REST API, with interactive documentation is available at api.uchecker.net/docs.