Work Email Waterfall MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token. Get a token at https://console.apify.com/account/integrations. Read-only. Consumes Apify credits per contact submitted and per address found. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_work_emailA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusing it with another. The tool's purpose is clearly defined and distinct.
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.
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.
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.