Skip to main content
Glama
avivshafir

atdata-email-verification-mcp-server

by avivshafir
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

AtData SafeToSend MCP Server

A Model Context Protocol (MCP) server that provides email verification services using AtData's SafeToSend API. This server allows you to verify email addresses to filter out invalid and high-risk ones, resulting in higher open rates, clicks, and conversions.

https://docs.atdata.com/reference/safe-to-send

Features

  • Email Verification: Verify individual email addresses using AtData's SafeToSend API

  • Batch Verification: Verify multiple email addresses at once with summary statistics

  • Comprehensive Error Handling: Detailed error messages for different failure scenarios

  • Environment Variable Support: Secure API key management through environment variables

  • Rate Limiting Awareness: Proper handling of API rate limits

Related MCP server: email-verify

Installation

  1. Clone this repository:

git clone <repository-url>
cd atdata-mcp-server

  1. Install dependencies using uv (recommended) or pip:

# Using uv
uv sync

# Using pip
uv pip install .

Setup

Get AtData API Key

  1. Sign up for an AtData account at https://atdata.com

  2. Obtain your API key from the AtData dashboard

  3. Set up your API key as an environment variable:

export ATDATA_API_KEY="your-api-key-here"

Or create a .env file in the project root:

ATDATA_API_KEY=your-api-key-here

Usage

Running the Server

Method 1: Direct Python execution

python server.py

Method 2: Using FastMCP CLI

fastmcp run server.py

Method 3: Install for Claude Desktop

fastmcp install server.py

Using with uv

If you're using uv, you can also run the server with:

{
  "mcpServers": {
    "atdata-email-verification-mcp-server": {
      "command": "uv",
      "args": ["run", "python", "server.py"],
      "cwd": "/path/to/your/atdata-email-verification-mcp-server",
      "env": {
        "ATDATA_API_KEY": "your_api_key_here"
      }
    }
  }
}

Available Tools

1. verify_email

Verify a single email address.

Parameters:

  • email (string, required): The email address to verify

  • api_key (string, optional): AtData API key (uses environment variable if not provided)

Example:

{
    "email": "user@example.com",
    "api_key": "your-api-key"  # Optional if ATDATA_API_KEY is set
}

Response:

{
    "success": True,
    "email": "user@example.com",
    "verification_result": {
        "email": "user@example.com",
        "status": "valid",
        "deliverable": True,
        "risk_level": "low",
        # Additional verification details from AtData API
    }
}

2. batch_verify_emails

Verify multiple email addresses in batch.

Parameters:

  • emails (array of strings, required): List of email addresses to verify

  • api_key (string, optional): AtData API key (uses environment variable if not provided)

Example:

{
    "emails": ["user1@example.com", "user2@domain.com", "invalid@email"],
    "api_key": "your-api-key"  # Optional if ATDATA_API_KEY is set
}

Response:

{
    "results": [
        {
            "success": True,
            "email": "user1@example.com",
            "verification_result": { /* verification details */ }
        },
        {
            "success": True,
            "email": "user2@domain.com", 
            "verification_result": { /* verification details */ }
        },
        {
            "error": "Bad request. Please check the email format.",
            "email": "invalid@email",
            "status_code": 400
        }
    ],
    "summary": {
        "total": 3,
        "successful": 2,
        "failed": 1,
        "success_rate": 66.67
    }
}

Error Handling

The server provides comprehensive error handling for various scenarios:

  • Missing API Key: Returns error when no API key is provided

  • Authentication Errors: Handles invalid API keys (401 status)

  • Bad Requests: Handles invalid email formats (400 status)

  • Rate Limiting: Handles API rate limit exceeded (429 status)

  • Network Issues: Handles connection errors and timeouts

  • Unexpected Errors: Catches and reports any unexpected exceptions

API Documentation

This server is based on the AtData SafeToSend API. For more details about the underlying API, see:

Development

Project Structure

atdata-mcp-server/
├── src/
│   └── server.py          # Main MCP server implementation
├── pyproject.toml         # Project configuration and dependencies
├── uv.lock               # Locked dependencies
└── README.md             # This file

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

License

This project is licensed under the MIT License. See the LICENSE file for details.

Support

For issues related to:

  • This MCP Server: Open an issue in this repository

  • AtData API: Contact AtData support or check their documentation

  • FastMCP Framework: Check the FastMCP documentation

Available Tools

2 tools
batch_verify_emailsA
Verify multiple email addresses using AtData's SafeToSend API.

This tool allows you to verify multiple email addresses in batch,
processing each one individually through the SafeToSend API.

