Since opening MoltSets up to alpha and beta users, we've watched a lot of people run email-finding workflows through Claude. The pattern that keeps showing up isn't a MoltSets problem. It's a prompting problem.
The pattern
Someone uploads a list of 300 names, or pastes in a single contact they need an email for, and gives Claude an instruction like:
"Find emails for everyone on this list."
Claude picks a tool, usually the most obvious one for the inputs it can see, runs it once per row, and reports back. Some hits, a pile of "not found" rows, done.
The problem is that "not found" from a single tool call almost never means the email doesn't exist. It means one specific lookup path came up empty. MoltSets has a dozen-plus endpoints that approach the same question from different angles: a name-and-domain lookup, a LinkedIn-keyed enrichment, a reverse lookup that confirms whether someone is genuinely unindexed, and a pattern-guessing layer that checks common address formats directly against the reverse index. Each one catches people the others miss. Stopping after the first miss and calling it done is like checking one drawer for your keys and telling someone the house doesn't have them.
We ran into this ourselves recently, on our own list, using our own tooling. Claude had a skill available that specified the full chase order, but only followed the first step of it across every row. Misses were being reported as "not found" when they were really "not found by this one lookup." Once we asked Claude to run the whole chain on the same list, on the same rows that had already been marked as misses, we got meaningfully more hits. Nothing about MoltSets changed between those two runs. What changed was how thoroughly Claude was told to search.
Why this keeps happening
Claude does what it's asked. If a prompt says "find these emails" without specifying a strategy, the model has to invent one on the spot, and it will often converge on the cheapest, most obvious path rather than the most thorough one, especially across a long list where call volume adds up. That's not a flaw so much as an underspecified instruction getting the response it deserves. The fix isn't a smarter model. It's a clearer brief.
This is exactly what good prompt engineering solves for, and it's the gap we keep seeing. People are giving Claude a task, not a method. A single instruction like "find this person's email" leaves every downstream decision, which tool to try first, what to do on a miss, when a miss is actually final, up to whatever Claude infers in the moment. On a small ad hoc lookup that's rarely a big deal. Across a spreadsheet of 300 rows, those small inferred shortcuts compound into a lot of quietly under-searched results.
What we built instead
We wrote a MoltSets skill for Claude that encodes the whole search strategy up front, so nobody has to reconstruct it in a prompt every time.
It's built around the idea that "an email for this person" can start from wildly different inputs: a full LinkedIn URL, a name and a company domain, a name and just a company name, a bare name with nothing else, or a company and a role with no name at all. The skill routes each of those starting points down the path that fits it, and every path runs the same underlying chase order until it's genuinely exhausted: check whether the identifying search already returned an email (it often does), try the direct name-and-domain lookup, fall back to LinkedIn enrichment, and only after all of that, try pattern-guessing common address formats against the confirmed domain.
Critically, the skill also tells Claude what counts as actually finished. A miss on the first tool in a chain isn't a result, it's a checkpoint. The skill spells out that Claude should keep working through the remaining steps automatically, and that if the list is large enough that running the full chain on every miss meaningfully changes the amount of work involved, that tradeoff gets surfaced to the user as a question, not decided quietly on their behalf.
That last part matters as much as the search logic itself. The point isn't just giving Claude more tools to try. It's making sure Claude doesn't get to unilaterally decide it's done trying.
The takeaway for anyone running this themselves
If you're using Claude with MoltSets to find emails, the single biggest lever you have isn't which tool gets called first. It's whether your prompt (or the skill backing it) actually specifies a complete strategy, including what "not found" is allowed to mean.
A few things worth checking in your own workflows:
- Are you telling Claude to try multiple lookup paths, or letting it pick one and stop?
- Does your prompt define when a miss is final, or is Claude inferring that on its own?
- On large lists, have you actually agreed with Claude on the thoroughness/speed tradeoff, or did it just pick one?
If the answer to any of those is "I'm not sure," that's usually where the missing hits are hiding.
Get it
The skill described here is Email Finder: Find Anyone's Email Address from a Name or LinkedIn URL. It's free in the MoltSets Skills Library, and we'll keep publishing skills like it as we move through beta.
