@pipeworx/icypeas

Connect: https://pipeworx.io/mcp — every tool in the catalog, including @pipeworx/icypeas’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 work email by name + company domain/name, via Icypeas (icypeas.com). Part of the enrich-waterfall finder rotation (fleet #2860).

Tools

• icypeas_find_email(first_name?, last_name?, domain_or_company, _apiKey) — work email with Icypeas’s own certainty label.

Auth

BYO only. Pass your Icypeas API key as _apiKey (header Authorization: Bearer <key>). Enable API access and grab the key from the API section of your icypeas.com dashboard. No platform key (D4).

Data sources

• https://app.icypeas.com/api/email-search — email search.

Verification notes (fleet #2860, 2026-10-08, no vendor key held) — READ BEFORE TRUSTING THE PARSE

• Icypeas’s documented model is ASYNC: the vendor’s own docs (https://api-doc.icypeas.com/find-emails/email-discovery/) describe /email-search as enqueuing a search, with an optional webhook fired “when it is done” — implying the bare enqueue response does not itself carry the email. We hold no Icypeas key, so we could not make a real search end to end to see the actual success shape, and an unauthenticated probe cannot get past the 401.
• What IS confirmed by edge probe: the endpoint is live, and both no Authorization header and Authorization: Bearer invalidkey123 return the identical HTTP 401 {"message":"The user does not exist","error":"UserNotFoundError","status":401, "code":"user_not_found_error"} — so the header name is right and a bad key surfaces honestly (as “no such user”) rather than silently.
• The parser is defensive, not confirmed: it reads a results array at either the top level or under item.results and takes the first entry with a non-empty email. This is a best-effort shape inferred from Icypeas’s Make/n8n no-code integrations (which present single-search results inline), NOT a field-by-field confirmed response. If this pack returns found: false on every call even with a valid key, the first thing to check is whether /email-search actually hands back an item._id that must be polled via a separate results endpoint — that would mean this pack needs a second poll step added, not that the person has no email. Flagging this explicitly rather than letting a parse gap read as a mundane “not found.”
• Not verified (no key held): the exact success response shape; whether a poll step is required; the certainty field’s possible values.

Tools

• icypeas_find_email — Find a work email by first name, last name and company domain/name, via Icypeas. Icypeas runs searches asynchronously server-side; this call waits for the result rather than handing back a bare task i