Skip to main content
Glama

Find work emails for a list of people

argorant_find_emails
Destructive

Find work emails for a list of up to 1,000 people per call, each with first name, last name, company domain and an optional ref of your own. Use it for more than 5 people; for one person use argorant_find_email, and to check addresses the user already has use argorant_quote_verification. Each person costs 1 credit when an email is found and confirmed, and 1 credit when the company's domain accepts every address (catch-all). In that case the most likely address is returned and marked unconfirmed. It costs 0.25 credits when nothing is found. Nothing is charged for invalid input, for a domain that does not exist or cannot receive email, or when the check cannot be finished right now (status retry_later). Credits are the account's shared credits. Before calling, tell the user how many people there are, the price for each result and the most it can cost (people times the found price), and ask the user to approve a spending limit, passed as max_credits. The list runs in the background and never spends more than max_credits. It pauses at that limit (resume with a higher one through argorant_manage_find_emails), when the account runs out of credits, or at the daily lookup limit (it continues after midnight UTC), and it slows down by itself when most lookups find nothing. Duplicates are removed and rows without a usable name or domain are skipped for free (invalid_rows). The answer has job_id, status, totals and maximum_charge at once; call argorant_find_emails_status about every 30 seconds for progress and results, which are also in the Argorant app (app_url) as a table and a CSV download. More in the docs at https://docs.argorant.com/docs/agents/tools#find-work-emails

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": {
      "people": "<people>",
      "max_credits": "<max_credits>"
    },
    "name": "argorant_find_emails"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoA label for the list, e.g. 'Q4 accounts'
peopleYesThe people to look up, as [{first_name, last_name, domain, ref?}]
max_creditsYesSpending limit in credits the user approved for this list

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only mark this as a destructive, open-world, non-read-only call, but the description supplies the real behavioral detail: per-outcome credit costs, which outcomes are free, catch-all handling that returns an unconfirmed address, background execution, the max_credits pause/resume path via argorant_manage_find_emails, the daily limit and midnight UTC reset, self-throttling, and free deduplication/skipping. Nothing contradicts the annotations; a spend-incurring, destructive tool is precisely described.

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?

Front-loaded correctly: purpose and scale, then sibling routing, then cost model, then operational flow. Every clause carries information an agent needs, but it arrives as one undifferentiated block, and pricing/limit details could be tightened or bulleted to reduce scan cost.

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?

For a paid, asynchronous, destructive batch operation this covers everything an agent must know to call it safely: approval prerequisites, spend ceiling, polling cadence ('about every 30 seconds' via argorant_find_emails_status), pause conditions, and where results appear. An output schema exists, yet the description still names the immediate response fields (job_id, status, totals, maximum_charge) without duplicating the full schema.

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 genuine meaning: max_credits is framed as a user-approved spending limit that the job never exceeds and that pauses execution (resumable via argorant_manage_find_emails), and ref is 'of your own' returned with results. It also explains that invalid rows without a usable name or domain surface as invalid_rows rather than erroring.

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?

States a specific verb and resource ('find work emails') plus the operating scale ('up to 1,000 people per call') and the exact input shape (first name, last name, company domain, optional ref). It explicitly distinguishes itself from argorant_find_email and argorant_quote_verification, so an agent can route without opening either 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?

Gives an explicit threshold ('use it for more than 5 people') and names both alternatives with the condition that selects each: single-person lookups go to argorant_find_email, and addresses the user already has go to argorant_quote_verification. It also states the pre-call obligation to disclose volume, per-result price and maximum cost, and get user approval.

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.