Skip to main content
Glama

Verify email address

verify_email
Destructive

Verify the deliverability of one email address (two-stage check incl. catch-all analysis). Returns status valid|invalid|catch_all_valid|catch_all_unknown|unknown|risky and is_catch_all_domain. Costs credits per call. An address from enrich already carries this check (its contact.email_verdict): call verify_email only for an address you got elsewhere. budget_credits is a spend ceiling, never permission to use a dearer source: 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.

Input Schema

NameRequiredDescriptionDefault
emailYes
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.
budget_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. 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. Changed1 schema field 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."
  2. Changed2 schema fields changed
    • addedInput schema / properties / budget_credits
      Added value: +{
      +  "description": "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. 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"
      +}
  3. 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."
  4. 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."
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing credit cost per call, that an over-ceiling call is refused before any reservation, and that dry_run returns a plan with nothing looked up, reserved or charged. The two-stage/catch-all behavior and the exact return fields (status, is_catch_all_domain) are also disclosed, which annotations alone never convey.

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-loads purpose, then result values, then cost, then the sibling routing rule, then the two optional parameters — a sensible order. Sentences are dense but each carries information; the closing dry_run sentence is long and slightly overlaps the schema's own dry_run description.

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 still names the returned status enum and is_catch_all_domain, plus cost and refusal semantics for the spend ceiling. An agent has everything needed to decide whether to call it and how to interpret a result.

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 75%, so the schema already documents dry_run and budget_credits at length; the description nevertheless adds interpretive nuance the schema lacks, notably that budget_credits is a ceiling and 'never permission to use a dearer source.' The email parameter itself gets no added guidance, which is the only gap.

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 ('Verify the deliverability of one email address') and pins the scope to a single address, distinguishing it from bulk enrichment siblings. It even enumerates the possible return statuses, so the agent knows exactly what kind of answer to expect.

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 the agent away from redundant calls: 'An address from enrich already carries this check (its contact.email_verdict): call verify_email only for an address you got elsewhere.' This names the sibling, the field to check instead, and the condition that selects this tool.

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