Skip to main content
Glama
Sign In
Email Verifier MCP Server

Email Verifier MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Email Verifier MCP Server

Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs Email Verifier actor on Apify. Give it a list of email addresses and it checks each one with the verification service you already pay for: ZeroBounce, NeverBounce, MillionVerifier, BounceBan, or Reoon Email Verifier. You supply the service key.

What's Inside

Related MCP server: send-guard

What it does

  • One flat row per address: verdict (valid, invalid, catch_all, risky, or unknown), the service's own provider_status and provider_sub_status, is_role, is_free_email, is_disposable, and did_you_mean for a spelling fix.

  • One layout for every service: the five services spell their answers differently; every row uses the same five verdicts and the same columns.

  • Credits protected: an address with broken syntax is never sent, a repeat is checked once, and a rejected key or an empty service balance stops the run from sending more.

Bad input returns one free row whose error_reason starts with input_invalid:. With no key set, the tool refuses before any run starts, so nothing is charged.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer, an Apify account with an API token, and an API key for one of the five services.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-email-verifier": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-email-verifier"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token",
        "EMAIL_VERIFIER_API_KEY": "your-verification-service-key"
      }
    }
  }
}

Restart the client. The verify_emails tool appears.

Prerequisites

  • Node.js 18 or newer.

  • An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.

  • Your own API key for ZeroBounce, NeverBounce, MillionVerifier, BounceBan, or Reoon Email Verifier, set as EMAIL_VERIFIER_API_KEY.

Example prompts

  • "Verify these 40 addresses with my NeverBounce key and list the ones that are not valid."

  • "Which of these leads are catch all or role addresses?"

  • "Check jane@example.com and tell me if the domain looks like a typo."

Tool

verify_emails. One tool. Example arguments:

{
  "emails": [
    "jane@example.com",
    "sales@example.org"
  ],
  "provider": "neverbounce"
}

Inputs

Every buyer facing input of the actor except api_key, which comes from EMAIL_VERIFIER_API_KEY in the server environment so it never passes through the conversation. Omitted inputs take the actor's own defaults. Numbers are sent as strings.

Input

Type

Description

emails

array

Required. The addresses to verify, 1 to 5,000 per run

email

string

One more address, added to emails

provider

string

zerobounce (default), neverbounce, millionverifier, bounceban, or reoon. The service your key belongs to

concurrency

string

Addresses checked at the same time, 1 to 20. Default 5

max_charge_usd

string

Optional. The run stops before an actor charge that would pass this amount

Pricing

Two separate bills. Your verification service bills each check to your account there, at your plan's price. The actor charges per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

email-verified, one address your service answered valid, invalid, catch all, or risky

$0.0016

$0.00152

$0.00144

$0.00136

apify-actor-start, per run start

$0.0006

$0.0006

$0.0006

$0.0006

Unknown answers, error rows, addresses with broken syntax, repeats in the same run, and refused input are free. Mamba Labs pays the Apify platform costs of the run.

Your key

The key is read from this server's environment and passed in the run input as a secret field. The actor sends it only to the service you chose and never logs, stores, or returns it. Apify blocks the outbound mail port, so every mailbox check runs at your service.

Full actor documentation

apify.com/mambalabs/email-verifier

License

MIT. See LICENSE.

Available Tools

1 tool
verify_emailsVerify email addresses on your own verification keyA
Read-only

Check whether email addresses will deliver, using the caller's own ZeroBounce, NeverBounce, MillionVerifier, BounceBan, or Reoon account. Give emails (1 to 5,000 addresses) and provider (zerobounce by default). The service API key is read from this server's environment (EMAIL_VERIFIER_API_KEY), never from the tool arguments, and the service bills each check to the key owner. Returns one flat row per address: verdict (valid, invalid, catch_all, risky, or unknown), provider_status, provider_sub_status, is_role, is_free_email, is_disposable, did_you_mean, row_status, and error_reason. Addresses with broken syntax are not sent; repeats are checked once. If the key is missing the call is refused before any run starts. Bad input returns one free row whose error_reason starts with input_invalid. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per address the service answered valid, invalid, catch all, or risky.

