Skip to main content
Glama

Find Email

find_email
Read-only

Costs 1 Sliq credit per verified email; a BYO-Apollo key makes the Apollo leg free. The default chain runs MoltSets first and fills its misses with Apollo, so a contact that comes back {'error': ...} has been tried by both providers and is final — report those gaps and move on rather than re-running them.

When only one provider ran — a BYO-Apollo user's default, or an explicit 'apollo' pin — the other is still untried, and the result says so. That paid lookup is the user's call: in a background run with no one to answer, report how many were missed and stop; in an interactive chat, tell them the count and offer a MoltSets backfill (1 credit/hit), re-calling with provider='moltsets' on just those contacts only after they say yes.

A contact this user already resolved in the last 24h is served from a cache, so re-calling does not look up or charge again. One entry per input contact, in input order — either a hit dict (email, email_status, name, title, linkedin_url) or an {'error': ...} miss — followed by any warnings.

Each verified email is also written for you onto the person's canonical profile (the Email column on the Output tab) and onto their prospect row in your campaigns if it had none — you do not match or persist emails back onto rows yourself.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contactsYesPeople to look up. Each must have name plus at least one of linkedin_url, company_name, or company_domain.
providerNoLeave unset (default) to let the chain pick — almost always right; don't pin a source the user didn't ask for. Set 'apollo' or 'moltsets' to pin a single source: 'apollo' runs Apollo alone (free with BYO Apollo, 1 credit/hit on Sliq's key); 'moltsets' runs MoltSets alone (1 credit per hit). Use 'moltsets' for the backfill the user approved after a run where only Apollo went out. Pinning skips the fallback, so coverage may be lower.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description directly contradicts the readOnlyHint=true annotation by stating that verified emails are 'written for you onto the person's canonical profile' and 'onto their prospect row in your campaigns.' This is a state-modifying side effect, so per rubric the score is 1 and the contradiction must be flagged. Apart from that, the description is transparent about costs, caching, and provider fallback behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loaded with the core purpose and organized into summary and returns sections. Every paragraph carries operational necessity, though some sentences are dense enough that a bit of trimming could improve readability. Overall efficient for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description fully defines the return shape, error semantics, side effects, cost model, cache behavior, and provider fallback logic. An agent has everything needed to invoke the tool correctly and interpret results, including when to stop and ask the user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: the contacts parameter's single-vs-batch usage, parallel lookup behavior, provider pinning effects, and the cache/credit implications of choosing provider or leaving it unset. These details go well beyond the schema's field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Find email addresses for one or more people.' It clearly distinguishes itself from sibling tools like find_phone_number and find_linkedin_url by the object being found, and further clarifies batch versus single lookup without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides strong operational guidance: pass single contacts as a one-entry list, batch contacts for parallel lookup, don't re-run finalized misses, and only run backfills after explicit user approval. It does not explicitly compare against alternative tools or state when to prefer find_email over apollo_enrich or other siblings, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources