Skip to main content
Glama
mambalabsdev

Work Email Waterfall MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Remote

Work Email Waterfall MCP Server

npm MCP License: MIT

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: Prospector 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

contacts

object[]

One object per person. Any of full_name, first_name, last_name, company_domain, company_name, linkedin_url, email. A single contact is an array of one.

providerKeys

object

Your own keys, by provider name. Validated for free before any paid call.

providerOrder

string[]

Registry entry ids in call order. Empty means the actor's default chain.

verificationOrder

string[]

Verifier entry ids in order. Empty means the actor's default.

maxContacts

integer

Hard ceiling on contacts processed.

maxProviderUnits

integer

Run-level cap on provider credits spent from your accounts. Strongly recommended.

providerRates

object

Map of provider or provider.endpoint to your cost per unit, so spend is reported in dollars.

concurrencyHint

integer

Advisory. Real pacing comes from each endpoint's own multi-window rate limits.

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. Read-only. Consumes Apify credits per contact submitted and per address found, on top of whatever your own provider keys spend.

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 tool
find_work_emailFind Work EmailA
Read-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
NameRequiredDescriptionDefault
contactsYesOne 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.
maxContactsNoHard ceiling on how many contacts are processed. Leave empty for no ceiling.
providerKeysNoYOUR 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.
providerOrderNoRegistry entry ids in the order you want them called. Leave empty for the actor's default order.
providerRatesNoOptional 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.
concurrencyHintNoAdvisory only. Real pacing comes from each endpoint's own documented rate limits, which are multi-window and per endpoint, so this cannot exceed them.
maxProviderUnitsNoRun-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.
verificationOrderNoVerifier 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. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedfind_work_email
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
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

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

  • LeadEnrich MCP Server by carsonlabs

    LeadEnrich MCP Serverofficial

    carsonlabs
    A
    license
    A
    quality
    D
    maintenance
    Waterfall lead enrichment for AI agents. Cascades through Apollo, Clearbit, and Hunter to build the most complete lead profile in a single call.
    6
    2
    MIT

  • Prospector MCP

    JosieBot26
    A
    license
    A
    quality
    D
    maintenance
    Finds and verifies business email addresses using DNS/SMTP verification and web scraping, with no external API costs.
    5
    38
    10
    MIT

  • Nose for Leads MCP

    NoseForLeads
    A
    license
    Not graded
    quality
    B
    maintenance
    Finds, 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

  • Email Finder API

    Br0ski777
    A
    license
    Not graded
    quality
    B
    maintenance
    Find professional email addresses from name + company domain. Tests 15+ patterns against MX records with confidence scoring, with pay-per-call via x402.
    MIT

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/mambalabsdev/mcp-email-waterfall-orchestrator'

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