Email List Validation Email Verification

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

With no annotations, the description carries the full behavioral burden. It usefully implies this is a side-effect-free estimate that precedes billing, but it never states whether the estimate call itself consumes credits, what permissions are needed, or how the result should be interpreted. This leaves real gaps for a billing-adjacent 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 sentences, front-loaded with the purpose and closing on the action directive, with no filler. Minor redundancy in re-listing the input modes that the schema already enumerates keeps it out of the top band.

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 covers the three input modes and the when-to-use trigger, which is solid for a parameterized tool. However, with no output schema and no annotations, it never says what the estimate returns (a number? a boolean affordability flag?) or its units beyond the schema's credit hints, so an agent lacks a complete picture of the response.

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 documents emails (1 credit each), list_id, and the operation enum with its per-type credit rates. The description's restatement of the three mutually exclusive input modes adds only selection guidance, not new parameter meaning. 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 ('estimate the credit cost of a verification') plus a secondary outcome ('whether the user can afford it'). The word 'before running it' implicitly contrasts this with the sibling tools that actually perform verification (verify_email, verify_batch), letting an agent tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Always quote this before proposing anything billable' is an explicit, actionable trigger that tells the agent exactly when to reach for this tool. It stops short of a 5 because it never names a specific alternative or a when-not condition (e.g., don't call this before a free read like get_credit_balance).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the disclosure burden, and it does describe the output shape (plain-English explanation plus a send recommendation) without an output schema to lean on. It omits any note on side effects or scope limits, but as a pure lookup/explanation operation that gap is minor.

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 purpose sentence followed by the supported-value list and the usage trigger, with no filler. The long enumeration is dense but it earns its space by preempting invalid input attempts.

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, annotation-free tool with no output schema, the description supplies purpose, input vocabulary, and expected return content. What remains missing is only trivial (permissions, whether unknown terms error), which is not essential for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds value beyond the schema by enumerating the supported vocabulary (valid, invalid, catch-all, greylisted, disposable, role, spam-trap, no-mx, etc.). That enumeration helps an agent know which inputs will be meaningful rather than guessing.

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 (explain) and resource (verification status/reason), and defines the output as a plain-English meaning plus a send recommendation. The enumerated status vocabulary makes it immediately distinguishable from siblings like verify_email or verify_batch, which perform verification rather than interpret its 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?

Gives a clear trigger condition: use when a user asks what a result means. It does not name when-not-to-use or an alternative tool, but no sibling overlaps this interpretive role, so the routing guidance is sufficient in practice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 well: it discloses the cost model (free, no account), a concrete rate limit (25 email verifications per day), the one-time nature of the return ('Returns the key once'), and the exact authentication usage ('Authorization: Bearer <api_key>'). These are non-obvious traits an agent could not infer from 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?

Three tight sentences, front-loaded with the core action and cost, followed by the optionality caveat and the critical one-time-return/auth detail. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations and no output schema, the description covers the important unknowns: what you get back (a key), that it is returned only once, and how to use it. It stops short of key lifetime, revocation, or what happens on a repeat call, which would complete the picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and all three parameters (name, contact, purpose) are documented in the schema, so the baseline is 3. The description adds no parameter-level 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?

States a specific verb and resource ('Get your own free API key for this server') and immediately clarifies scope: it is for your own quota and the list tools, which distinguishes it from the sibling verification tools that run on a shared trial. An agent can tell what this does without opening 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?

Explicitly frames the tool as optional ('the verification tools already work without a key on a shared trial'), which is real when/when-not guidance for an agent deciding whether to call it. It does not name a specific alternative sibling tool by name, keeping it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full behavioral burden. It does convey that this is a read that returns progress and status, but it discloses nothing about auth requirements, rate limits, whether a completed job stops reporting, or error behavior for an unknown id. Adequate but thin for a tool whose entire value is the status payload.

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 front-loaded sentence with no filler; the resource and the identifying key come first. It is efficient, though it leaves room it could have used for the id's provenance without becoming bloated.

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 (one required integer, no nested objects, no annotations, no output schema). Because there is no output schema, the description should describe what 'progress and status' contain, but it does not. It is minimally sufficient to invoke, not sufficient to interpret the result.

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 0%, so list_id has no documentation in the schema and the description must compensate. 'by id' weakly identifies the required integer, but it never says the id comes from a previous verify_batch submission or list_lists call, which is the one piece of semantics an agent actually needs.

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: retrieving progress/status of a bulk verification job by id. This is clearly distinct from the write-oriented sibling verify_batch and the list-oriented get_list/list_lists. It stops short of explicitly naming where it sits relative to those siblings, but the purpose 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?

There is no when-to-use guidance and no mention of alternatives. An agent must infer that this is a polling tool used after verify_batch submits a job, and nothing hints at whether it is cheap to call repeatedly or how it relates to get_list. Only the phrase 'by id' implies a prerequisite.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden. 'Get' implies a safe read with no side effects and it discloses the shape of the response (balance + usage summary), which is useful. However it says nothing about authentication requirements, whether the balance is live or cached, rate limits, or units of the balance, all of which an agent would benefit from knowing.

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 front-loaded sentence with no filler; the primary purpose (credit balance) appears before the secondary detail (usage summary). Nothing is wasted.

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 getter with no output schema, the description gives enough to call it correctly and hints at the return payload. It could be stronger by clarifying what the 'usage summary' includes or the units of the balance, but nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the baseline there is no parameter semantics to document. There is nothing for the description to add or compensate for here.

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 ('Get the current credit balance') plus a secondary return ('short usage summary'), so the agent knows exactly what it retrieves. It does not differentiate itself from related siblings like estimate_cost or explain_result, which would be needed for 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?

The description says what the tool returns but never states when to reach for it versus alternatives such as estimate_cost (which likely also touches credits). No prerequisites, preconditions, or exclusions are given; usage is only inferred from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full disclosure burden. 'Get' implies a non-mutating read, but it says nothing about error behavior for unknown ids, whether the list must be finished/verified to return meaningful data, or what the returned 'details' comprise.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the verb and resource, with no filler. It is appropriately sized for a one-parameter lookup, though it is terse enough that any added context was clearly cut rather than omitted for brevity.

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 single-entity read with 100% schema coverage and no output schema, the definition is minimally adequate. The absence of an output schema means the description should ideally sketch what 'details' are returned, and it does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter list_id is fully documented in the schema, so baseline 3 applies. The description only restates 'by its id' and adds no format, source, or lookup guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('details of a single bulk verification list'), scoped to one entity by id. It distinguishes itself implicitly from the sibling list_lists by emphasizing 'single', but never names or contrasts that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'By its id' implies you must already have a list_id, which hints at the post-creation/post-listing retrieval workflow. However, there is no explicit when-to-use statement, no mention of list_lists as the way to obtain the id, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

No annotations are provided, so the description carries the full disclosure burden. It adds the ordering behavior ('most recent first') and implies per-user scoping ('the user's'), but says nothing about pagination behavior, auth requirements, rate limits, or what happens beyond the limit.

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 front-loaded sentence with zero filler; the resource and the ordering constraint are both stated immediately and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only list tool with one optional parameter this is minimally adequate, but with no annotations and no output schema the description should describe the shape of a returned list item and any pagination, which it omits.

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%: limit is fully documented with its default, minimum, and maximum. The description adds no format or semantics beyond what the schema already provides, 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 (List) and resource (the user's bulk verification lists/jobs) plus an ordering guarantee, which is clear enough to distinguish it from a detail-fetch sibling. It does not explicitly differentiate itself from the closely named get_list sibling, so it falls 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?

No when-to-use guidance, no exclusions, and no mention of the get_list alternative for fetching a single list's details. Usage is only implied by the verb and the plural resource.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the load well: it discloses the 25-email cap, the agent-key requirement, a persistent side effect (saves a list), and a cost model (1 credit per email). It stops short of clarifying whether processing is synchronous or must be polled via get_batch_status.

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 compact sentences, each carrying distinct information (cap, return/side effect, cost), with nothing redundant or padded.

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 2-param tool with no annotations and no output schema, the description covers limits, billing, and the save side effect. The main gap is not relating it to the async get_batch_status flow.

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 both parameters (name, emails) are already documented. The description only echoes the emails array with a size cap, adding little beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (verify) plus resource (batch of email addresses), and the batching scope naturally distinguishes it from the single-address sibling verify_email. An agent can tell what it does without opening 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?

The 'up to 25 per call' and 'agent key' constraint implies bulk usage, but the description never states when to prefer this over verify_email or the other siblings (estimate_cost, get_batch_status). Usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

With no annotations, the description carries the full burden and does disclose two behavioral facts beyond the schema: the possible return verdicts (valid, invalid, risky, unknown) and the cost of 1 credit. It omits auth requirements, rate limits, and latency, so it is strong but not exhaustive.

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 short sentences with zero waste: purpose first, then return shape and cost. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description enumerates the possible verdicts, which is the key return information an agent needs. Cost is also stated. Only secondary details like error behavior or auth prerequisites are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single well-documented parameter, so the baseline of 3 applies. The description adds no syntax, format, or validation detail beyond what the schema already states.

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 (verify) and resource (email address deliverability) with the scope qualifier 'single', which implicitly separates it from the sibling verify_batch. An agent can route correctly without opening 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?

Usage is implied by the 'single email address' scope, which hints that bulk work belongs to verify_batch, but no alternative is named and no when-not conditions or prerequisites are given. Adequate but leaves routing inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.