Skip to main content
Glama

waterfall_email

Read-only

Find ONE person's professional email, trying providers in turn and stopping at the FIRST that returns one (native waterfall).

Steps (default order): hunter (name + domain) → aiark (LinkedIn URL) → apollo (LinkedIn URL, or name + domain / company) → kaspr (LinkedIn URL) → lusha (LinkedIn URL, or name + domain / company) → forager (LinkedIn URL — your own Forager key, or the shared one where this instance opens email lookups) → then the asynchronous ones: dropcontact (LinkedIn URL, or name + company / domain) → lemlist (LinkedIn URL, or name + domain) → fullenrich (LinkedIn URL, or name + domain — usually 30 s to 4 min, so often pending). A slow step is billed even when its answer comes back pending, and a pending step ENDS the cascade: nothing after it is paid. The email is NOT verified here.

Order: your steps setting on this connector's card if set (an org default, or your own override), kept as written; else the default order above, where the free steps run first, then lemlist's database on your OWN lemlist key (no credits, your own quota), then the other providers you hold your own key for, and the shared keys next. A provider with no usable key is skipped without being called. Each step uses THAT provider's key and is billed by it, exactly as a direct call of its tool — the waterfall adds no cost. A step whose inputs are missing, or whose connector is not activated for this org, is skipped too. Give every input you have. One contact per call; for a list, run it from a recipe (for_each).

Returns {found, provider, email: {email, all, status?}, attempts, order_from} — attempts says, step by step, what happened (found / no_match / skipped / failed / withheld / pending, with the code, the message and the key used); order_from says where the order came from (call / setting / default); pending gives the collect call of the asynchronous step the cascade stopped at.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "waterfall_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
domainNothe company's domain (`acme.com`; a URL is accepted).
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
dry_runNoreturn the plan (order, key per step, arguments, skips) without calling anything. `planned` is not a promise: the connector's activation for your org is only checked by the real call.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
full_nameNoalternative to first_name + last_name.
last_nameNothe person's last name.
providersNothe steps to try for THIS call, in this order — keys from the list above. Overrides your setting. Never a tool name.
first_nameNothe person's first name.
company_nameNothe company's name, when the domain is unknown.
linkedin_urlNothe person's LinkedIn profile URL.
apify_max_usdNoa cost ceiling for each Apify run of this lookup (≥ 0.50 — Apify refuses less; above your organization's ceiling per run, $25 unless its admins set another, the step is refused). Omitted = the ceiling Apify launches take by default: derived from the run's size, else the platform default ($5), and never above that ceiling.
max_paid_stepsNoat most this many PAID provider calls for this lookup (free steps don't count); the steps past it are skipped. Omitted = no limit — the default: set it when spend matters more than finding.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnlyHint annotation: discloses that slow steps are billed even when pending, that a pending step ends the cascade, that the email is not verified, that missing inputs or inactive connectors are skipped, and how order resolution works. This is exactly the cost and side-effect context an agent needs.

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?

Front-loads the core purpose and mechanism, then layers order, billing, and return details. It is long but dense; a few clauses (e.g. the repeated key/billing explanation) could be tightened without losing meaning.

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?

For a 15-parameter tool with no output schema, the description supplies the return shape (found, provider, email, attempts, order_from, pending) and the billing/skip semantics. An agent has enough to call it correctly and interpret results.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: the providers list is an ordered override of the setting, max_paid_steps excludes free steps, and apify_max_usd is a per-run ceiling. It clarifies intent beyond the schema text.

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?

States a specific verb and resource ('Find ONE person's professional email') plus the defining mechanism (native waterfall, stop at first hit). This clearly separates it from siblings like waterfall_phone, waterfall_company, and waterfall_person.

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?

Gives concrete usage context: one contact per call, use a recipe with for_each for lists, and notes the waterfall costs the same as a direct provider call. It does not explicitly say when to prefer this over a direct apollo_email or lemlist_enrich call, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources