Skip to main content
Glama

Find a person's verified email

enrich
Destructive

Find a person's verified work email and profile (title, company, linkedin, location). Accepts email, linkedin_url, or name plus company_domain. Fresh results are cached per workspace; repeats are served from cache. Costs credits on hit only. The address it returns already carries its check: contact.email_verdict, in verify_email's status words (null only when the check couldn't finish). Call verify_email only for an address you got elsewhere, or one whose email_verdict is null. want: ["mobile_phone"] also looks for a mobile number: 17 credits when a separate mobile search finds it, 5 when it comes with the email, nothing when none is found. budget_credits is a spend ceiling, never permission to use a dearer source: the same ceiling as max_credits (send one); above it, the call is refused before anything is reserved. dry_run: true returns the plan instead (the most the call can cost, how many sources could answer, and each limit it would trip) with nothing looked up, reserved or charged. route picks how sources are chosen: balanced (the default), cheapest, broadest or fastest. The price is the same whichever you pick, and the answer's layrcake.route says which route was used and whether it came from the request, this key's default or the default.

Input Schema

NameRequiredDescriptionDefault
wantNoWhat to look up. work_email and profile run the email lookup (5 credits on a hit), which returns a mobile number too when its source has one. mobile_phone also runs a separate mobile search when the email lookup found none: 17 credits when that search finds one, 5 when the mobile came with the email, nothing when no mobile is found; a mobile_phone-only request that finds only an email is free and returns nothing. Where this isn't applied for your key yet, every call runs the same email lookup whatever this lists.
routeNoSource preference for this call: balanced (the default), cheapest (the lowest-cost sources), broadest (the sources expected to find the most) or fastest. The price doesn't change with it. Where route choice isn't available to this key yet, only balanced is accepted.
personYes
dry_runNoReturn this call's plan instead of running it, as of evaluated_at: the most it can cost, how many sources could answer, what budget_credits changes, and every limit the real call would trip. Nothing is looked up, reserved or charged, and a later call may differ. Where previews aren't available to this key yet, a request that sets it is refused with the reason.
max_creditsNoSpend ceiling for this call, in credits. If the most the call can cost is above it, the call is refused before anything is reserved or charged.
budget_creditsNoSpend ceiling for this call, in credits. The same ceiling as max_credits, as a number: send one or the other. If the most the call can cost is above it, the call is refused before anything is reserved or charged. It is a ceiling only: it never lets the call use a dearer source. Where spend ceilings aren't available to this key yet, a request that sets it is refused with the reason.
idempotency_keyNoA payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."New value: +"A payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
    • changedInput schema / properties / want / description
      Previous value: -"What to look up. work_email and profile run the email lookup (5 credits on a hit), which returns a mobile number too when its source has one. mobile_phone also runs a separate mobile search when the email lookup found none: 15 credits when that search finds one, 5 when the mobile came with the email, nothing when no mobile is found; a mobile_phone-only request that finds only an email is free and returns nothing. Where this isn't applied for your key yet, every call runs the same email lookup whatever this lists."New value: +"What to look up. work_email and profile run the email lookup (5 credits on a hit), which returns a mobile number too when its source has one. mobile_phone also runs a separate mobile search when the email lookup found none: 17 credits when that search finds one, 5 when the mobile came with the email, nothing when no mobile is found; a mobile_phone-only request that finds only an email is free and returns nothing. Where this isn't applied for your key yet, every call runs the same email lookup whatever this lists."
  2. Changed1 schema field changed
    • changedInput schema / properties / want / description
      Previous value: -"Not yet applied: every call runs the same lookup and returns what it finds (work email, profile, and a mobile number when the source has one), whatever this lists. Accepted so requests stay valid once it is applied."New value: +"What to look up. work_email and profile run the email lookup (5 credits on a hit), which returns a mobile number too when its source has one. mobile_phone also runs a separate mobile search when the email lookup found none: 15 credits when that search finds one, 5 when the mobile came with the email, nothing when no mobile is found; a mobile_phone-only request that finds only an email is free and returns nothing. Where this isn't applied for your key yet, every call runs the same email lookup whatever this lists."
  3. Changed1 schema field changed
    • addedInput schema / properties / route
      Added value: +{
      +  "description": "Source preference for this call: balanced (the default), cheapest (the lowest-cost sources), broadest (the sources expected to find the most) or fastest. The price doesn't change with it. Where route choice isn't available to this key yet, only balanced is accepted.",
      +  "enum": [
      +    "balanced",
      +    "cheapest",
      +    "broadest",
      +    "fastest"
      +  ],
      +  "type": "string"
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / budget_credits
      Added value: +{
      +  "description": "Spend ceiling for this call, in credits. The same ceiling as max_credits, as a number: send one or the other. If the most the call can cost is above it, the call is refused before anything is reserved or charged. It is a ceiling only: it never lets the call use a dearer source. Where spend ceilings aren't available to this key yet, a request that sets it is refused with the reason.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 2000,
      +  "type": "number"
      +}
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "Return this call's plan instead of running it, as of evaluated_at: the most it can cost, how many sources could answer, what budget_credits changes, and every limit the real call would trip. Nothing is looked up, reserved or charged, and a later call may differ. Where previews aren't available to this key yet, a request that sets it is refused with the reason.",
      +  "type": "boolean"
      +}
  5. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."New value: +"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  6. Changed2 schema fields changed
    • addedInput schema / properties / max_credits / description
      Added value: +"Spend ceiling for this call, in credits. If the most the call can cost is above it, the call is refused before anything is reserved or charged."
    • addedInput schema / properties / want / description
      Added value: +"Not yet applied: every call runs the same lookup and returns what it finds (work email, profile, and a mobile number when the source has one), whatever this lists. Accepted so requests stay valid once it is applied."
  7. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Stable retry key; the same value identifies retries of the same request after timeout or approval."New value: +"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."
  8. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Adds a lot beyond the annotations: credit costs per outcome, per-workspace caching of repeats, 'refused before anything is reserved' spend ceilings, dry_run returning a plan with nothing charged, and feature-availability caveats ('where this isn't applied for your key yet'). It does not reconcile the destructiveHint=true annotation with what is actually destroyed (nothing but credits), leaving that trait unexplained.

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

Conciseness3/5

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

Purpose is front-loaded, but the remainder is a single dense block that jumps between cost, verification, mobile sourcing, budgets, dry_run and routing with no grouping, and includes a garbled reference ('the answer's layrcake.route'). Most sentences earn their place, but the lack of structure costs readability.

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

Completeness4/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 usefully names the returned profile fields and the key response field contact.email_verdict, tying it to verify_email's vocabulary. What is missing is a fuller sketch of the response object and the credit/balance requirements that gate a real call.

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 already 86%, so the baseline is 3; the description still adds real meaning, notably that budget_credits and max_credits are the same ceiling ('send one') and that budget is not permission to use a dearer source, plus the 17/5/0 credit outcomes for want=['mobile_phone']. Route semantics (price invariant across routes) are also spelled out.

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?

Opens with a specific verb and resource ('Find a person's verified work email and profile') plus the fields returned, and immediately distinguishes itself from the sibling verify_email. An agent can tell this apart from enrich_company and find_leads without reading any schema.

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?

Explicitly routes between siblings: 'Call verify_email only for an address you got elsewhere, or one whose email_verdict is null.' It also gives per-option usage conditions for want (mobile_phone add-on), route, dry_run and budget_credits, including the exclusion that budget_credits never authorizes a dearer source.

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