@pipeworx/prospeo

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

Tools

• prospeo_find_email(first_name, last_name, domain, company_name?, _apiKey) — returns the verified email only when Prospeo actually reveals it; a masked/unrevealed guess is reported as not found.

Auth

BYO only. Pass your Prospeo API key as _apiKey. Get one at https://app.prospeo.io/api. No platform key — PII vendors are never platform-keyed (Bruce default D4).

Data sources

• https://api.prospeo.io/enrich-person — person enrichment, used for email finding.

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

• The old /email-finder endpoint is DEAD. Edge-probed live: HTTP 400 {"req_status":false,"error_code":"DEPRECATED","error_toast":"...migrate by using our new APIs: https://prospeo.io/api-docs"}. Several third-party write-ups (Apify, Pipedream, a glama.ai MCP server) still document this path — do not copy them. The live replacement is POST /enrich-person, used here.
• Auth header confirmed live. X-KEY: <key> per https://prospeo.io/api-docs/authentication. Edge-probed with no key: HTTP 400 {"error":true,"error_code":"INVALID_API_KEY"} on the real /enrich-person endpoint — confirms the header name and that the endpoint is live and auth-gated. This pack’s refusal message says “Prospeo requires an API key… get one at app.prospeo.io/api.”
• Response shape is from vendor docs only (https://prospeo.io/api-docs/enrich-person, read 2026-10-08) — we hold no Prospeo key, so no live successful call was made. The documented example:

  { "error": false, "free_enrichment": false,
    "person": { "person_id": "...", "first_name": "Eoghan", "last_name": "Mccabe",
      "email": { "status": "VERIFIED", "revealed": true, "email": "eoghan.*****@intercom.com" } },
    "company": { "company_id": "...", "name": "Intercom" } }

  Note the doc’s own example masks the address (eoghan.*****@intercom.com) even with revealed: true — this pack’s parser only accepts an email string that does NOT contain *, so a masked/teaser address from a live call will correctly fall through to found: false rather than being handed back as a usable contact. This is the one thing a live key would need to confirm: whether a fully-paid reveal always returns the full address un-masked. Flagged as not verified below.
• Not verified (no key held): whether a successful paid call returns the address unmasked; exact behaviour of only_verified_email: true when Prospeo has only a guessed (unverified) address.

Tools

• prospeo_find_email — Find a person’s verified work email by first name, last name and company domain, via Prospeo’s person-enrichment API. Returns the email only when Prospeo actually reveals and verifies it — a masked/un