Skip to main content
Glama
mambalabsdev

Work Email Waterfall MCP Server

by mambalabsdev

Find Work Email

find_work_email
Read-only

Find and verify work emails for each contact by running a chain of your own provider API keys, with per-provider spend reporting.

Instructions

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.

Input Schema

TableJSON 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.
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.

Install Server

Other Tools

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