Args:
    emails: List of email addresses to verify
    api_key: AtData API key (if not provided, will try to get from ATDATA_API_KEY env var)

Returns:
    Dictionary containing:
    - results: List of verification results for each email
    - summary: Summary statistics of the batch verification
ParametersJSON Schema
NameRequiredDescriptionDefault
emailsYes
api_keyNo

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the batch processing approach and API key fallback behavior, but doesn't cover important aspects like rate limits, error handling, authentication requirements beyond the API key, or what happens if the API is unavailable. It provides basic operational context but lacks comprehensive behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and concise with zero wasted words. It opens with the core purpose, explains the batch nature, provides clear parameter documentation in a structured format, and describes the return value. Every sentence earns its place and information is front-loaded effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no annotations and no output schema, the description provides adequate coverage of inputs and basic operation but lacks details about the verification results format, error conditions, or API limitations. The return value description is helpful but doesn't fully compensate for the missing output schema, leaving the agent uncertain about the exact structure of verification results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by clearly explaining both parameters: 'emails' as 'List of email addresses to verify' and 'api_key' with its fallback behavior to environment variable. The description adds essential meaning beyond the bare schema, including the optional nature and default behavior of the api_key parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('verify multiple email addresses'), the resource ('using AtData's SafeToSend API'), and distinguishes from the sibling tool 'verify_email' by emphasizing batch processing. The phrase 'in batch, processing each one individually' explicitly differentiates it from single-email verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('verify multiple email addresses in batch'), but doesn't explicitly state when not to use it or mention the sibling 'verify_email' as an alternative for single emails. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_emailA
Verify an email address using AtData's SafeToSend API.

This tool verifies email addresses to filter out invalid and high-risk ones,
which results in higher open rates, clicks, and conversions.

Args:
    email: The email address to verify
    api_key: AtData API key (if not provided, will try to get from ATDATA_API_KEY env var)

Returns:
    Dictionary containing the verification results including:
    - email: The email address that was verified
    - status: The verification status
    - deliverable: Whether the email is deliverable
    - risk_level: Risk assessment of the email
    - additional verification details
ParametersJSON Schema
NameRequiredDescriptionDefault
emailYes
api_keyNo

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality and business purpose well, but lacks details about error handling, rate limits, authentication requirements beyond the API key parameter, or what happens when the API key isn't provided. The description doesn't contradict any annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It begins with the core purpose, adds business context, then provides clear sections for Args and Returns. Every sentence earns its place, with no redundant information or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 parameters, no annotations, and no output schema, the description does a good job covering the essentials. It explains what the tool does, provides parameter semantics, and describes the return structure. However, it could benefit from more behavioral context about error cases or performance characteristics given the lack of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for both parameters. It explains that 'email' is 'The email address to verify' and that 'api_key' is the 'AtData API key' with fallback behavior to environment variable. This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('verify an email address'), identifies the resource ('email address'), and specifies the external service ('AtData's SafeToSend API'). It distinguishes from the sibling tool 'batch_verify_emails' by being for single email verification rather than batch processing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool ('to filter out invalid and high-risk ones, which results in higher open rates, clicks, and conversions'), but doesn't explicitly mention when NOT to use it or provide detailed alternatives. The sibling tool 'batch_verify_emails' is implied as an alternative for batch operations, but not explicitly called out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: verify_email handles single email verification, while batch_verify_emails processes multiple emails in batch. There is no overlap or ambiguity between them, as each serves a specific use case within the email verification domain.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (verify_email and batch_verify_emails) that clearly indicates their function. The naming is predictable and readable, with no deviations in style or convention.

Tool Count2/5

With only 2 tools, the server feels under-scoped for a comprehensive email verification service. While the tools cover basic verification, there are likely missing operations such as checking verification status, managing API keys, or handling bulk results that would enhance completeness.

Completeness2/5

The toolset is severely incomplete for an email verification domain. It lacks essential operations like checking verification history, managing batch jobs, or providing domain-level insights. The current tools only offer basic verification without supporting common workflows or lifecycle management.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • email-verify

    Baneado98
    A
    license
    A
    quality
    B
    maintenance
    Enables real-time email verification via MCP tools, checking syntax, MX, disposable domains, and optional SMTP probe to determine deliverability with a VALID/RISKY/INVALID verdict.
    2
    31
    MIT

  • email-validator-api

    lazymac2x
    F
    license
    Not graded
    quality
    D
    maintenance
    Comprehensive email validation MCP server that checks syntax, MX records, disposable domains, role-based accounts, SPF/DKIM, typo suggestions, and risk scoring.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avivshafir/atdata-email-verification-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server