Skip to main content
Glama

waterfall_phone_act

Destructive

Run the phone waterfall over a TABLE's rows, on the server — op update_rows. Nothing personal goes through this call, and nothing found comes back: name the rows and the columns once, oto reads each row, runs the same cascade as waterfall_phone and writes the find into the row.

Cheaper than one call per row: only rows whose status_column is empty are taken, and each gets found (its provider in the status comment), no_match or failed — so a row is never paid twice; call again with the same arguments until remaining is 0 (clear a status to retry that row). no_match is written only when a provider answered without finding and none failed: a row whose steps failed or never ran stays empty, its code in errors. Rows with the same inputs share ONE lookup. Up to 8 rows run in parallel; a call that runs out of time says stopped: "time_budget" and leaves the rest pending. ⚠️ The asynchronous steps (apollo, dropcontact, fullenrich, lemlist, pipecorn) are left out here — they would answer after the row is written; the one-contact tool collects them. The answer is counts plus errors: [{row_id, code}]; dry_run reads the rows, counts the lookups and returns the first one's plan, calling nothing. From a hosted agent, a step whose tool the agent may not call is skipped and its rows stay pending (tool_not_in_job, not a quota): the answer then names them (missing_tools) with the owner's one-click fix.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "op": "<op>",
      "datastore": "<datastore>",
      "inputs": "<inputs>",
      "output": "<output>",
      "status_column": "<status_column>"
    },
    "name": "waterfall_phone_act"
  }
}

Input Schema

NameRequiredDescriptionDefault
opYes`update_rows`.
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
rolesNo
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
filterNodata_rows filter grammar; `{}` = every row not yet treated.
inputsYes{input: column} — inputs are `first_name`, `last_name`, `full_name`, `domain`, `company_name`, `linkedin_url`. Map every column you have: more inputs open more (and cheaper) steps.
outputYes{field of the find: column} — `phone`, `all`, or `provider`.
_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_runNoread and plan only — nothing called, nothing written.
qualifyNo
row_idsNothe rows to run (at most 50). Exclusive with `filter`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
datastoreYesthe table, by name or number.
providersNothe steps to try, in order, for these rows (see `waterfall_phone`).
batch_sizeNorows per call with `filter` (1-50, default 25).
qualify_minNo
technologiesNo
apify_max_usdNo
status_columnYeswhere found | no_match | failed is written.
max_paid_stepsNo
people_per_rowNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and openWorld=true, but the description earns its keep beyond them: exactly what gets written into the status column and under what condition (`no_match` only when a provider answered and none failed), what is irreversibly consumed (paid steps, 'never paid twice'), concurrency (up to 8 rows), the time-budget stop (`stopped: "time_budget"`), and dry-run semantics.

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-loaded with the core action and the cost rationale before the edge cases, and every sentence carries operational content. It is dense and em-dash-chained, which makes it harder to scan than it could be, but nothing is pure filler.

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 22-parameter batch mutation with no output schema, the description supplies the return shape (counts plus `errors: [{row_id, code}]`), the idempotency/resume contract (`remaining`), the partial-failure model, and the dry-run plan. What an agent needs to call this correctly and interpret the result is present.

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 68% across 22 parameters, so the schema carries much of the burden, but the description adds real meaning the schema does not: the status_column value vocabulary and its retry semantics, the dry_run return shape, and the relationship between row selection and pending state. Several parameters (`batch_size`, `max_paid_steps`, `people_per_row`, `qualify`, `technologies`) receive no mention in the description, keeping it below a 5.

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 — 'Run the phone waterfall over a TABLE's rows, on the server — op `update_rows`' — and immediately distinguishes itself from the sibling `waterfall_phone` (one-contact) and from row-by-row calling. An agent can tell from the first two sentences what this does and how it differs from `waterfall_phone_act`-style alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('cheaper than one call per row'), explicit when-not ('the asynchronous steps … are left out here — the one-contact tool collects them'), and an explicit operating loop ('call again with the same arguments until `remaining` is 0; clear a status to retry that row'). It also names a concrete failure mode for hosted agents (`tool_not_in_job` vs quota).

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