AI agents are getting good at finding things. Point Claude or Cursor at a company website, ask it to find the founder's email, and it'll confidently hand you jane@acme.com. What it won't tell you is whether that address actually exists.
That's not a knowledge gap — it's an architecture gap. An LLM has no way to open an SMTP connection, check MX records, or query a disposable-domain list. It can pattern-match firstname@company.com from a scraped bio, but it has zero mechanism to confirm the mailbox is real. A model that returns a plausible-looking address with full confidence is arguably worse than one that says "I don't know" — the wrong answer looks identical to the right one until the email bounces.
This is the problem we built our MCP (Model Context Protocol) server to solve at MailValid: give an agent a tool instead of asking it to guess.
Why not just let people wrap the REST API themselves?
We already had a REST API before this. The problem is every agent framework wants tool definitions in its own shape — a function schema written for LangChain isn't what Claude Desktop expects, which isn't what Cursor expects. Anyone integrating against three agent frameworks ends up maintaining three thin wrappers around the same POST /verify call, forever, as each framework's tool-calling spec drifts.
MCP standardizes that interface once. We ship one server, and any MCP-compatible client — Claude Code, Claude Desktop, Cursor, VS Code with Copilot, Windsurf — can call it without anyone writing per-framework glue. We're one of the earlier email verification providers to ship this natively rather than leaving it to users to wrap the REST API themselves, and this post is mostly about what we learned building it, not just an announcement.
Setting it up
For clients with native remote-MCP support (Claude Code, Cursor, VS Code):
{
"mcpServers": {
"mailvalid": {
"url": "https://mailvalid.io/mcp/",
"headers": { "X-API-Key": "mv_live_your_key_here" }
}
}
}
For stdio-only clients (Claude Desktop doesn't support remote HTTP servers directly), you bridge through a local launcher instead:
{
"mcpServers": {
"mailvalid": {
"command": "npx",
"args": ["-y", "@mailvalid/mcp"],
"env": { "MAILVALID_API_KEY": "mv_live_your_key_here" }
}
}
}
One thing worth flagging for anyone building their own MCP server, not just using ours: the trailing slash on the endpoint matters. https://mailvalid.io/mcp (no slash) 307-redirects, and some MCP clients don't follow that cleanly. https://mailvalid.io/mcp/ works every time. We only caught this after a few confused bug reports — if you're shipping an MCP server, save yourself the support tickets and document the trailing slash explicitly.
What the agent can actually do once it's connected
- verify_email — full check: syntax, DNS/MX, SMTP mailbox confirmation, disposable/role/catch-all detection, confidence score
- submit_bulk_verification / get_bulk_job — queue a list, poll for results
- get_credit_balance — so an agent can check budget before running a large job
- verify_email_demo — a no-auth, no-key demo tool That last one was a deliberate decision worth explaining: we wanted agents (and developers) to be able to try the tool before committing to an API key. It's the difference between an agent evaluating verification providers by reading docs, versus actually calling a few and comparing real output. If you're building an MCP server of your own, we'd genuinely recommend shipping at least one no-auth tool — it lowers the bar for both human and agent adoption.
Here's roughly what it looks like in practice — asking Claude Code to find and verify a contact:
Me: Find the general contact email for this company and confirm it's deliverable.
Claude: I found info@example-company.com on their contact page. Let me verify it.
[calls verify_email]
Confirmed — this is a valid, deliverable address, though it's role-based (a shared inbox rather than a named person), confidence 92%.
That "role-based" flag is the part that matters most to us. Before the tool call, the agent had a plausible string. After, it has a graded fact — valid, but with a caveat a human would actually want before sending something important to it.
The broader pattern
This isn't really about email specifically, and we'd say the same thing even if it weren't our product. Any agent workflow where the agent is asserting a fact about the outside world is a candidate for an MCP tool. Lead research agents, data-cleanup pipelines, signup-abuse triage — anywhere an LLM is currently inferring instead of checking, there's probably a small, well-scoped MCP server that turns the inference into a verified answer.
MCP adoption is still early — most vendors in most categories haven't shipped a server yet. If you're weighing whether it's worth building one for your own narrow, well-defined check, our experience has been: comparatively small lift, outsized payoff. It's the difference between your product being something an agent can reach for directly, versus something a human has to remember to open a separate tab for.
Full docs for our MCP server: mailvalid.io/docs#mcp. If you're building your own MCP server for the first time, the official MCP quickstart is the best starting point regardless of what you're wrapping.
Top comments (1)
This is a strong example of replacing inference with a check. I would make the temporal and epistemic contract explicit, though: SMTP verification is not a permanent fact, and catch-all domains, greylisting, and transient server responses can produce “unknown” rather than a clean yes/no.
A useful structured result would include a status enum such as
deliverable,undeliverable,risky, orunknown; reason codes; which checks actually produced evidence;checked_at; andexpires_atorreverify_at. Then the agent can say “appeared deliverable at this time under these checks” instead of upgrading a 92% score to “confirmed forever.” Bulk workflows should preserve the per-address evidence and retry history without silently turning transient unknowns into valid addresses.