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. A hit's linkedin_url is the person's LinkedIn profile URL; a recipient or person takes it as linkedin_slug.

Each verified email is also written for you onto the person's canonical profile if it had none, which is the address every campaign tracking that person sends to and the one the Email column on the Output tab shows wherever they're on a list — you do not match or persist emails back onto rows yourself. It adds no one to an agent's list: when a person found here who isn't on it yet belongs there, record them with record_search_results.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "contacts": "<contacts>"
    },
    "name": "find_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
contactsYesPeople to look up. Each needs a name, plus either an apollo_id or at least one of linkedin_slug, 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.
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed3 schema fields changed
    • changedInput schema / properties / contacts / description
      Previous value: -"People to look up. Each needs a name, plus either an\n      apollo_id or at least one of linkedin_url, company_name, or\n      company_domain."New value: +"People to look up. Each needs a name, plus either an\n      apollo_id or at least one of linkedin_slug, company_name, or\n      company_domain."
    • addedInput schema / properties / contacts / items / properties / linkedin_slug
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The person's LinkedIn profile slug or profile URL."
      +}
    • removedInput schema / properties / contacts / items / properties / linkedin_url
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "LinkedIn profile URL"
      -}
  3. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  4. Changed3 schema fields changed
    • changedInput schema / properties / contacts / description
      Previous value: -"People to look up. Each must have name plus at least one of\n      linkedin_url, company_name, or company_domain."New value: +"People to look up. Each needs a name, plus either an\n      apollo_id or at least one of linkedin_url, company_name, or\n      company_domain."
    • changedInput schema / properties / contacts / items / description
      Previous value: -"A person to look up in Apollo."New value: +"A person to look up."
    • addedInput schema / properties / contacts / items / properties / apollo_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The `apollo_id` from an `apollo_search` people result. With it, `name` can be the result's masked name and no other field is needed: Apollo matches the person by this ID."
      +}
  5. First observed

TDQS

A4/5.0
Behavior1/5

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

The annotations declare readOnlyHint=true, but the description explicitly says verified emails are written onto the person's canonical profile. That is a persistent state change and directly contradicts the read-only annotation, so this dimension scores 1 despite otherwise rich disclosure about costs, caching, and provider fallback.

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-loads the core purpose and then covers costs, provider behavior, caching, and return semantics. Most sentences add operational value, though the density is high and could be tightened slightly.

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?

With no output schema, the description fully explains the return shape: one entry per contact in input order, hit versus error dictionaries, warnings, and the side effect on canonical profiles. It also covers costs, caching, provider fallback, and downstream recording behavior.

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. The description adds practical meaning beyond the schema by explaining that a single contact should still be passed as a one-item list, that batch contacts are looked up in parallel, and how provider pinning and backfill affect the contacts being re-called.

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 states a specific verb and resource: find email addresses for one or more people. It explicitly covers single-contact and batch usage, making its purpose distinguishable from sibling tools like find_phone_number and find_linkedin_url.

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

Usage Guidelines5/5

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

It gives explicit usage guidance: pass one contact for a single lookup, pass all contacts for parallel batch lookup, leave provider unset by default, pin only when the user asks, and handle missed provider coverage differently in background versus interactive chats.

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