Add Email Verification to an AI Agent With MCP

An MCP-compatible agent does not need a custom email-verification SDK. Give the client one remote server URL, authorize one emailverifier.dev project, and it can load two narrow tools:

Server URL:     https://emailverifier.dev/mcp
Authentication: browser sign-in and project approval
Tools:          verify_email, check_domain
Cost:           one project credit per tool call

The project choice matters because usage, credit balance, and request history remain scoped to that project. Discovery calls such as initialization and tools/list do not use credits.

Create the project the agent will use

Create an emailverifier.dev account, verify the account email, and create or select a project. Its first project receives the account’s starter credits. You do not need to copy an API key for the normal browser authorization flow.

Use a separate project for an agent or environment when you want its usage and balance isolated from a production REST integration.

Add the remote MCP server

Open the MCP or connector settings in your client and add this remote server URL:

https://emailverifier.dev/mcp

Most remote-MCP clients open a browser when authorization is required. Sign in to emailverifier.dev, select the project that should pay for tool calls, review the client name, and approve access.

The Model Context Protocol’s current remote-server guide describes this URL, browser authorization, and tool-permission flow. Interface labels vary by client, so use its remote server or custom connector control rather than a local command transport.

After authorization, inspect the available tools. The list should contain only:

• verify_email, requiring one email string.
• check_domain, requiring one domain string.

Make one complete-address check

Ask the agent to verify an address and preserve the returned status, action, signals, and suggestion. A suitable instruction is:

Use verify_email for person@example.com. Return the exact status,
action, signals, and suggestion. Do not describe unknown as invalid.

The client sends one tool call equivalent to this JSON-RPC request after the MCP session is initialized:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "verify_email",
    "arguments": {
      "email": "person@example.com"
    }
  }
}

The result contains the same address evidence as the REST API:

• status: deliverable, risky, undeliverable, or unknown.
• action: allow, review, or block.
• flagged: true only for a block recommendation.
• signals: the facts behind the result, such as disposable_address, possible_typo, or verification_inconclusive.
• suggestion: a corrected address for a recognized provider typo, otherwise null.

Let downstream automation act on action. Keep status and signals in logs or the review record so a human can see why the agent chose that path.

Use the domain tool for a different job

check_domain does not inspect a complete mailbox. It classifies the provider domain and its mail routing:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "check_domain",
    "arguments": {
      "domain": "gmail.com"
    }
  }
}

Its possible values are:

Use check_domain when an agent is screening provider types or explaining domain routing. Use verify_email when the workflow will invite a specific person, update a customer record, or create a lead.

Set tool permissions and agent rules

Both tools are read-only from the agent’s perspective, but each call spends a project credit and sends the supplied address or domain to emailverifier.dev. Configure the client so tool calls require approval when the agent can receive arbitrary user input or process a large batch.

Give the agent four explicit rules:

1. Call a tool only when the address or domain is needed for the current task.
2. Do not retry automatically after authentication, credit, rate-limit, or transport failures.
3. Keep unknown and review distinct from invalid and block.
4. Do not claim identity, employment, inbox ownership, or guaranteed delivery from a verification result.

For a headless MCP host that cannot complete browser authorization, the endpoint also accepts an X-API-Key header. Keep that project key in the host’s secret store, never in prompts or a checked-in client configuration.

The MCP reference contains the current connection details and tool schemas. The result-handling guide provides the application state machine to use after the agent returns evidence.