Skip to main content
Glama

waterfall_tech

Read-only

Find ONE company's tech stack, trying sources in turn and stopping at the FIRST that returns it (native waterfall) — or, with technologies, at the first that detects one of them.

Steps (default order): lemlist (domain — lemlist's company record: website and business tools, kept when lemlist scores them CONFIRMED or LIKELY; no credits, one call of the key's search quota) → dataforseo (domain — what the WEBSITE runs, from DataForSEO's index: CMS, framework, hosting, analytics, e-commerce, payment) → apify (domain — the same, by a live crawl of the site now: for a site the index has not seen) → apollo (domain — Apollo's company record: website AND business tools, ~100 names with categories) → aiark (domain — AI Ark's company record, the same kind of mix) → theirstack (domain or name — what the company's JOB POSTINGS name: CRM, ERP, data stack, internal tools; far more names, dearer, thin on small companies). The website sources give display names (Next.js), TheirStack gives slugs (next-js): matched compares them loosely.

To know whether a company uses a given tool, pass it in technologies: a source that does not detect any of them does NOT stop the cascade (the next one sees other things), and found: false means none of the sources detected it — not that the company does not use it. To read back-office tools first, call with providers=["theirstack"].

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, tech: {technologies, count, source ("website" | "vendor_database" | "job_postings"), by_category?, matched?}, 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_tech"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
domainNothe company's website 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')`.
providersNothe steps to try for THIS call, in this order — keys from the list above. Overrides your setting. Never a tool name.
company_nameNothe company's name, when the domain is unknown (TheirStack only).
technologiesNothe tools you are looking for (e.g. ["Shopify", "HubSpot"], or one comma-separated string). Omitted = the first stack found.
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.8/5.0
Behavior5/5

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

Goes well beyond the lone readOnlyHint annotation: it discloses per-provider key requirements and billing (each step billed by that provider's key, waterfall adds no cost), quota consumption (lemlist's search quota), spend controls (apify_max_usd, max_paid_steps with free steps not counted), and skip rules for missing inputs or inactive connectors. The `attempts`/`pending`/`withheld` vocabulary also tells the agent how partial and asynchronous outcomes surface.

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 behavior and return shape is spelled out at the end; every section (steps, order, technologies, returns) is clearly delineated. It is dense and long — the per-provider parentheticals could be tightened — but almost no sentence is 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?

With 12 parameters, no output schema, and minimal annotations, the description compensates fully: it names every provider and what each contributes, describes the returned object field by field (found, provider, tech, attempts, order_from, pending), and covers failure/skip semantics. An agent has enough to call it and interpret the result without opening a schema.

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; the description nonetheless adds real meaning — `found: false` means no source detected the passed technologies, not that the company lacks them, and that website sources return display names while TheirStack returns slugs so `matched` compares loosely. It could say more about how `domain` vs `company_name` interact for non-Theirstack steps.

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 and resource — "Find ONE company's tech stack" — and immediately defines the waterfall semantics (tries sources in turn, stops at the FIRST hit). It is unambiguously distinct from the other waterfall_* siblings (company, people, email, phone) by naming the resource it returns.

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?

Explicitly states when to pass `technologies` (to check a given tool), warns that a non-detecting source does not stop the cascade, and gives a concrete alternative path: `providers=["theirstack"]` for back-office tools first. It also documents the order resolution chain (call arg > connector setting > default) and skip conditions, leaving little to inference.

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