Skip to main content
Glama

Price a check of your email list

argorant_quote_verification

Get a price for checking email addresses the user already has, up to 1,000 different addresses (5,000 rows). Use it for the user's own list; to find emails for people use argorant_find_email or argorant_find_emails, and to get contacts from Argorant use argorant_reveal_people. It checks nothing and spends no credits. Duplicates are removed and the row numbers of entries that are not email addresses are listed. Each new check costs half a credit, so two checks cost 1 credit, rounded up for each run; addresses checked recently are free again, and any older check balance on the account is used before credits. The quote is kept privately for 15 minutes. The answer shows the counts, the most it can cost and the credits left, without repeating the addresses. Show these to the user and ask the user before starting the check with argorant_start_verification. More in the docs at https://docs.argorant.com/docs/agents/tools#verify-your-own-list

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": {
      "emails": "<emails>"
    },
    "name": "argorant_quote_verification"
  }
}

Input Schema

NameRequiredDescriptionDefault
emailsYesThe addresses to check, up to 5,000 rows.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description goes well beyond by clarifying that the call itself checks nothing and spends no credits, which is essential given readOnlyHint=false. It also discloses pricing (half a credit per check, rounded up per run), reuse of recently checked addresses for free, consumption of existing check balance before credits, and 15-minute private quote retention. The only gap is that it doesn't say whether a failed quote is retryable or what happens after the 15 minutes expire.

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?

Purpose and alternatives are front-loaded, and almost every sentence carries operational weight (cost model, dedup behavior, retention, human-confirmation step). It is on the long side for a one-parameter tool, with pricing detail that could be tightened, but nothing is redundant.

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?

An output schema exists, yet the description still summarizes the response shape (counts, maximum cost, credits remaining, no echoed addresses) and tells the agent what to do with it. For a quote tool that gates a paid follow-up call, this is complete enough to act on.

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 would be a 3, but the description adds real meaning: duplicates are collapsed to 1,000 distinct addresses, and rows that aren't email addresses are reported back by row number. That nuance is not inferable from the schema's maxItems of 5,000.

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 ("Get a price for checking email addresses the user already has") plus the scale limits (1,000 unique addresses / 5,000 rows). It explicitly distinguishes itself from the sibling discovery tools argorant_find_email, argorant_find_emails and argorant_reveal_people, so an agent can route correctly without opening 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?

Gives an explicit when-to-use (the user's own existing list) and when-not (finding new emails or pulling Argorant contacts), naming the alternative for each case. It closes the loop by instructing the agent to show the quote and ask the user before calling argorant_start_verification.

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.