---
name: moltsets-enrich-contact
description: Use this skill whenever the user has one or more LinkedIn URLs and wants to get contact information - business email, personal email, or mobile phone.
---

# Enrich Contact

Retrieve contact data for one or many LinkedIn profiles using `MoltSets:linkedin_to_business_email`, `MoltSets:linkedin_to_personal_email`, and `MoltSets:linkedin_to_mobile_phone`.

## Triggers

"get the email for [LinkedIn URL]", "find their phone number", "enrich this profile", "enrich these profiles", "I have a list of LinkedIn URLs", "bulk enrich", "get contact info for all of these", or when a LinkedIn URL has just been confirmed via the find-person skill. Works for a single profile or up to 100 at once. Do NOT use this skill if the user does not yet have LinkedIn URLs - use find-person first.

## API rules

- **Email tools** (`linkedin_to_best_email`, `linkedin_to_business_email`, `linkedin_to_personal_email`): pass a single `linkedin_url` (string). There is no batch array - for a list, fire one call per URL, in parallel where possible.
- **Phone** (`linkedin_to_mobile_phone`): for a single profile pass `linkedin_url`; for a list pass `linkedin_urls` (array, max 100). This is the only tool that accepts a batch array. Do NOT send both.
- Credits are only charged when data is found.

## Set Expectations

Before firing any calls, give the user a brief, dry heads-up. Deadpan over enthusiastic - no filler, no corporate speak. One line is enough.

Facts to work with (scale to batch size and tools selected). Emails are one call per URL (fired in parallel); phone is a single array call:
- Single profile: 1–3 calls, a few seconds
- 2–10 profiles: up to 30 parallel calls, ~10–20 seconds
- 11–50 profiles: up to 150 parallel calls, ~20–45 seconds
- 51–100 profiles: up to 300 parallel calls, up to a minute

Always include the count and what's being fetched (email / phone / everything).

## Risk scores - confirm before enriching

Every email MoltSets returns carries a deliverability risk score - a grade from A to F. Ask which grades to keep before running anything:

> "MoltSets grades email deliverability risk from A (best) to F (no data). Which grades should I keep? I'd recommend **A, B, C and F** - and dropping **D**, since D is a confirmed bounce, complaint or spam trap."

| Grade | Meaning | Best practice |
| --- | --- | --- |
| A | Strongest engagement signal available | Safe to send immediately |
| B | Solid | Fine in regular sends; on a new or warming domain, send a smaller batch before scaling |
| C | Deliverability can't be confirmed | Segment separately from A/B, warm at low volume, watch engagement, suppress non-responders after 1-2 attempts |
| D | Confirmed bounce, complaint or spam trap | Never send - fastest way to trip spam traps and damage sender reputation for the whole list |
| F | No data - unknown risk, not "safe" | Re-verify before sending, or treat like C |

Use whatever set the user confirms. Treat the grade as a filter, not a guarantee - it lowers risk, it doesn't remove it. Pair it with the user's own sending domain reputation and list hygiene.

## Step 1 - Determine what to retrieve

| User says... | Run... |
|---|---|
| "email" (unspecified) | `linkedin_to_best_email` (hybrid - business preferred, personal fallback) |
| "business email" / "work email" / "company email" | `linkedin_to_business_email` only |
| "personal email" / "home email" | `linkedin_to_personal_email` only |
| "phone" / "mobile" / "number" | `linkedin_to_mobile_phone` only |
| "everything" / "all contact info" / no preference stated | All three: `linkedin_to_business_email` + `linkedin_to_personal_email` + `linkedin_to_mobile_phone` |

When in doubt, run all three in parallel - credits are only charged on hits.

## Step 2 - Detect singular vs. batch

**Singular (1 URL):**
- Call the relevant tool(s) with `linkedin_url`
- Present as a contact block (see format below)

**Batch (2–100 URLs):**
- Confirm count with the user before running: "I have X profiles - enriching now for [email / phone / everything]."
- For email tools, fire one call per URL (in parallel). For phone, pass the `linkedin_urls` array in a single call.
- If the list exceeds 100, tell the user the phone batch limit is 100 per call and ask how they'd like to split it
- Present results as a table (see format below)

## Accepting bulk input

Users may provide multiple URLs in various formats:
- Line-separated paste
- Comma-separated list
- Uploaded CSV (extract the LinkedIn URL column)

Parse and deduplicate before passing to the tool.

## Output formats

**Singular - contact block:**
```
Business email: jane@acmecorp.com  risk score: A (validated 2024-11-03)
Personal email: jane.smith@gmail.com  risk score: C (validated 2024-09-17)
Mobile: +1 415 555 0192
```
Show `Not found` for any field where the lookup returned nothing.

Always show the risk score next to each email, including when the grade falls outside the accepted set - flag it rather than hiding the result. Add the one-line best practice for that grade (from Step 0) when the score is C, D or F.

**Batch - table:**

| LinkedIn URL | Business Email | Risk | Personal Email | Risk | Mobile |
|---|---|---|---|---|---|
| linkedin.com/in/janesmith | jane@acmecorp.com | A | Not found | - | +1 415 555 0192 |
| linkedin.com/in/samlee | sam@oldco.com | D (held) | Not found | - | Not found |
| linkedin.com/in/johndoe | Not found | - | john@gmail.com | B | Not found |

Show the risk score on every row that has an email, including grades outside the accepted set - flag those rather than dropping them silently, so the user can see what was filtered and why.

After the table, summarise hit rates and the risk-score spread: e.g. "Found business emails for 34 of 50 profiles, phone numbers for 21. Risk scores: A 12, B 9, C 7, D 3, F 3 - 31 kept, 3 filtered."

## Edge cases

- If a URL looks malformed or is just a slug (e.g. `janesmith`), construct the full URL: `https://www.linkedin.com/in/janesmith`
- If no data is found for any field across the entire batch, tell the user and suggest verifying the URLs are correct and profiles are active
- Do not fabricate contact data - only surface what the API returns