Mobile Phone Waterfall MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify token, required to run the Mobile Phone Waterfall actor. | |
| LUSHA_API_KEY | No | Optional Lusha API key used as a phone data provider. | |
| PROSPEO_API_KEY | No | Optional Prospeo API key used as a phone data provider. | |
| CONTACTOUT_API_KEY | No | Optional ContactOut API key used as a phone data provider. | |
| FULLENRICH_API_KEY | No | Optional FullEnrich API key used as a phone data provider. |
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_mobile_phoneA | Find a mobile phone number for each contact by calling the buyer's own phone data providers in order (Prospeo, Lusha, ContactOut, FullEnrich) until one returns a number. Returns one row per contact with the number in E.164 format, its line type, country, a Do Not Call flag where the provider reports one, the provider that found it, and the provider credits it spent, plus a run summary row. Provider keys are read from the PROSPEO_API_KEY, LUSHA_API_KEY, CONTACTOUT_API_KEY, and FULLENRICH_API_KEY environment variables of this server; with none set, the run completes, calls nothing, and charges nothing. A LinkedIn URL is passed to providers as an identifier and never opened. A run that does not succeed is returned as an error with its run ID. Requires an APIFY_TOKEN and consumes Apify credits per contact searched and per number found, plus the buyer's own provider credits. |
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 a single tool in the set, there is no possibility of confusing it with another tool or misselecting between overlapping purposes. The tool's purpose (waterfall phone-number lookup) is clearly stated and unambiguous.
The lone tool, find_mobile_phone, follows a clear verb_noun snake_case convention. With one tool there is no risk of inconsistent conventions, though the pattern can only be assessed trivially.
The server targets a narrow, single-purpose operation, so one tool is defensible, but the surface is thin: a single tool leaves no room for adjacent operations like checking run status, listing past runs, or validating numbers. It sits at the borderline of 'feels thin' rather than being an extreme mismatch.
The core lookup operation appears fully specified (E.164 output, line type, DNC flag, provider attribution, spend, error-with-run-ID handling). However, obvious lifecycle operations are absent: no tool to retrieve or poll a prior run's status/results and no way to inspect or configure provider order or credits, so agents hit dead ends on anything beyond a single fire-and-forget call.