Email verification for AI agents — verify, clean & validate emails; self-onboard + crypto pay
Scored across 17 tools
Every tool has a clearly distinct purpose: single vs batch vs bulk verification, job status vs results vs listing, account vs credits vs usage, and demo vs paid verification are all unambiguous. The descriptions reinforce boundaries well, such as get_job_status versus get_job_results and buy_credits versus get_packages.
All tools consistently use lowercase snake_case with a verb_noun pattern: verify_email, submit_bulk, get_job_status, list_jobs, buy_credits. The only slight deviation is get_started, but it still follows the 'get' prefix pattern and fits the overall style.
At 17 tools, the set is slightly above the ideal 3-15 range but each tool serves a distinct need across account management, billing, verification, batch jobs, and utilities. The count is justified by the breadth of the API, but the slight overlap between get_account and get_credits means it is not maximally lean.
The tool surface fully covers the email verification lifecycle: onboarding (register_account, get_started), individual and batch verification (verify_email, verify_batch), bulk async jobs (submit_bulk, get_job_status, get_job_results, list_jobs), domain health, list cleaning, extraction, account/usage monitoring, and credit purchasing. No obvious gaps exist for the intended domain.
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?
With no annotations, the description fully discloses behavioral traits: it does NOT complete payment, returns a payment link/address, specifies the human requirement for stripe, and explains that credits are added automatically once crypto payment confirms. This goes beyond basic purpose to detail the exact transaction flow and autonomy levels.
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 longer than two sentences, but it is well-structured with bullet points and every sentence carries functional weight. It avoids fluff while covering method-specific behavior, return values, and prerequisites.
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?
Given the tool's complexity (two payment methods with different requirements), the description is remarkably complete. It covers prerequisites, what is returned for each method, who can complete the payment, and follow-up behavior (automatic credit addition), leaving no critical gaps even without an output schema.
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 schema already documents all parameters with descriptions and enum values, so the bar is higher. The description adds valuable interaction semantics, such as how method 'crypto' with a currency returns a raw wallet address and amount. This enriches the schema without redundancy, justifying a score above baseline.
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 clearly states 'Start a purchase of a credit package and return a way to pay', identifying the specific action and resource. It distinguishes itself from sibling tools like get_credits (checking balance) and get_packages (listing packages) by explaining the purchase initiation purpose.
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 explicit when-to-use guidance: 'Prefer crypto for fully autonomous top-ups' and instructs to 'Get a package id from get_packages first'. It also gives an exclusion by warning that an agent cannot finish a card payment on its own, thus steering agents toward the crypto method when needed.
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?
No annotations are provided, so the description carries the burden of disclosure. It reveals the specific DNS records checked, but does not explain the response format, scoring criteria, or any potential side effects/limitations. For a read-only check tool, some behavioral context is missing.
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?
Exceptionally concise: two sentences that immediately convey what the tool does, what it checks, and when to use it. No wasted words or redundant details.
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?
The tool has no output schema, so the description should compensate by explaining return values. It mentions an 'overall health score' but does not describe the response structure, interpretation, or error handling. For a simple single-parameter tool, it is adequate but leaves the agent uncertain about the result format.
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 'domain' parameter is well-documented with an example. The description adds no additional parameter semantics beyond what the schema already provides, so 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?
Description clearly states it checks DNS and deliverability health of an email domain, listing MX, SPF, DMARC, and health score. This distinguishes it from sibling tools like verify_email which check individual addresses rather than domain-level configuration.
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 describes two use cases: diagnosing bounced domains and validating sending domains. It does not explicitly name alternative tools, but the domain-vs-address distinction is clear from the description and sibling context.
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?
With no annotations provided, the description carries the full burden. It clearly states what cleaning operations are performed (dedupe, invalid syntax, disposable/role) and what is returned (cleaned list plus summary). It does not cover edge cases like case normalization or whether the input is modified, but it is reasonably transparent for a cleaning 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 the main purpose, then scope, then return detail. No wasted words.
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?
The description is complete for a simple cleaning tool: it explains the operation and return value. It does not explicitly differentiate from verification tools (e.g., checking deliverability), but the sibling list and context make this clear enough. The lack of an output schema is offset by the description's mention of a summary.
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 the description does not need to repeat parameter definitions. The description's 'optionally strips disposable and role accounts' aligns with the schema defaults, but adds no new meaning 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?
The description clearly states the tool cleans an email list, specifying concrete actions: dedupe, remove invalid syntax, and optionally strip disposable and role accounts. This distinguishes it from sibling tools like verify_email and extract_emails.
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 provides clear usage context: 'before an import or campaign.' It does not explicitly mention when not to use it or name alternative tools, but the context is sufficient for most scenarios.
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?
With no annotations provided, the description carries the full burden. It discloses optional deduplication and lowercasing behavior, adding value beyond the schema defaults. However, it does not mention edge cases like invalid formats, no matches, or the return type, which could be relevant for an extraction tool. This is adequate but not rich.
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 sentence with a trailing clause, front-loaded with the core purpose. Every word earns its place—no fluff or redundancy. It is highly concise while conveying essential behavior.
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?
This is a low-complexity tool with no output schema, but the description explains the input and optional processing, making the return (a list of extracted emails) fairly obvious. It is complete enough for the tool's simplicity, though a note about empty results could improve it.
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 adds context by framing the text parameter as 'free-form text' and noting optional processing, but it largely mirrors the schema's default descriptions. It does not add significant syntactic or behavioral detail beyond what the schema already provides.
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 clearly states the verb (extract), the resource (email addresses), and the context (free-form text), which is distinct from sibling tools like verify_email or clean_email_list. It also notes optional deduplication and lowercasing, adding specificity.
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 clearly implies when to use: when you have free-form text with email addresses, such as notes, documents, or signatures. It does not explicitly exclude alternatives, but the context and sibling list make the extraction use case clear. No exclusions are needed for this simple utility.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly notes 'Costs no credits' and enumerates the return fields, providing useful transparency beyond the basic action. It does not mention rate limits or error handling, but for a simple getter with no parameters these are less critical.
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, front-loaded sentence that immediately names the action and resource. It efficiently lists the returned fields and adds a concise cost note. Zero waste.
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?
Since there is no output schema, the description compensates by listing the exact returned fields. It also informs about the credit cost. For a zero-parameter tool, this is sufficiently complete. Minor gaps like error behavior are not significant given the tool's simplicity.
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 is empty (0 parameters), so the baseline is 4. The description adds context by specifying that the account is identified via the 'current API key', which is an implicit authentication input. No parameter details are needed since there are none.
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 clearly states the tool 'Return the account profile for the current API key' and lists specific fields (email, name, company, timezone, credits, etc.). This specific verb+resource combination distinguishes it from sibling tools like get_credits or get_usage, which focus on narrower data subsets.
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 implied usage is evident from the resource description ('current API key'), but there is no explicit guidance on when to use this versus alternatives like get_credits or get_usage, nor any exclusions. The context is clear but the guidance is only implicit.
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?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait by stating 'Costs no credits' and clearly lists the data returned (today/this month usage, plan). This exceeds minimal transparency, though it omits details like data freshness or authentication.
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 two short sentences, front-loaded with the primary action and result, and includes an important cost note. Every word earns its place with 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?
For a zero-parameter tool with no output schema or annotations, the description is remarkably complete: it specifies exactly what data is returned (remaining credits, today's/monthly usage, plan) and the cost behavior. It provides all necessary context for an agent to invoke this tool confidently.
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 baseline for this dimension is 4. The description adds meaning by explaining the return values, which is essential given there is no output schema. It does not need to explain parameters that do not exist.
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 clearly states the tool returns remaining verification credits, recent usage, and plan. The verb 'Return' and specific resource (API key's remaining verification credits) make the purpose unambiguous, though it doesn't explicitly differentiate from sibling tool get_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?
The description implies usage for checking credit status without cost, but it does not explicitly state when to use this tool versus others like get_usage or get_account. The 'Costs no credits' note is a contextual hint but not full guidance.
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?
With no annotations provided, the description carries the burden. It discloses the return content (per-address results, summary, credits used) and the precondition (only for completed jobs). It does not mention error behavior or side-effects, but 'fetch' implies read-only, and the main traits are covered.
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 two sentences: first states the core action and return contents, second gives the necessary precondition. No redundant words, and it is front-loaded with the verb and resource.
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 complete enough to invoke correctly. It specifies the resource, return values, and usage condition. It could add pagination or error details, but these are not essential for basic use.
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 parameter description already explains job_id as returned by submit_bulk. The description adds no extra semantic detail about the parameter, so the baseline score of 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?
The description clearly states the tool fetches full per-address results of a completed bulk verification job, listing specific data fields (verdict, recommendation, reason) and the summary/credits used. This distinguishes it from siblings like get_job_status (status) and list_jobs (job list).
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 explicitly states the job must be 'completed' and instructs to 'check get_job_status first', providing a clear precondition and directing the agent to the relevant sibling tool. It does not contrast with all alternatives, but the key ambiguity is resolved.
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?
With no annotations, the description carries full burden. It discloses that this is a polling operation, lists the returned fields, and implies a read-only nature. It does not mention error behavior or rate limits, but for a simple status endpoint this is adequate.
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?
Exactly two sentences: the first defines the action and output, the second provides the workflow. No fluff, front-loaded verb, and every word adds value.
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 tool with one parameter and no output schema, the description covers the returned fields (status, percent progress, processed count, valid/invalid/risky summary), when to call it, and the next step. It is fully sufficient for an agent to use 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?
The schema already fully describes job_id as 'The job_id returned by submit_bulk', with 100% coverage. The description merely restates 'by its job_id', adding no new parameter meaning, 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?
The description clearly states 'Fetch the current status and progress of a bulk verification job by its job_id', using a specific verb and resource. It distinguishes itself from the sibling get_job_results by focusing on status/progress rather than final results.
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 instructs to 'Poll this after submit_bulk until status is completed, then call get_job_results', naming both a predecessor and a successor tool. This provides clear when-to-use guidance and an explicit alternative.
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?
With no annotations provided, the description carries the full burden. It accurately states the operation is a list and specifies the output fields, but doesn't disclose authentication requirements, rate limits, or whether the list is complete/unpaginated. The verb 'List' implies read-only, but this is not explicit.
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 concise sentences: the first states the purpose and lists return fields, the second gives a direct usage directive. No wasted words or redundant elaboration.
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?
Given no output schema and no parameters, the description adequately explains what is returned and how to use it. It doesn't mention pagination, ordering, or authentication requirements, but for a presumably small list of credit packages, these are minor omissions.
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 has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific semantics, but with no parameters to document, the baseline of 4 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?
The description uses a specific verb 'List' with a specific resource 'credit packages', and enumerates the exact fields returned (id, name, credit amount, price in USD, price per 1k credits). This clearly distinguishes it from siblings like buy_credits (purchase) and get_credits (likely balance).
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 explicitly directs the agent to use the returned package id with buy_credits, providing a clear next step and implicit alternative. It doesn't state when not to use or mention sibling tools like get_credits, but the context is sufficient for typical use.
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?
With no annotations, the description carries the burden. It explains that no API key is needed, no human interaction required for access, and describes what the tool returns (how Verifly works, getting started info).
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 focused sentences with front-loaded condition ('Call this FIRST if...') and actionable summary. No wasted words.
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, no-output-schema onboarding tool, the description fully covers purpose, when to use, preconditions, and behavior. Nothing 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?
Zero parameters, so baseline is 4. No parameter info needed; the description correctly adds no redundancy.
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 explicitly states the tool's role as the entry point ('Call this FIRST') and clearly distinguishes it from the 16 sibling tools by targeting users without an API key.
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?
Clear when to use (no API key) and what it returns, but could explicitly state 'do not call if you have a key' to cover exclusions.
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?
No annotations are provided, so the description carries the full burden. It accurately indicates a read operation ('Return') and describes the response contents, but it does not disclose potential limitations such as data freshness, pagination, or performance implications. The schema covers limits via the 'limit' parameter, but the description itself adds no extra behavioral context.
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 sentence that front-loads the core function and then enumerates the response components. It is efficient, with no redundant phrases, though the list is somewhat long. Every part contributes value.
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 adequately explains the return values by listing the main data points. It covers the period options and mentions recent activity, which aligns with the 'limit' parameter. It does not clarify the default period or the default limit, but those are in the schema defaults. Overall, sufficient for a reporting tool with no annotations.
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%, with both 'limit' and 'period' already documented in the schema. The tool description restates the period options ('day, week, or month') but does not add new parameter details. Per rubric, baseline 3 applies when schema handles the heavy lifting.
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 uses a specific verb ('Return') and clearly identifies the resource ('detailed usage statistics for the account over a period'). It lists concrete data (credits used, emails processed, request counts by endpoint/source, daily breakdown, recent activity), making it distinct from siblings like get_credits or get_account.
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 implies use for detailed reporting but does not explicitly state when to use this tool versus alternatives such as get_credits (for credit balance) or get_account. No when-not-to-use guidance is provided, so the usage context is only implied by the detailed scope.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns jobs most recent first, includes status/progress/summary, and supports filtering/pagination. The 'List' verb implies a read-only operation with no side effects, which is adequate for a simple list tool. It doesn't mention rate limits or authentication, but these are not critical for a list operation.
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 two sentences, front-loaded with the verb and resource, and includes only essential information. No redundant details.
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?
The tool is simple, with 3 optional parameters and no output schema. The description covers purpose, ordering, filters, and gives use-case guidance. It mentions the output fields (status, progress, summary) partially compensating for the missing output schema. Overall, it's complete for this level of complexity.
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 the schema already fully documents all three parameters. The description adds a high-level statement about filtering and pagination, but doesn't add details beyond 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?
The description clearly identifies the tool as a list operation for bulk verification jobs, specifying what it returns (status, progress, summary) and the ordering. It distinguishes from siblings like get_job_status by focusing on listing multiple jobs and providing job_ids.
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 explicitly states 'Use this to find past jobs and their job_ids,' giving a clear use case. It also mentions optional status filtering and pagination, providing context for when to use these features. However, it does not explicitly exclude alternatives like get_job_status for specific job lookups.
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?
With no annotations provided, the description fully carries the behavioral disclosure burden and does so excellently: it warns about the one-time visibility of the API key, instructs immediate capture, states it cannot be retrieved again, mentions free credits, and discloses domain rejection. These side effects go well beyond a basic creation operation.
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 three sentences, each earning its place: purpose, requirements/free credits, and critical one-time key behavior. It is front-loaded with the core action and contains no fluff or redundant 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 2-parameter tool with no output schema, the description covers purpose, prerequisites, response contents (account id/email and API key), and the crucial one-time-capture behavior. There is no ambiguity left for an agent to misuse the tool or lose the key.
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% because both parameters have descriptions in the schema (e.g., 'not a disposable domain', 'minimum 8 characters'). The description adds minimal parameter-specific meaning beyond restating these constraints; its extra value about the key pertains to the response, not the input parameters. Baseline 3 is appropriate when schema already documents parameters.
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 clearly states the tool creates a brand-new Verifly account and frames it as the self-onboarding mechanism, using the specific verb 'create' and naming the resource. It is clearly distinguished from sibling tools like get_account or buy_credits, which operate on existing accounts.
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 gives explicit context for when to use the tool ('this is how an agent self-onboards with no human in the loop') and notes key requirements (email/password, disposable domains rejected). However, it does not explicitly state when not to use it or compare to alternatives, though no sibling tool serves the same account-creation purpose.
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?
With no annotations, the description carries the full burden and does so thoroughly. It discloses the async behavior, immediate return with job_id/status/URLs, inline completion for small lists, pending status for large lists, polling requirements, and optional webhook notification.
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 convey purpose, behavioral details, polling flow, and webhook option with no filler. The first sentence front-loads the main action, and each subsequent sentence adds necessary context.
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?
Given no output schema, the description explains the return fields (job_id, status, URLs) and the job lifecycle, covering inline completion, polling, and webhook notification. It is complete for the tool's complexity and usage path.
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 description adds no new parameter semantics. It merely reinforces that webhook_url is optional and used for notification, while emails are the list to verify. This aligns with the baseline score for high schema coverage.
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 explicitly states the tool's function: 'Submit a list of email addresses as an asynchronous bulk verification job' and frames it as 'the right tool for large lists', distinguishing it from other verification tools like single-email checks or synchronous batch options.
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 clearly explains when to use this tool (large lists) and provides a workflow: returns immediately, poll get_job_status until completed, then call get_job_results. It doesn't explicitly name alternatives like verify_batch or verify_email, but the context strongly implies its use case.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It notes the synchronous nature and return of per-address verdicts, but does not mention credit consumption, rate limits, or whether the operation is read-only. This is a mid-level disclosure: some useful context is provided, but significant behavioral aspects remain unspecified.
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 two sentences, front-loaded with the core purpose, and includes both return behavior and size guidance. Every sentence contributes value, with no filler or 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?
Given the absence of an output schema, the description explains that a per-address verdict is returned, which provides a basic understanding of the results. It also covers scale limits and suggests an alternative for large batches. However, it does not elaborate on the exact verdict structure or how the exclude_* parameters affect results, leaving some gaps. Still, for a tool of this complexity, it is reasonably complete.
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 parameters are already well-documented. The description adds no additional parameter details beyond the schema; it only reiterates the 'list of email addresses' concept. Thus the baseline score of 3 applies, as the description does not go beyond schema-provided semantics.
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 clearly states the tool verifies a list of email addresses synchronously, and explicitly distinguishes itself from the bulk async endpoint for large lists. The verb 'verify' and resource 'list of email addresses' are specific and unambiguous.
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 provides explicit guidance on when to use this tool ('best for up to a few hundred') and when to use an alternative ('For very large lists use the bulk async endpoint instead'). This directly addresses usage context and alternatives.
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?
With no annotations, the description carries the full burden. It discloses the deliverability verdict, reason, flags (disposable, role account, catch-all, etc.), recommendation, and credit usage—giving a solid picture of behavior. It does not mention error handling or rate limits, but for a verification tool, it transparently indicates output and cost.
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 sentence, front-loaded with the core purpose ('Verify one email address in real time'), followed by a concise list of valuable outputs. Every clause adds meaningful detail without redundancy or fluff.
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?
Given one parameter, no annotations, and no output schema, the description covers the purpose, the return values (verdict, flags, recommendation), and the cost (credit usage). It could add error handling or timeout behavior, but for a straightforward verification tool, it is largely complete.
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 only parameter 'email' is described with an example ('e.g. lead@example.com'). The description adds no extra parameter semantics, but the parameter is self-explanatory, so the baseline score of 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?
The description states a specific verb and resource: 'Verify one email address in real time.' It clearly distinguishes itself from batch and list-cleaning tools by emphasizing the singular, real-time nature. It also enumerates key outputs (verdict, flags, recommendation, credit usage), making the tool's purpose unambiguous.
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 phrase 'one email address' and 'real time' implies this is for immediate single-address checks, which implicitly contrasts with batch tools like verify_batch. However, it does not explicitly name alternatives or state when not to use this tool, so it provides clear context but lacks explicit exclusions.
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?
With no annotations provided, the description discloses rate-limiting per IP and that it returns the same verdict as the full API. However, the rate limit is vaguely described as 'a few checks', which could be more precise.
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 concise with no extraneous words, front-loading the key value proposition (no account required). Every sentence adds value.
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?
Given no output schema, the description states the return matches the full API, providing adequate context. It could elaborate on the verdict format, but for a demo tool with a single parameter, it is fairly complete.
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 sole parameter 'email' has schema description 'The email address to verify, e.g. lead@example.com'. The description adds no extra meaning beyond the schema, and schema coverage is 100%, so 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?
The description clearly states the tool verifies one email without an account or API key, distinguishing it from the sibling verify_email tool that requires a key. The verb 'Verify' and resource 'one email address' are specific.
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 explicitly states when to use this tool (free demo, no key) and when not to (for real volume), and provides an alternative: register_account for a key then use verify_email.
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.