@pipeworx/wiza

Connect: https://pipeworx.io/mcp — every tool in the catalog, including @pipeworx/wiza’s. Install: one-click buttons

No MCP client? Skip the connection: POST https://gateway.pipeworx.io/v1/tools/search_packs {"query":"..."} to find a tool below, GET /v1/tools/<name> for its schema, POST the same URL with arguments for the data — see For AI agents.

Tools: 1

Find a person’s mobile phone number from their LinkedIn profile URL, via Wiza’s individual-reveal API (wiza.co). Part of enrich-waterfall’s new enrich_find_phone finder rotation (fleet #2860).

Tools

• wiza_find_phone(profile_url, _apiKey) — starts a reveal and polls it inline (bounded ~10s across 5 polls) so the caller gets one synchronous answer instead of a bare reveal id to manage.

Auth

BYO only. Pass your Wiza API key as _apiKey (header Authorization: Bearer <key>). Find your key on your Wiza account API page. No platform key (D4).

Data sources

• https://wiza.co/api/individual_reveals — start a reveal (POST) and poll it (GET /individual_reveals/{id}), with enrichment_level: "phone".

Verification notes (fleet #2860, 2026-10-08, no vendor key held)

• Edge-probed live with an invalid key: HTTP 401 {"status":{"code":401,"message":"Invalid API key."}} — confirms the endpoint, the Authorization: Bearer header, and that a bad key fails cleanly.
• The reveal is genuinely async (Wiza’s own docs describe “0-15 seconds” typical, “~4 seconds” average) — this pack polls up to 5 times with a 2s gap inside one tool call. We hold no Wiza key, so this poll loop and its field parsing (mobile_phone/phone_number/phones[], phone_status) were never exercised against a real reveal — they are built directly from https://docs.wiza.co/using-the-api/find-mobile-phone-number (read 2026-10-08). If a real reveal returns a different field name for the number, the loop will exhaust its 5 attempts and report a pending: true not-found rather than a confirmed miss — that distinction is deliberate (see below) but depends on phone_status actually appearing as documented.
• Pending vs. confirmed-miss is a real distinction, not padding. If the 5-poll budget runs out without Wiza setting phone_status: "not_found", this pack returns { found: false, pending: true, reveal_id } rather than a flat miss, because Wiza may simply still be working — a caller (or the waterfall) can decide whether to wait longer rather than being told falsely that no phone exists.
• Not verified (no key held): the exact phone_status enum; whether phones[] can return more than one number worth preferring by type.

Tools

• wiza_find_phone — Find a person’s mobile phone number from their LinkedIn profile URL, via Wiza. Starts an individual reveal and polls it inline (bounded to ~10s) so you get one synchronous answer. Example: wiza_find_p