Email verification for AI agents — verify, clean & validate emails; self-onboard + crypto pay
Scored across 17 tools
Most tools have clearly distinct purposes, and the verification modes (verify_email, verify_batch, submit_bulk, verify_email_demo) are well-differentiated by scope and authentication. However, get_account, get_credits, and get_usage overlap in reporting account/credit information, which could cause mild misselection.
All tool names follow a consistent snake_case verb_noun pattern, such as get_account, verify_email, submit_bulk, and list_jobs. There are no mixed conventions or vague names.
With 17 tools, the set is slightly above the typical 3-15 range but still well-scoped for an email verification API covering onboarding, billing, account, usage, and multiple verification workflows. Each tool appears to earn its place, though a few reporting tools could potentially be consolidated.
The surface covers core email verification workflows (single, batch, bulk async, demo), account creation and profiling, credit purchase, job submission/status/results, and useful preprocessing utilities like clean_email_list and extract_emails. Minor gaps exist, such as job cancellation, API key rotation, or webhook management, but these are not likely to block common agent workflows.
Start a purchase of a credit package and return a way to pay. This does NOT complete a payment by itself — it returns a payment link / address:
• method 'stripe' → returns a checkout_url. Paying by card requires a HUMAN to open that link and enter card details; an agent cannot finish a card payment on its own.
• method 'crypto' → returns a Plisio invoice with a checkout_url AND, when you pass a currency (BTC, ETH, LTC, USDT, USDC), a RAW wallet address + amount. An autonomous agent CAN pay this from a crypto wallet with no browser/human, then credits are added automatically once the payment confirms. Prefer crypto for fully autonomous top-ups. Get a package id from get_packages first.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Payment method. 'stripe' = card link (needs a human), 'crypto' = wallet-payable invoice. Default 'stripe'. | |
| currency | No | For method 'crypto': the coin to pay in; returns a raw wallet address an agent can pay autonomously. | |
| package_id | Yes | The package id to buy (from get_packages). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes well beyond this: it discloses that the call does not complete payment, that stripe needs a human to enter card details, that crypto returns a raw address an agent can pay autonomously, and that credits are added automatically after confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key constraint ('does NOT complete a payment by itself') and organized into two scannable bullets per method. Slightly long, but nearly every sentence carries decision-relevant information for an autonomous agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain returns — and it does precisely, naming checkout_url, the Plisio invoice, address and amount per method. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning beyond the schema: the autonomy implication of method='crypto' and the currency enum (raw wallet address, agent-payable). It stops short of adding format/syntax detail for the package id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Start a purchase of a credit package and return a way to pay') and immediately clarifies the boundary that it does not itself complete a payment. This distinguishes it from siblings like get_packages and get_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to call get_packages first for a package id, and gives a clear selection rule between methods ('Prefer crypto for fully autonomous top-ups'). It also states the when-not condition for stripe (requires a human browser).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the DNS and deliverability health of an email domain: MX records, SPF, DMARC, and an overall health score. Useful for diagnosing why a domain bounces or for validating a sending domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds useful specifics about what is checked (DNS records, SPF, DMARC) and the outcome (overall health score), though it does not mention external DNS lookups or return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the core action and followed by the use case. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only diagnostic tool with one parameter, annotations covering safety, and no output schema, the description provides enough to invoke it correctly. It could optionally state what the health score represents or what the response includes, but the core purpose and checks are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter, including an example. The description adds no further parameter guidance, which is acceptable since the schema already fully documents the field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check the DNS and deliverability health of an email domain') and enumerates the exact checks (MX, SPF, DMARC, overall health score). Clearly distinguishes from sibling verification tools, which target individual email addresses rather than domain-level health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use it ('diagnosing why a domain bounces' or 'validating a sending domain'), but does not mention explicit alternatives or when-not to use it, such as deferring to verify_email for individual address checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean a list of email addresses before an import or campaign: dedupes, removes invalid syntax, and (optionally) strips disposable and role accounts. Returns the cleaned list plus a summary of what was removed.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to clean. | |
| remove_disposable | No | Remove disposable/throwaway addresses. Default true. | |
| exclude_role_accounts | No | Remove role accounts (info@, support@, ...). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it says what is removed and that the response includes the cleaned list plus a removal summary, so an agent knows mutations are non-destructive transformations of the input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence plus a short return-value clause, with no filler or redundancy. The core action and the notable optional behaviors are stated before the response shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by describing the return (cleaned list plus removal summary). With only three boolean/array parameters and full annotation coverage, nothing essential for a correct call is missing, though edge cases like handling of duplicates across case differences are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes slightly beyond the schema by framing the disposable and role-account flags as optional behaviors layered onto the core cleaning pass, helping the agent understand that these are toggles on an otherwise always-on dedupe/validation pipeline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Clean a list of email addresses') and enumerates the concrete operations (dedupe, invalid-syntax removal, disposable/role stripping). This is clearly distinguishable from siblings like verify_email, verify_batch, or extract_emails, which validate or extract rather than clean.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context ('before an import or campaign'), which tells the agent when this tool belongs in a workflow. It does not, however, name or exclude alternatives such as verify_email/verify_batch for validation-only needs, so the routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all email addresses found in a block of free-form text (notes, pasted documents, signatures). Optionally deduplicates and lowercases the results.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Free-form text to scan for email addresses. | |
| lowercase | No | Lowercase all extracted addresses. Default true. | |
| deduplicate | No | Remove duplicate addresses. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that dedup and lowercasing are optional behaviors, which is minor context beyond the schema. It says nothing about matching strictness or how malformed addresses are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and followed by the optional modifiers. No filler, though the second sentence largely echoes schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only extraction tool with full schema coverage and annotations covering safety, the description is sufficient. No output schema exists, but the return (addresses) is self-evident from the purpose, so no major gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (text, lowercase, deduplicate) are already documented with defaults. The description's mention of optional dedup/lowercase restates rather than extends the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Extract all email addresses') and scopes it to a block of free-form text. It is clearly distinguishable from siblings like clean_email_list and verify_email, which operate on lists or single addresses rather than raw text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical use cases (notes, pasted documents, signatures) imply when the tool is useful, but there is no explicit when-not guidance and no named alternative (e.g. 'for verifying a known address, use verify_email'). Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the account profile for the current API key: email, name, company, timezone, remaining credits, total credits used, number of API keys, and plan. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral context beyond those annotations: it scopes the call to the current API key and explicitly states that it costs no credits, which is operationally useful for an agent managing API budget.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and resource, then lists the returned fields and closes with the cost note. Every clause carries useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter read tool with no output schema, the description is sufficiently complete: it states the subject (current API key), enumerates the returned fields, and discloses the no-credit-cost behavior. Annotations cover the safety profile, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the input schema is empty, so the baseline is 4. The description lists returned fields rather than parameter semantics, which is appropriate for a parameterless read tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: 'Return the account profile for the current API key', and enumerates the fields included. This clearly distinguishes an account-profile read from most siblings, though it does not explicitly contrast with get_credits, get_usage, or register_account, which overlap partly on credits/usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: fetch account metadata for the current API key. The description adds a useful cost note ('Costs no credits'), but it does not say when to choose this over get_credits, get_usage, or other sibling tools, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the API key's remaining verification credits and recent usage (today / this month) and plan. Costs no credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — that the call consumes no credits — which an agent needs when deciding whether to probe it. It omits any auth/permission note, but for a read-only endpoint that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the primary purpose front-loaded and the useful cost caveat appended. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description fully enumerates what comes back (remaining credits, usage today/this month, plan) and the cost implication. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. The description correctly implies no input is needed by describing only return content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and resource (API key's remaining verification credits, recent usage, plan), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from siblings like get_usage or get_account, which could overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Costs no credits" implies the tool is free to call and lower-stakes than metered siblings such as verify_email, giving implied usage context. There is no explicit statement of when to prefer this over get_usage or get_account, so guidance remains inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full per-address results of a completed bulk verification job by job_id (each email's verdict, recommendation, and reason) plus the valid/invalid/risky summary and credits used. The job must be 'completed' — check get_job_status first.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by submit_bulk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the completed-state requirement and previews the result contents, but it does not mention pagination, result size limits, or permission needs. With annotations carrying the safety burden, this is useful but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and followed immediately by the critical prerequisite. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with one fully documented parameter and no output schema, the description is complete: it states the prerequisite, describes the returned per-address data, and mentions the summary and credits used. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter job_id is already documented as 'The job_id returned by submit_bulk.' The description adds no syntax, format, or constraint beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Fetch), resource (per-address results of a completed bulk verification job), and scope (by job_id, with verdict/recommendation/reason plus summary and credits). It distinguishes itself from get_job_status by requiring the job to be 'completed' and pointing to that sibling for status checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite: the job must be completed, and it names get_job_status as the tool to check first. This gives the agent an unambiguous when-to-use condition and a direct alternative for the pending case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current status and progress of a bulk verification job by its job_id (status, percent progress, processed count, and a valid/invalid/risky summary). Poll this after submit_bulk until status is 'completed', then call get_job_results.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id returned by submit_bulk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is already covered. The description adds genuine behavioral context: it is a polling endpoint, the loop-terminating status value ('completed'), and the state transition to the results call. It stops short of disclosing polling cadence, terminal failure states, or whether results expire, which keeps it from a 5 for a long-running async job tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return contents, then the workflow directive. Zero filler; every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description is nearly complete: it names the return fields, the polling pattern, and the handoff to get_job_results. It does not specify error/interrupted behavior of a job or any backoff guidance, which would matter for a long-running bulk job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is documented as 'the job_id returned by submit_bulk'. The description reinforces the same provenance ('by its job_id'), adding marginal confirmation of the id's origin rather than new format detail. With one fully documented parameter, the baseline is high and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Fetch the current status and progress of a bulk verification job') and enumerates exactly what is returned (status, percent progress, processed count, valid/invalid/risky summary). It is clearly distinguishable from get_job_results, its closest sibling, which is instead named as the follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow routing: poll this after submit_bulk until status is 'completed', then call get_job_results. Both the alternative (get_job_results) and the terminating condition are stated, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the credit packages available for purchase (id, name, credit amount, price in USD, and price per 1k credits). Use the returned package id with buy_credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that by disclosing the exact shape of the result set (which fields come back), which matters since no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, no filler. The field list is front-loaded and the second sentence delivers the actionable linkage to buy_credits. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list tool with no output schema, the description supplies everything an agent needs: what is returned, in what shape, and what to do with the result. No meaningful gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no semantics to convey and the schema is trivially complete. Baseline for a 0-param tool is 4; nothing in the description could add further parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('List the credit packages available for purchase') followed by an explicit enumeration of the returned fields (id, name, credit amount, price in USD, price per 1k credits). An agent can distinguish this from siblings like get_credits or buy_credits 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the concrete downstream step — 'Use the returned package id with buy_credits' — which tells the agent exactly when this tool precedes another. It gives clear usage context but no explicit exclusions or when-not-to-use conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call this FIRST if you have no Verifly API key. Returns how Verifly works and how to get access with no human: pay-as-you-go email verification API, 100 free credits on self-registration, no monthly fee. No API key required to call this tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious behavioral fact that no API key is required to call the tool, which is useful context beyond annotations. It does not describe the shape of the returned content, but for a zero-param informational tool that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the key routing instruction, but the middle sentence drifts into marketing copy ('pay-as-you-go email verification API, 100 free credits, no monthly fee') that is not strictly action-guiding. Still compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input, read-only onboarding tool with no output schema, the description supplies everything an agent needs: when to call it, that no auth is required, and what it returns. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline expectation is met without the description needing to explain anything. No parameter meaning is added or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Call this FIRST') and a specific return ('how Verifly works and how to get access'), making it immediately distinguishable from siblings like register_account or buy_credits. It is not a restatement of the title and clearly conveys a unique onboarding resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger condition: 'Call this FIRST if you have no Verifly API key,' and reinforces the prerequisite-free nature of the call. An agent can decide whether to invoke it without inspecting any other tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return detailed usage statistics for the account over a period (day, week, or month): total credits used, emails processed, request counts broken down by endpoint and source, a daily breakdown, and recent activity.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max recent log entries to include (default 100, max 1000). | |
| period | No | Reporting period. Default 'month'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that output spans credits, emails processed, per-endpoint/source counts, a daily breakdown, and recent activity, but says nothing about auth requirements, retention, or rate limits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence front-loads the purpose and then enumerates the returned metrics. Every clause earns its place by describing contents; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 enumerates what the response contains, and both parameters are fully specified in the schema. The main remaining gap is the absence of guidance on how this relates to the credit/account siblings, which is minor for a read-only reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in the schema, including the limit bounds and default and the period enum/default. The description only restates the period options ('day, week, or month') without adding format or interpretation detail, so baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb ('Return'), resource ('usage statistics'), and scope ('for the account over a period'), and enumerates the reported metrics. It does not explicitly distinguish itself from the closest sibling get_credits, which likely reports a balance rather than a breakdown, so sibling differentiation is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the supported periods (day/week/month) but gives no guidance on when to choose this tool over get_credits, get_account, or get_job_results. There is no when-to-use context and no exclusions, so the agent must infer the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's bulk verification jobs, most recent first, with their status, progress, and summary. Optionally filter by status and paginate. Use this to find past jobs and their job_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max jobs to return (1-100, default 50). | |
| offset | No | Pagination offset (default 0). | |
| status | No | Only return jobs in this status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the ordering behavior ('most recent first') and the returned field set, which is genuine value beyond the annotations, but it does not discuss pagination limits, default page size, or result caps at the behavioral level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences: the first states what is returned and in what order, the second states filters and purpose. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and annotations covering safety, the description is nearly sufficient — it explains output fields, ordering, filtering, and pagination, and points at the job_id token needed for follow-up calls. It stops short of naming get_job_status/get_job_results as the next step, which is the one remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, offset, and status are fully documented there, including the enum values. The description adds only what the schema already covers ('filter by status and paginate'). Baseline 3 is appropriate when the schema carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list bulk verification jobs) with scope ('the account's'), ordering ('most recent first'), and returned fields (status, progress, summary). It is distinguishable from get_job_status/get_job_results by being the collection-level listing, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a purpose clause ('Use this to find past jobs and their job_ids'), which implies when to use it. However, it does not contrast with get_job_status, get_job_results, or how to drill into a specific job — the natural alternatives in this sibling set are left unnamed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Programmatically create a brand-new Verifly account — this is how an agent self-onboards with no human in the loop. Requires only an email and a password (min 8 chars; disposable email domains are rejected). The new account starts with free credits. The response includes the new account id/email and a freshly generated api_key.key that is shown ONCE — capture and store it immediately, it cannot be retrieved again. Subsequent tool calls can then use that key as the bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email for the new account (not a disposable domain). | ||
| password | Yes | Password for the new account (minimum 8 characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it as a non-read-only, non-destructive, closed-world write. The description goes well beyond that by disclosing the disposable-domain rejection rule, that the account receives free credits, and critically that `api_key.key` is returned ONCE and cannot be retrieved again — a one-time-secret hazard an agent must act on immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what the tool does, then requirements, then the response contract. No filler; the one-time-key warning is stated where an agent will read it before calling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description enumerates the return payload (account id/email and the api_key) and the ephemerality of the key, which is the only return detail an agent needs to call and handle this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented including the 8-character minimum. The description reinforces the constraints and adds enforcement context (disposable domains rejected) but does not add syntax or format detail beyond the schema, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Programmatically create a brand-new Verifly account') and frames its role as the agent self-onboarding path, which cleanly separates it from read siblings like get_account, get_credits, and get_started.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the when clearly: no human in the loop, only email and password required, and that the returned key enables subsequent tool calls. It does not name an alternative or an explicit 'do not use this if you already have an account' exclusion, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a list of email addresses as an asynchronous bulk verification job — the right tool for large lists. Returns immediately with a job_id, status, and the check_status_url / results_url to poll. Small lists may complete inline (status 'completed'); larger ones return status 'pending' — poll get_job_status until it is 'completed', then call get_job_results. Optionally register a webhook_url (public HTTPS) to be notified when the job finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to verify in this job (deduped server-side). | |
| webhook_url | No | Optional public HTTPS URL to POST a job.completed notification to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (non-readOnly, openWorld, non-destructive). The description goes well beyond that, disclosing the async lifecycle, immediate return of job_id/status/poll URLs, the inline-completion case for small lists, and the webhook notification path — exactly the behavioral context an agent needs to drive the workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the primary purpose and immediate return, then the polling workflow, then the optional webhook. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by describing the return payload (job_id, status, check_status_url, results_url) and the two terminal states. Combined with the follow-up tool names, an agent has everything needed to submit and complete the job.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are self-documenting, so the schema does the heavy lifting. The description adds only the 'public HTTPS' constraint on webhook_url, which the schema already states, and the server-side dedupe note already appears in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (submit), resource (list of email addresses), and mode (asynchronous bulk verification job), and explicitly scopes it as 'the right tool for large lists.' This lets an agent distinguish it from verify_email and verify_batch without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly routes the agent: use for large lists, poll get_job_status until 'completed', then call get_job_results. It names the follow-up siblings and the webhook alternative. It stops short of stating when NOT to use it (e.g., preferring verify_batch/verify_email for small lists), so a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synchronously verify a list of email addresses (best for up to a few hundred). Returns a per-address verdict for each email. For very large lists use the bulk async endpoint instead.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Array of email addresses to verify. | |
| exclude_role_accounts | No | Flag/exclude role accounts (info@, sales@, ...). Default false. | |
| exclude_public_domains | No | Flag/exclude public domains (gmail.com, ...). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely new context: synchronous execution model, practical batch-size ceiling, and the shape of the result (per-address verdict). It omits rate limits, credit cost, and partial-failure behavior, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool does and why the sync path exists. Every sentence earns its place: purpose, return shape, and the routing condition to the alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read tool with full schema coverage and no output schema, the description supplies the sync/async distinction and the return value shape, which is what an agent needs to call it correctly. Remaining gaps (cost, rate limits, error semantics) are minor but nonzero.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all three parameters (emails, exclude_role_accounts, exclude_public_domains) carry their own descriptions with defaults. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (synchronously verify a list of email addresses) and scopes it ('best for up to a few hundred'), which cleanly separates it from verify_email (single) and submit_bulk (async large lists). 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the when ('best for up to a few hundred') and the when-not with a named alternative path ('For very large lists use the bulk async endpoint instead'). Both the selection condition and the escape hatch are stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one email address in real time. Returns a deliverability verdict (valid / invalid / risky / unknown), the reason, detailed flags (disposable, role account, catch-all, MX, SMTP), a send/reject recommendation, and credit usage.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to verify, e.g. lead@example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint, non-destructive), and the description adds genuinely non-structured context: the verdict taxonomy, the flag set produced, and that the call consumes credits. It stops short of stating latency/auth/rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the action and the return payload are front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 enumerates the return values (verdict, reason, flags, recommendation, credit usage), which is exactly what an agent needs. Only the choice among sibling verification tools remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented in the schema, so the description correctly does not duplicate it. Baseline 3 applies since the description adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify one email address') and scopes it to a single address in real time, which cleanly separates it from siblings like verify_batch and verify_email_demo without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Verify one email address' implies the single-address use case, but there is no explicit guidance on when to choose this over verify_batch, verify_email_demo, or clean_email_list. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one email address with NO account or API key, so you can evaluate Verifly before registering. Rate-limited per IP (a few checks). Returns the same deliverability verdict and flags as the full API. For real volume, call register_account for a key + 100 free credits, then use verify_email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to verify, e.g. lead@example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavior: per-IP rate limiting with a small check budget, no auth requirement, and output parity with the full API. It doesn't say what happens when the rate limit is hit (error shape), which keeps it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all load-bearing: first the action and key-free constraint, then the rate-limit and output-parity caveats, then the upgrade path. Front-loaded with the differentiator and zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating that the same deliverability verdict and flags are returned as the full API. Auth expectations, rate limits, and the escalation path are all covered for a simple single-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required 'email' parameter, so the schema already carries the semantics. The description only implies one address at a time, adding little beyond what the schema documents; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify one email address') plus the distinguishing scope: demo mode with no account or API key. An agent can separate it from verify_email, verify_batch, and verify_email_demo's siblings without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use (evaluating Verifly before registering, no key needed) and routes to alternatives by condition: register_account for a key + credits, then verify_email for real volume. Exclusions and escalation path are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_startedverify_email_demobuy_creditscheck_domain_healthclean_email_listextract_emailsget_accountget_creditsget_job_resultsget_job_statusget_packagesget_usagelist_jobsregister_accountsubmit_bulkverify_batchverify_emailEmail finder + verifier for AI agents: find work emails by name and company, check deliverability.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Add one secure layer between your agents and this server.