F
licenseNot graded
qualityD
maintenanceComprehensive email validation MCP server that checks syntax, MX records, disposable domains, role-based accounts, SPF/DKIM, typo suggestions, and risk scoring.
-
email-verify
by Baneado98
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@email-verifyverify email jane@example.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
email-verify ✉️
Find out if an email address is real and deliverable — before you send.
email-verify is a live email-verification service shipped two ways:
an MCP server (
npx -y mailbox-verify-mcp) you plug into Claude, Cursor or any MCP agent, anda pay-per-call HTTP API gated by x402 (USDC on Base) for autonomous agents — no sign-up, no API key.
It returns a VALID / RISKY / INVALID verdict with a 0–100 deliverability score and explained reasons.
What it checks
Check | What it does |
✉️ Syntax | RFC-shaped |
📮 MX (live) | Live DNS lookup of the domain's mail servers — can it receive mail at all? Falls back to the A record (implicit MX) per RFC 5321. |
🗑️ Disposable | Embedded catalog of hundreds of throwaway / temp-mail providers (Mailinator, 10minutemail, temp-mail, Guerrilla Mail, 1secMail …), including wildcard subdomains. |
👥 Role-based | Shared function mailboxes ( |
🌐 Free provider | Flags consumer webmail (gmail/outlook/yahoo…) vs a business domain. |
🎯 SMTP mailbox (deep) | Opens a live SMTP conversation to the real mail server up to |
Everything is read-only. No email is ever sent.
Related MCP server: Email Verification MCP Server
Use it as an MCP server (free)
{
"mcpServers": {
"email-verify": { "command": "npx", "args": ["-y", "mailbox-verify-mcp"] }
}
}Tools:
verify_email— verify one address (deep: trueruns the live SMTP mailbox probe).verify_many— verify a batch (clean a list before a campaign).
Or connect over HTTP at POST /mcp.
Free HTTP API
GET https://email-verify-seven.vercel.app/verify?email=jane@example.com
GET https://email-verify-seven.vercel.app/verify?email=foo@mailinator.com # → RISKY (disposable)
GET https://email-verify-seven.vercel.app/verify?email=jane@gmial.com # → RISKY (domain typo)
GET https://email-verify-seven.vercel.app/verify_many?emails=a@x.com,b@y.comFree tier is rate-limited (30 / hour / IP) and runs every check except the live SMTP probe.
Pay-per-call (x402) — the deep tier
The /pro/* routes are gated by x402. Your agent pays $0.05 USDC per call automatically (Base); the paid tier runs the live SMTP RCPT-TO mailbox probe and lifts the batch cap to 50.
GET /pro/verify?email=<addr> # 402 → pay → deep result
GET /pro/verify_many?emails=a,b,c # up to 50 addressesSettlement goes on-chain straight to the operator wallet — the server holds no key.
A note on honesty about the SMTP probe
Many networks (including serverless egress) block outbound port 25. When the live SMTP probe can't connect, email-verify says so in the output (smtp_blocked) and degrades to MX + syntax + disposable + role signals rather than inventing a mailbox-exists result. The verdict reflects exactly what could and couldn't be confirmed.
Example output
{
"email": "jane@example.com",
"verdict": "VALID",
"score": 90,
"deliverable": true,
"reasons": [
{ "code": "has_mx", "severity": "info", "message": "Domain has 2 MX host(s); top: aspmx.example.com." },
{ "code": "smtp_accept", "severity": "info", "message": "Mailbox accepted by aspmx.example.com (SMTP 250). The inbox exists." }
],
"checks": { "syntaxValid": true, "hasMx": true, "disposable": false, "roleBased": false, "smtp": { "status": "deliverable" } }
}Why this exists
List cleaning and signup-fraud prevention are things businesses pay real money for. An LLM agent can't open a TCP socket to a mail server or carry a maintained disposable-domain catalog on its own — email-verify gives it that as one tool call.
Development
npm install
npm run dev:http # local HTTP server on :8080 (payments default ON; set X402_ENABLED=false to disable)
npm run dev:mcp # local stdio MCP server
npm run test:engine # deterministic offline testsLicense
MIT
Available Tools
2 toolsverify_emailA
Verify whether an email address is real and deliverable, live. Checks: syntax (RFC-shaped, typos like gmial.com), the domain's live MX records (can it receive mail at all), whether the domain is a known disposable/temporary provider (Mailinator, temp-mail, 10minutemail, ...), whether the local-part is a role/shared mailbox (info@, admin@, support@), whether it's a consumer free-webmail address, catch-all detection, and — when deep=true — a live SMTP RCPT-TO probe of the real mail server to confirm the specific MAILBOX exists WITHOUT sending any email. Returns a VALID / RISKY / INVALID verdict, a 0-100 deliverability score and explained reasons. Use this before adding an email to a list, accepting a signup, or sending mail you don't want to bounce.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to verify, e.g. 'jane@example.com'. | ||
| deep | No | When true, run the live SMTP RCPT-TO probe to confirm the actual mailbox exists (not just the domain). Slower; degrades gracefully if the host blocks outbound port 25. Recommended for high-stakes verification. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of transparency. It details every check (syntax, MX, disposable, role, catch-all, deep SMTP probe) and explains behaviors like 'live SMTP RCPT-TO probe' that does not send email, and graceful degradation if port 25 is blocked. No contradictions.
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 front-loaded with the main purpose in the first sentence, uses a well-organized list for the checks, and has no extraneous words. Every sentence adds value, making it highly efficient.
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 lacking an output schema, the description fully defines the return values (VERDICT, score, reasons). All parameters are covered, and the tool's complexity is addressed comprehensively. No gaps remain.
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 baseline is 3. The description adds significant value beyond the schema: it explains the 'deep' parameter in detail (live probe, slowness, graceful degradation) and provides an example email format. This elevates it above baseline.
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 starts with a clear verb+resource: 'Verify whether an email address is real and deliverable, live.' It enumerates specific checks and the verdict types, fully distinguishing it from the sibling tool 'verify_many' by focusing on 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 explicitly states when to use this tool: 'before adding an email to a list, accepting a signup, or sending mail you don't want to bounce.' It implies the sibling tool is for batch verification, but does not explicitly provide when-not-to-use or alternative scenarios, though the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_manyA
Verify a batch of email addresses at once (e.g. a whole mailing list). Returns one verdict per address. Useful to clean a list before a campaign — flagging invalid, disposable, role-based and risky addresses that would bounce or hurt deliverability.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | List of email addresses to verify. | |
| deep | No | Run the live SMTP mailbox probe on each (slower). |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool returns verdicts per address and mentions flag types. However, it lacks details on error handling, rate limits, or the effect of the 'deep' parameter beyond schema description.
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?
Two sentences, no wasted words. The first sentence states purpose and output; the second provides usage context and examples of flags.
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?
The description is incomplete regarding the output structure (what does a verdict look like?) and lacks details on error states, rate limits, or prerequisites. For a batch tool, these are important for correct agent invocation.
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%, but the description adds value by explaining the batch context, the purpose of verification (flagging risky addresses), and elaborating on the 'deep' parameter as a live SMTP probe, which is not in the schema description.
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 tool verifies a batch of email addresses (e.g., mailing list) and returns one verdict per address. It explicitly distinguishes from the single-verify sibling tool verify_email by focusing on 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 a clear use case: 'clean a list before a campaign' and describes what flags are returned (invalid, disposable, role-based, risky). It implies when not to use (single addresses) but does not explicitly exclude or mention alternatives beyond the sibling name.
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.
2 tool updates
v0.1.0- First observed
verify_email - First observed
verify_many
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
The two tools are clearly distinct: one verifies a single email address, the other verifies a batch. There is no ambiguity or overlap.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern: 'verify_email' and 'verify_many'. The naming is predictable and clear.
Tool Count4/5
Two tools is appropriate for the focused domain of email verification. While more tools could be added (e.g., domain check), the current count is reasonable for the core functionality.
Completeness5/5
The server covers both single and batch verification, which are the primary use cases for email verification. No obvious gaps in the tool surface for its stated purpose.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Verify emails and domains for routing, disposable providers, role accounts, and SMTP risk.
Emailable MCP — wraps the Emailable email verification API (emailable.com)
Verify emails — deliverability, disposable/role/free detection, MX validity, domain age.
Verify email deliverability by SMTP. Catch-all/disposable/role detection. EU-hosted, GDPR-ready.
Related MCP Servers
- FlicenseBqualityCmaintenanceAn MCP server that provides email verification, returning valid, invalid, or risky status with detailed checks and metadata. It enables verifying email addresses via a simple tool interface.3-
- FlicenseNot gradedqualityCmaintenanceProvides email verification as an MCP tool, checking format, disposable domains, and mail server availability with structured results.-
- FlicenseNot gradedqualityCmaintenanceMCP server that exposes an email verification tool, returning verdicts of valid, invalid, or risky with reasons.-