Verify email addresses before you send: single, batch (50) and bulk lists (10,000).
Scored across 10 tools
Most tools target clearly distinct actions (single vs. batch verify, job creation vs. continuation vs. status/summary/CSV/delete), and descriptions explicitly state boundaries such as '1-20 addresses' vs. '21+ or file use create_bulk_job'. The main soft overlap is get_bulk_csv vs. get_bulk_summary, which both deliver job results and a download link, though the ≤2000-address / summary-only distinction is spelled out.
All ten tools follow a consistent snake_case verb_noun pattern (verify_email, create_bulk_job, get_bulk_status, list_bulk_jobs, delete_bulk_job). The singular/plural pair verify_email/verify_emails is a regular, predictable variant rather than a convention break.
Ten tools is well within the sweet spot and each maps to a real step in the verification workflow: single verify, small batch, bulk job creation/continuation, polling, summary, CSV export, listing, deletion, and credit check. No tool appears redundant or pad the surface.
The domain lifecycle is well covered: verification at all scales, bulk job create/append, status polling, summary and CSV retrieval, listing, deletion, and credit balance. The notable gap is any way to cancel an in-flight bulk job (only delete after completion), which an agent may want for long 100k-address jobs.
Send the next part (up to 5000 addresses) of a list started with create_bulk_job and parts_total. After the last part the whole list is deduplicated and uploaded (one job per 100000 addresses), and the answer is the same as create_bulk_job's. Consumes credits only when the last part starts the job(s).
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses of this part (1 to 5000) | |
| upload_session | Yes | upload_session returned by create_bulk_job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint and non-idempotent, and the description adds valuable side-effect context: deduplication, one job per 100000 addresses, credits consumed only when the last part triggers the job. It does not cover retry behavior or what happens if a part is resent (important given idempotentHint=false), leaving a small 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 dense sentence, front-loaded with the action and cap, then the terminal behavior and credit rule. Efficient, though the packed clause structure (three ideas in one sentence) is slightly harder to scan than separated points.
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?
Covers the sequencing contract, side effects, billing trigger, and points to create_bulk_job for the return shape, which compensates for the absent output schema. A brief note on failure/retry semantics for a non-idempotent append would make it fully 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 both parameters are already documented, including the 1-5000 range and the uuid format. The description only restates the 5000 cap and implies the upload_session provenance, which the schema already states — 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 ('Send the next part... of a list') and pins its scope with the 5000-address cap. It clearly distinguishes itself from create_bulk_job by being the continuation step, and even explains the terminal behavior (dedup + upload).
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 names the prerequisite (a list started with create_bulk_job and parts_total) and the terminating condition ('after the last part'). An agent knows exactly where this tool sits in the workflow and when to stop calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an asynchronous verification job. Use it for 21 or more addresses, or for ANY file the user attaches (read the addresses from the file). Up to 100000 addresses per call. Consumes one credit per unique address and the account needs enough credits for all of them (check with get_credits and tell the user the number before starting). Duplicates and lines that are not addresses are removed first. Lists larger than 10,000: suggest uploading the file on the dashboard (https://dashboard.easyemailverification.com/bulk-email-verification). If the user prefers the chat, send the list in parts of up to 5000: call this tool with parts_total and the first part, then append_bulk_emails with each other part; lists over 100000 become several jobs. Returns list_id (or jobs) and message_for_user: tell the user the job id, that you will report the status every 30 seconds, and the dashboard link. Then call get_bulk_status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name of the list in English, shown in the dashboard (a list split into several jobs becomes "List <name> 1 of N"…) | |
| emails | Yes | Email addresses to verify (1 to 100000); with parts_total, the first part (up to 5000) | |
| parts_total | No | Only to send a large list in parts: the total number of parts of up to 5000 addresses, this call included |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the credit cost model (one credit per unique address), that the account must hold enough credits for the whole list, that duplicates and non-address lines are stripped before processing, that the call is asynchronous, and that a job may split into several jobs. It also specifies the return payload and the obligation to report status every 30 seconds. None of this is inferable from readOnlyHint=false / destructiveHint=false alone.
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?
Purpose, threshold, and alternatives are front-loaded, and nearly every sentence carries operational content (cost, splitting, return values, next call). It is on the long side and the dashboard URL plus multi-step chat instructions add density, but there is little 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 mutating, credit-consuming, asynchronous tool with no output schema, the description covers what the agent needs: prerequisites (credits), batching strategy for large inputs, return values (list_id / jobs, message_for_user), and the mandated follow-up call. Nothing essential to correct invocation is left out.
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 already 100%, so the baseline is 3; the description earns an extra point by explaining the cross-call workflow for parts_total (first part here, remaining parts via append_bulk_emails, up to 5000 per part, lists over 100000 becoming multiple jobs) and by tying name to the dashboard display. It mostly reinforces the schema rather than adding new per-parameter syntax.
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 up front: 'Start an asynchronous verification job.' It then distinguishes itself from siblings by threshold (21+ addresses) and by input type (any attached file), which separates it from verify_emails and append_bulk_emails without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit decision rules: use this for 21+ addresses or any attached file; for lists over 10,000 suggest the dashboard; if the user prefers chat, split into parts of 5000 with parts_total then append_bulk_emails. It also names the prerequisite check (get_credits) and the follow-up call (get_bulk_status), so the agent knows both when to use it and what comes before and after.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a bulk job and its results (they are also deleted automatically 30 days after upload). Cannot be undone; confirm with the user first. Credits are not refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Job id (list_id) returned by create_bulk_job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint annotation: discloses that results are deleted too, that the same happens automatically 30 days after upload, that the action is irreversible, and that credits are not refunded. These are exactly the consequences an agent needs before committing to a destructive call.
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 with no filler; the permanence and cascade are front-loaded, and each sentence contributes a distinct consequence or safeguard.
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 destructive tool with annotations covering safety hints, the description supplies the missing business consequences (refund policy, auto-expiry) and a confirmation requirement. Nothing needed to call it safely is absent.
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 list_id description already tells the agent it is the job id returned by create_bulk_job. The description adds nothing about the parameter, so the baseline of 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 ('permanently delete a bulk job and its results') and clarifies the cascading scope. Siblings are create/get operations, so the destructive nature is 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?
Explicitly instructs the agent to 'confirm with the user first' before invoking, which is actionable pre-call guidance. No alternative tool is named, but none of the siblings offers deletion, so the routing gap is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The complete results file (CSV) of a completed bulk job, for jobs of up to 2000 addresses: hand it to the user as a .csv file. Larger jobs only get download_url. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Job id (list_id) returned by create_bulk_job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds context annotations cannot: the 2000-address cap, the degraded behavior for larger jobs, and that the call is free of credit cost. It omits what happens if the job isn't complete (error vs. partial), but the behavioral picture is otherwise solid.
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 resource and scope, then the size cutoff, then the downstream instruction, with no filler. "Free." is a fragment but it carries real decision-relevant information.
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?
There is no output schema, so the description must carry the return semantics; it does state that the payload is a CSV meant to be surfaced as a file. It remains unclear whether the tool returns a string, a URL, or an attachment object, and what happens for an unfinished 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?
With one parameter at 100% schema description coverage, the schema already explains list_id and its provenance from create_bulk_job. The description adds no further meaning about the parameter, 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 names a specific resource (the complete results CSV of a completed bulk job) and a verb-like action ("get" / "hand it to the user as a .csv file"), which is more than a restatement of the title. It implicitly contrasts with get_bulk_summary by stressing "complete results file," but no sibling is named explicitly, so it falls short of full differentiation.
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?
"For jobs of up to 2000 addresses" plus "Larger jobs only get download_url" gives an explicit use condition and an explicit non-use condition with the alternative mechanism. It does not say to confirm job completion via get_bulk_status first, which is a meaningful precondition left implied by "completed bulk job."
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status (queued, processing, completed, failed, not_enough_credits), progress in percent and counters of a bulk job. Free. Waits up to wait_seconds (default and maximum 30) and answers as soon as the job ends. After each answer, show the status and progress to the user and call it again, until completed, failed or not_enough_credits. After 10 minutes, stop, give the user the dashboard link and tell them to ask for the job status later.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Job id (list_id) returned by create_bulk_job | |
| wait_seconds | No | Seconds to wait for the job to end before answering (0 to 30, default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, but the description adds behavior beyond them: it is free, it long-polls for up to wait_seconds (default and max 30), and it answers immediately when the job ends. It also discloses the 10-minute polling cutoff and the fallback action, none of which is derivable from the structured fields.
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 return payload is front-loaded in the first sentence and every subsequent sentence is actionable rather than filler. It is a dense run of imperative clauses, though, and the wait_seconds default/max restatement is redundant with the schema.
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?
There is no output schema, so the description carries the burden of describing return values, and it does so concretely (status enum, percent, counters). Combined with the polling loop and cutoff guidance, an agent has everything needed to invoke and re-invoke 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 the baseline is 3; the description goes further by explaining that wait_seconds causes the call to block until the job ends or the timeout elapses, which is the semantic an agent needs to choose a value. The '(default and maximum 30)' phrasing slightly duplicates the schema's minimum/maximum rather than adding new detail.
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?
It states a specific resource (a bulk job identified by list_id) and enumerates the exact payload the agent gets back: status values (queued, processing, completed, failed, not_enough_credits), percent progress, and counters. It does not, however, contrast itself with siblings such as get_bulk_summary, get_bulk_csv, or list_bulk_jobs, leaving the agent to infer which one it wants.
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 explicit operational flow: call, show status/progress to the user, call again, repeat until completed/failed/not_enough_credits, and stop after 10 minutes with the dashboard link. Both the continue condition and the termination condition are stated, which is exactly the guidance a polling tool needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Totals of a completed bulk job by result and reason, risk flags, at most 50 example rows (invalid and risky addresses first) and download_url, a link to download the CSV with all results. Never returns the whole list. ALWAYS give the user the download_url link. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Job id (list_id) returned by create_bulk_job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, and the description adds real behavioral context on top: results are capped at 50 rows, invalid and risky addresses are ordered first, the full list is never returned, and the call is 'Free' (no credit cost, meaningful given the get_credits sibling). This is exactly the kind of truncation and cost disclosure annotations cannot convey.
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 return contents, and every clause (row cap, ordering, never-full-list, download_url, 'Free') carries information. The first sentence is a long run-on that stacks five facts into one breath, which slightly hurts scanability.
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 does the work of describing the return shape (totals by result/reason, risk flags, sample rows, download_url) very well. It leaves one gap: what happens if the job is not yet complete or the list_id is invalid — the only failure mode an agent might hit.
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?
Only one parameter (list_id) with 100% schema description coverage that already maps it to create_bulk_job. The description adds no format, range, or edge-case meaning 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?
Specific verb (summarize/total) plus resource (completed bulk job results, by result and reason) plus the exact return payload: counts, risk flags, capped example rows, download_url. The clause 'Never returns the whole list' cleanly separates it from get_bulk_csv and get_bulk_status.
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 'completed bulk job' implicitly scopes usage to post-completion and the sibling get_bulk_csv covers full downloads, so the boundary is inferable. It also gives a direct instruction ('ALWAYS give the user the download_url link'), but never explicitly says to use get_bulk_status while the job is still running or names get_bulk_csv as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remaining Easy Email Verification credits of the account that owns the API key. Free: does not consume credits. Use it before large verifications to check the balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds genuinely new facts — that the call is free, does not consume credits, and is scoped to the API key's owning account. It doesn't say whether the value is live or cached, which is a minor remaining 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?
Three short sentences with zero waste: scope first, cost profile second, recommended usage last. Nothing repeats the title or the schema.
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, annotation-heavy tool this covers what an agent needs to decide and call it. The only soft spot is return shape — there is no output schema, and the description says 'remaining credits' without indicating the unit or whether a plan/quota breakdown comes back.
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 no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly makes clear that no account identifier is needed because the API key determines the account.
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?
Names the specific resource (Easy Email Verification credits), the exact scope ('of the account that owns the API key'), and a distinguishing property (free, non-consuming). It is a noun phrase rather than a verb, relying partly on the title 'Get remaining credits' for the action, which keeps it just short of a 5.
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 an explicit trigger: 'Use it before large verifications to check the balance.' That tells the agent when to call it, but it offers no when-not condition and doesn't reference any alternative (e.g., bulk job status endpoints that might also report consumption).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk jobs of this account with their status (results are kept for 30 days). Use it when the user asks about a job without giving its id. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful context beyond annotations: results are retained for 30 days and the call is free, which helps an agent reason about freshness 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?
Three short clauses, each earning its place: resource scope, retention, usage condition, and cost. It is front-loaded and contains 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 listing tool with no output schema and strong annotation coverage, the description supplies the key missing context: retention and when to choose it. It does not describe return ordering or pagination, but those are minor gaps here.
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, so the baseline is 4. The description appropriately does not waste space describing nonexistent inputs.
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 identifies the resource (bulk jobs of this account) and adds useful scope (their status, retention period), though it uses a noun phrase rather than an explicit verb. It differentiates itself from ID-based status lookup by saying to use it when the user asks about a job without giving its id.
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 a clear triggering condition: use when the user asks about a job without providing an id. It does not explicitly name get_bulk_status as the alternative when an id is available, but the exclusion is strongly implied.
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 Easy Email Verification (syntax, domain, MX, mailbox, disposable, role and catch-all checks). Consumes one credit.
Read "result": valid, invalid or unknown. "unknown" means no reliable conclusion: treat it as neither valid nor invalid. "safe_to_send" is the overall recommendation; "disposable", "role", "free" and "accept_all" are signals for the user's own policy; "did_you_mean" suggests a typo fix. "success": true only means the request was processed.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond annotations: the credit cost of each call, the three-valued meaning of "result" including the crucial caveat that "unknown" is neither valid nor invalid, and the warning that "success": true only means the request was processed. That last point is a non-obvious trap an agent would otherwise fall into.
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-loads what the tool does and its cost, then spends the second paragraph on output interpretation, which is genuinely necessary given there is no output schema. Every clause (including each named result field) carries distinct meaning; nothing is redundant.
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 takes on the full burden of explaining return values and does so field by field, including the ambiguous "unknown" case and the misleading "success" flag. An agent has everything needed to call the tool and interpret the response 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?
There is exactly one parameter and schema description coverage is 100%, so the schema already carries the meaning ("Email address to verify"). The description adds nothing about format, normalization, or constraints such as the 320-character limit, 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 ("Verify one email address") and enumerates the checks performed (syntax, domain, MX, mailbox, disposable, role, catch-all), which tells the agent exactly what the tool does. The word "one" implicitly distinguishes it from the plural sibling verify_emails without needing the 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?
Gives clear operating context: single-address scope and "Consumes one credit", which lets an agent reason about cost versus the bulk siblings. It stops short of explicitly naming verify_emails as the alternative for multiple addresses, so the routing to siblings is implied 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 1 to 20 email addresses in one call with Easy Email Verification. Consumes one credit per address. Returns one result per address, with the same fields as verify_email (treat "unknown" as neither valid nor invalid). For 21 or more addresses, or any file the user attaches, use create_bulk_job instead; never split a larger list into several verify_emails calls.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to verify (1 to 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real value beyond annotations: one credit consumed per address (a cost signal), one result per address, and the tri-state meaning of "unknown". Gaps remain on partial-failure behavior (does one bad address fail the whole batch?) and any rate/auth constraints, which matter for a non-idempotent, open-world 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?
Three tightly packed sentences: capability and cost first, then return shape, then the escalation rule. Zero filler and the most decision-relevant constraint (size limit → sibling tool) is not buried.
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 still explains the return contract (one result per address, same fields as verify_email, "unknown" semantics), and it covers the cost and routing model. An agent can call this correctly and knows what to do with oversized inputs.
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 already documents the 1-to-20 range and item constraints, so the schema carries the burden. The description only restates the batch bound and adds that results align one-per-address, which is marginal over 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 email addresses), the batch size bound (1 to 20), and names the provider. It is clearly distinguishable from verify_email (single) and create_bulk_job (large batches/files) without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: use create_bulk_job for 21+ addresses or any attached file, and an explicit prohibition against splitting a large list across multiple calls. Both the when and the when-not are stated with the alternative named.
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.
append_bulk_emailscreate_bulk_job4 fields changedInput schema / properties / emails / descriptionPrevious value: -"Email addresses to verify (1 to 10000)"New value: +"Email addresses to verify (1 to 100000); with parts_total, the first part (up to 5000)"Input schema / properties / emails / maxItemsPrevious value: -10000New value: +100000Input schema / properties / name / descriptionPrevious value: -"Optional name of the list, shown in the dashboard"New value: +"Optional name of the list in English, shown in the dashboard (a list split into several jobs becomes \"List <name> 1 of N\"…)"Input schema / properties / parts_totalAdded value: +{
+ "description": "Only to send a large list in parts: the total number of parts of up to 5000 addresses, this call included",
+ "maximum": 200,
+ "minimum": 1,
+ "type": "integer"
+}get_bulk_csvget_bulk_status1 field changedInput schema / properties / wait_secondsAdded value: +{
+ "description": "Seconds to wait for the job to end before answering (0 to 30, default 30)",
+ "maximum": 30,
+ "minimum": 0,
+ "type": "integer"
+}list_bulk_jobsverify_emails2 fields changedInput schema / properties / emails / descriptionPrevious value: -"Email addresses to verify (1 to 50)"New value: +"Email addresses to verify (1 to 20)"Input schema / properties / emails / maxItemsPrevious value: -50New value: +20create_bulk_jobdelete_bulk_jobget_bulk_statusget_bulk_summaryget_creditsverify_emailverify_emailsVerify emails: syntax, MX, SMTP mailbox, disposable, role and catch-all checks. Single and bulk.
Verify email addresses in bulk: syntax, domain, MX, disposable and role addresses, SPF and DMARC
Real-time single and bulk email validation (syntax, MX, 5,000+ disposable domains, SMTP).
Check whether an email address is real and will accept mail before you send to it.
Add one secure layer between your agents and this server.