A
licenseA
qualityD
maintenanceFinds and verifies business email addresses using DNS/SMTP verification and web scraping, with no external API costs.
5
16 npm
12
MIT
Work Email Waterfall MCP Server
by mambalabsdev
Run the find_work_email tool to find and verify work emails for contacts through a provider waterfall using your own API keys, with per-provider spend attribution.
Submit one or more contacts with identifiers such as full name, first/last name, company domain, company name, LinkedIn URL, or email.
Supply your own provider API keys; keys are validated for free before any paid call, bad/missing keys are dropped and reported, and no-key runs complete with unavailable capabilities explained and no charge.
Chain finder providers in your preferred order, then run verifiers after each finder that returns an address.
Set caps:
maxContacts,maxProviderUnits, and optionalmax_charge_usdto control runaway spend.Provide
providerRatesto report dollars at your negotiated rates; otherwise it reports provider units only.Get flat Clay-ready JSON: one row per contact including misses, plus a summary row with address found, provider, chain position, attempted providers, verification verdict/source, and provider units or spend.
Use
concurrencyHintas advisory pacing; actual pacing follows each endpoint’s multi-window rate limits.Note: it consumes Apify credits per contact submitted and per address found, in addition to your own provider-key spend.
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., "@Work Email Waterfall MCP ServerFind and verify work emails for this list of contacts with my provider keys"
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.
Work Email Waterfall MCP Server
MCP server for the Mamba Labs Work Email Waterfall actor on Apify.
Give it contacts and your own provider API keys. It finds a work email for each, verifies it, and tells you exactly what each provider cost you.
Tool
find_work_email
Returns one flat row per contact, misses included, plus a summary row carrying the run totals: the address found, which provider found it, its position in the chain, every provider attempted, the verification verdict and its source, and the provider units spent.
Related MCP server: Nose for Leads MCP
Bring your own keys
This is the part that makes it different from a credit-based enrichment tool. Mamba Labs supplies no provider keys, never sees your credits, and never resells them. The run spends from your accounts at your negotiated rates, which is why maxProviderUnits exists and why you should set it.
The tradeoff is honest in both directions: you keep your own pricing and your own provider relationships, and you carry your own spend. What you get back is real attribution rather than a credit count, so you can see which provider actually earned its keep.
Give it providerRates and the run reports dollars at your rate. Leave it empty and it reports units only, because your plan tier is not knowable from here and guessing it would produce a confident wrong number.
What happens to a bad key
Nothing dramatic. Every key is validated for free before any paid call. A provider with no usable key is dropped from the chain and reported, rather than failing the run or silently burning attempts. With no keys at all the run still completes, explains which capabilities were unavailable, and charges nothing.
Verification is not an afterthought
Verification runs after each finder that returns an address, not once at the end, because providers do not agree on what "found" means. An address that one provider calls a hit and a verifier calls undeliverable is a miss, and you want to know that before it reaches a sequencer.
find_work_email
Input | Type | Notes |
| object[] | One object per person. Any of |
| object | Your own keys, by provider name. Validated for free before any paid call. |
| string[] | Registry entry ids in call order. Empty means the actor's default chain. |
| string[] | Verifier entry ids in order. Empty means the actor's default. |
| integer | Hard ceiling on contacts processed. |
| integer | Run-level cap on provider credits spent from your accounts. Strongly recommended. |
| object | Map of provider or provider.endpoint to your cost per unit, so spend is reported in dollars. |
| integer | Advisory. Real pacing comes from each endpoint's own multi-window rate limits. |
| number | Optional cost cap in USD for this run. The actor stops before an item that could take its charges past this amount. |
More identifiers means a better chance of a hit. Keyed on a LinkedIn URL the top provider measured 13.7 percent against 9.3 percent on name plus domain, on the same 300 contacts in the same hour.
Setup
{
"mcpServers": {
"mamba-email-waterfall-orchestrator": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-email-waterfall-orchestrator"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Get a token at console.apify.com/account/integrations. Each call spends from your own provider accounts and consumes Apify credits per contact submitted and per address found, on top of whatever your own provider keys spend.
Pricing
Price per event on the Apify FREE plan, from the live pricing record; paid Apify plans pay less per event.
Event | Price (USD) |
Actor Start ( | 0.00005 |
Email Search Submitted ( | 0.003 |
Email Found ( | 0.02 |
Also available
This tool is also exposed by the GTM Suite umbrella server, alongside the rest of the Mamba Labs GTM actors, if you would rather run one server than many.
Built by Mamba Labs.
Available Tools
1 toolfind_work_emailFind Work EmailARead-only
Find a work email address for each contact by running a chain of finder providers on YOUR OWN provider API keys, verify each result, and return real per-provider spend attribution instead of an opaque credit count. This is bring your own key: Mamba Labs supplies no provider keys, never sees your credits, and the run spends from your accounts, so set maxProviderUnits. Supply contacts as an array of objects, each carrying any of full_name, first_name, last_name, company_domain, company_name, linkedin_url and email. More identifiers means a better chance of a hit. Supply your keys in providerKeys by provider name. Every key is validated for free before any paid call, and a provider with no usable key is dropped from the chain and reported rather than failing the run; with no keys at all the run still completes, explains what was unavailable and charges nothing. Verification runs after each finder that returns an address, not once at the end. Every contact gets a row including misses, so you can see what was attempted, and a final summary row carries the run totals and spend. Returns flat Clay-ready JSON. Requires an APIFY_TOKEN and consumes Apify credits per contact submitted and per address found, on top of whatever your own provider keys spend.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| contacts | Yes | One object per person. Each may carry full_name, first_name, last_name, company_domain, company_name, linkedin_url and email. A single contact is an array of one. | |
| maxContacts | No | Hard ceiling on how many contacts are processed. Leave empty for no ceiling. | |
| providerKeys | No | YOUR own provider API keys, keyed by provider name. Validated for free before any paid call. A provider with no usable key is dropped and reported rather than failing the run. | |
| providerOrder | No | Registry entry ids in the order you want them called. Leave empty for the actor's default order. | |
| providerRates | No | Optional map of provider or provider.endpoint to YOUR cost per unit, for example {"findymail.search_name": 0.0198}. Supply it and the run reports dollars at your rate; leave it empty and it reports units only, because your plan tier is not knowable from here. | |
| concurrencyHint | No | Advisory only. Real pacing comes from each endpoint's own documented rate limits, which are multi-window and per endpoint, so this cannot exceed them. | |
| maxProviderUnits | No | Run-level cap on the provider credits this run may consume from YOUR accounts. When it is reached the remaining contacts are skipped with a reason rather than spent on. Strongly recommended. | |
| verificationOrder | No | Verifier entry ids in order. Leave empty for the actor's default order. |
TDQS
A3.8/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses side effects (spending from user accounts, consuming Apify credits), key validation, provider drop behavior, and verification timing. However, it directly contradicts the readOnlyHint=true annotation by explicitly stating the run spends credits and consumes from your accounts, which is a meaningful side effect. This is a serious annotation contradiction.
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?
The description is a single dense paragraph but every sentence carries essential information. It avoids fluff and packs a lot of behavioral and cost-related guidance into a compact form. A bit more structure (e.g., bullet points) would improve scannability, but it remains appropriately concise for the complexity.
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?
Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It covers the BYOK model, cost implications, behavior with no keys, verification timing, output format (flat Clay-ready JSON), and per-contact/summary rows. This leaves the agent well-equipped to invoke the tool correctly.
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 description coverage is 100%, so all parameters are documented. The description adds value beyond the schema by emphasizing that more identifiers improve hit rates, explicitly instructing how to supply provider keys, and strongly recommending maxProviderUnits. This extra context elevates it above the 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 states a very specific action—find work email for each contact—and explains the method: running a chain of finder providers, verifying each result, and returning per-provider spend attribution. This clearly distinguishes the tool from any generic email finder and leaves no ambiguity about its core function.
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: it is bring-your-own-key, spends from your accounts, and recommends setting maxProviderUnits. It also states that contacts should be supplied as an array of objects with more identifiers improving hit chances. No alternatives are named because there are no sibling tools, but the when-to-use context is strong.
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 tool update
v1.0.0- First observed
find_work_email
TDQS
A4/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of confusing it with another. The tool's purpose is clearly defined and distinct.
Naming Consistency5/5
The tool name 'find_work_email' follows a clean verb_noun pattern. While consistency is trivially met with a single tool, the name is descriptive and predictable.
Tool Count3/5
A single-tool server feels thin, but for this niche operation (finding work emails via provider chaining) it may suffice. However, separate tools for key management or provider configuration would improve structure.
Completeness5/5
The tool covers the full workflow: accepting multiple contact identifiers, running providers, verifying results, handling missing keys, providing per-contact and summary rows, and returning JSON. No obvious gaps exist within its stated scope.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Find and verify B2B work emails, single or bulk. OAuth sign-in or API key; pay per verified email.
- PipecornOAuthcom.pipecorn
Search B2B companies and people, then find verified work emails and mobiles across 100+ providers.
Find and verify work emails with live SMTP checks and catch-all detection. Free 10 calls/day.
Find verified work emails from a name, company, role or LinkedIn URL, and verify emails you have.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceFinds, filters, and verifies local-business leads on demand; every returned email carries a verification receipt (verifier, verdict, timestamp). Credit-based with per-key spend budgets; 25 free validated leads at signup.MIT
Waterfall Enrichmentofficial
FlicenseNot gradedqualityBmaintenanceEnables multi-provider waterfall enrichment of B2B prospect data, combining firmographic details and verified decision-maker emails with automated fallback and deliverability filtering.8-- AlicenseAqualityAmaintenanceEnables AI agents to verify email addresses with catch-all detection, search existing contacts by company domain, and, when no API key is present, provision a human-approved subscription and retrieve the key after payment.425 npmMIT