NameRequiredDescriptionDefault
emailNoOne more address, added to emails.
emailsYesThe addresses to verify, 1 to 5,000 per run. A repeat of an address is verified and charged once.
providerNoThe service the key in EMAIL_VERIFIER_API_KEY belongs to: zerobounce, neverbounce, millionverifier, bounceban, or reoon. Default zerobounce.
concurrencyNoHow many addresses are checked at the same time, 1 to 20. Default 5. Lower it if the service plan has a tight rate limit.
max_charge_usdNoOptional. The run stops before an actor charge that would pass this amount. The verification service bills separately.

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations: discloses who is billed (the key owner, per answered address, plus Apify charges), that broken-syntax addresses are skipped and repeats checked once, that a missing key refuses the call before any run, that bad input returns one free row with an input_invalid error_reason, and that failed runs return an error with a run ID. That is unusually complete operational context for a read-only tool.

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

Conciseness4/5

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

Front-loaded with purpose, then input shape, then billing/security, then return fields, then failure modes — a sensible ordering with dense, non-repetitive sentences. Slightly long as a single paragraph and 'Read-only' restates the annotation, but nothing is filler.

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

Completeness5/5

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

Despite having no output schema, the description enumerates the returned row fields and the two error shapes (free input_invalid row vs. error with run ID), and it covers billing, auth prerequisites, and dedupe. An agent has everything needed to call it and interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema does not: the API key is never a tool argument, repeats are billed once, and malformed addresses never reach the provider. These details directly affect how an agent should shape its input.

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?

States a specific verb and resource ('Check whether email addresses will deliver') plus the exact mechanism: the caller's own ZeroBounce/NeverBounce/MillionVerifier/BounceBan/Reoon account. An agent knows precisely what the tool does and whose account is used, with no sibling tools to confuse it with.

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?

Gives concrete invocation context: pass 1 to 5,000 addresses, provider defaults to zerobounce, and the API key comes from the server environment rather than arguments. It also states prerequisites (APIFY_TOKEN, EMAIL_VERIFIER_API_KEY) and what happens if the key is missing. No alternatives exist to route against, so no exclusions are needed.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedverify_emails
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 1 tool

Disambiguation5/5

There is only one tool, so there is no possibility of misselection or overlap. Its purpose (batch-verify email addresses via a chosen provider) is unambiguous and fully described.

Naming Consistency5/5

The single tool follows a clear snake_case verb_noun pattern (verify_emails), which matches the naming conventions an agent would expect. There is no mixing of conventions to penalize.

Tool Count4/5

A single batch tool (1 to 5,000 addresses) is a sensible, well-scoped surface for a narrow email-verification service. It is slightly thin in that there is no separate lightweight single-address or account-info entry point, but nothing is redundant.

Completeness4/5

The core operation—verifying addresses and returning rich per-row verdicts—is fully covered, and input validation, deduplication, and error reporting are handled within the tool. Minor gaps exist: no way to check provider account credits/API key validity or list supported providers before spending money, which agents can only work around by trial.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • send-guard

    askeleven
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables agents to verify an email list before sending, returning a pass/fail plus keep, remove, and review categories with reasons. It exposes check_emails and check_file tools over stdio, with optional Analyzemail mailbox verification.
    23 npm
    2
    MIT

  • NoBounce Email Validation MCP

    notprathap
    A
    license
    A
    quality
    B
    maintenance
    Enables AI assistants to verify single email addresses and bulk lists of up to 1,000 addresses in real time, checking RFC 5322 syntax, DNS MX records, disposable providers, role accounts, and typos, with an optional deep SMTP mailbox handshake. Bulk runs handle partial-quota situations gracefully.
    2
    MIT
  • Analyzemail MCP Server

    Analyzemail MCP Serverofficial

    analyzemail
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables an AI agent to verify a single email address in real time, clean an entire uploaded list file with per-address verdicts, and download the results as CSV with the addresses that are safe to send to. It runs on npm with zero dependencies and includes built-in credit reporting and spending limits so agents cannot overspend without approval.
    31 npm
    MIT