Skip to main content
Glama
Sign In

Tulina

by ai.tulina.mcp
OverviewDiscussionsAdmin

waterfall_phone

Read-only

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

Steps (default order): pipecorn (LinkedIn URL; its own cascade of providers, mobiles only, billed only when one is found, even when another step found too — asynchronous, waited up to 20 s within the call's time budget, then the next steps run and it is read once more at the end if time is left, else left in pending) → kaspr (LinkedIn URL) → lusha (LinkedIn URL, or name + domain / company) → forager (LinkedIn URL) → then the asynchronous ones: apollo (phone reveal, your own Apollo key; LinkedIn URL, or name + domain / company) → lemlist (LinkedIn URL, or name + domain) → dropcontact (LinkedIn URL, or name + company / 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 LinkedIn URL opens the most steps. Phone credits cost more than email credits.

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, phone: {phone, all}, 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_phone"
  }
}

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.5/5.0
Behavior5/5

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

Goes far beyond the single readOnlyHint annotation: it discloses per-provider billing rules, that a slow step is billed even when it returns `pending`, that `pending` ENDS the cascade so nothing after it is paid, that phone credits cost more than email credits, and that steps with missing inputs or unactivated connectors are skipped. It also documents the full return shape including `attempts`, `order_from` and `pending`.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in one clear sentence, but the provider-order paragraph is a dense wall of parentheticals and arrows that is hard to scan, and billing rules are restated in several places. It earns most of its length, but the structure could be far tighter.

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, multi-provider, cost-incurring tool with no output schema, the description covers cost model, key sourcing, skip conditions, order resolution, async/pending handling and the exact return object. Nothing an agent needs to call it safely and interpret the result is missing.

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 supplies vocabulary the schema references without defining — the provider step keys (pipecorn, kaspr, lusha, forager, apollo, lemlist, dropcontact, fullenrich) and their input requirements — and adds the 'give every input you have' heuristic plus what `pending` in the response means. That is real added meaning beyond the field descriptions.

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?

Opens with a specific verb+resource+scope: 'Find ONE person's phone number, trying providers in turn and stopping at the FIRST that returns one'. The phone focus plus the waterfall semantics clearly separate it from waterfall_email, waterfall_person and waterfall_company.

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 operational guidance: 'One contact per call; for a list, run it from a recipe (for_each)', 'Give every input you have', and explains that `providers` overrides the connector's saved setting while the default order applies otherwise. It does not explicitly say when to prefer waterfall_email/person instead, so routing between the sibling waterfalls is left implicit.

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

All Tulina toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources