ClearBounce Email Verification

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

Even with annotations already marking the tool as read-only and idempotent, the description adds valuable behavioral context: the tool is free, reports progress and summary counts, and the full result file lives in the ClearBounce dashboard. This goes well beyond the annotations without contradicting them.

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 compact and front-loaded with the core purpose, then follows with return behavior and user-facing guidance. Every sentence earns its place with no filler or repetition of the title or annotations.

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 tool with an output schema and safety annotations, the description is complete: it explains what the job is, what statuses/progress will be returned, how to present results, and where to find the full output file. An agent has everything needed to select and invoke the 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 for the single parameter is 100%, and the schema already states that jobId is 'The jobId returned by verify_bulk.' The description reinforces that connection but does not add meaningfully new parameter detail beyond the schema.

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

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

The description states a specific verb and resource: 'Check the progress of a bulk verification job started with verify_bulk.' It clearly identifies this as the status-checking counterpart to verify_bulk, distinguishing it from siblings like verify_email, find_email, and check_credits.

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

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

The description clearly indicates the tool is for jobs 'started with verify_bulk,' which effectively conveys when to use it. It also gives post-call guidance to report the summary to the user instead of individual addresses, though it does not explicitly list when not to use it or compare it to sibling tools.

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?

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds meaningful context by specifying 'Free', indicating the call does not consume verification credits, and clarifies the account scope tied to the API key. This goes beyond the structured annotations.

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 one concise sentence that front-loads the key action and resource, then adds the account context and cost implication. 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 read-only tool with a full output schema available and annotations covering safety, the description is complete. An agent can confidently invoke this tool without additional information.

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

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

There are zero parameters and the schema is trivially empty, so the baseline is 4. The description adds relevant context by explaining that the balance is tied to the API key's account, which makes the absence of parameters sensible and complete.

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 clear verb ('Return'), a specific resource ('remaining verification credit balance'), and the owning context ('the account that owns the API key'). It is immediately distinguishable from sibling tools like verify_email and verify_bulk, which perform verification operations rather than balance checks.

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

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

The description provides clear context about what the tool does, but it does not explicitly state when to use it relative to alternatives or mention any exclusions. Usage is implied rather than directly guided, though the purpose is narrow enough that ambiguity is low.

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?

Beyond the readOnly and idempotent annotations, the description discloses that candidates are unverified pattern-based guesses, that finding is free while verification costs credits, and that the tool should not verify without user approval. This is substantial behavioral context that the agent would otherwise lack.

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 front-loaded with the core purpose, then efficiently covers return behavior, cost implications, and the required verification workflow. Every sentence delivers essential operational information without padding.

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 two fully documented parameters and an output schema, the description covers purpose, result nature, cost, consent, and the exact follow-up action with verify_email. No critical operational detail is missing for an agent to call it 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 input schema already fully describes both parameters with examples, so the description's mention of full name and company domain adds limited new meaning. It reinforces the source fields but does not introduce additional parameter-level semantics beyond what the schema 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 opens with a specific verb and resource: find a person's business email from full name and company domain. It clearly differentiates the tool from verify_email by describing find as generating pattern-based candidates rather than confirming deliverability.

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 workflow guidance: show candidates, inform the user about credit costs, ask before verifying, then call verify_email one at a time by confidence until a deliverable result is found. This makes the tool's role relative to verify_email and the approval process unambiguous.

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?

Beyond annotations, the description discloses that the job runs asynchronously in the background, takes roughly 1-10 minutes, costs 1 credit per unique address, deduplicates for free, and returns a jobId rather than immediate results. It also reveals a meaningful side effect (credit consumption) and the need for user confirmation, which annotations alone do not 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?

The description is compact but information-dense. Purpose, accuracy benefit, cost model, async behavior, and follow-up action each appear in tight prose, and the most critical facts are front-loaded.

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 an output schema, the description covers everything needed to call it correctly: constraints, cost, async return, follow-up status polling, and user-confirmation guidance. It also distinguishes the tool from the sibling verify_email tool without needing further context.

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 the emails parameter and its 2-to-10,000 item range at 100% coverage, so the baseline is 3. The description adds valuable semantics beyond the schema: duplicates are removed for free and cost is calculated per unique address, so an agent understands the real meaning of the list contents.

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 opens with a specific verb and resource: 'Verify a list of email addresses (2 to 10,000) as one bulk job.' It also differentiates from single-address verification by highlighting the bulk pipeline's per-domain caching and greylist retries, so an agent can see why this tool exists apart from verify_email.

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 explains when to choose bulk verification over one-by-one verification and names the follow-up tool, check_bulk_status, with the jobId. It also gives a clear behavioral instruction to confirm with the user before spending many credits, which is a strong usage guideline.

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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds meaningful behavioral context beyond annotations: real-time execution, live mailbox check, detailed result structure, and the 1-credit cost per call. No contradiction with annotations exists.

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

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

Three sentences with no filler. The core action and key differentiator ('single email address') are front-loaded, followed by output details and cost. 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?

Given the single parameter, high schema coverage, comprehensive annotations, and presence of an output schema, the description covers all essential operational context: what it does, what it costs, and what it returns. Nothing critical is missing for an agent to invoke it 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 description coverage is 100%, so the parameter is already well documented with an example. The description adds 'single' and 'live mailbox check' but does not meaningfully extend the semantic understanding of the email parameter beyond what the schema provides. 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 uses a specific verb ('verify') with a clear resource ('a single email address') and states the mechanism ('live mailbox check'). The word 'single' explicitly differentiates it from the sibling tool verify_bulk, making its purpose unmistakable.

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 the tool is for verifying a single email address in real time, which signals when to use it over verify_bulk or find_email. However, it does not explicitly mention alternatives or state when-not-to-use conditions, so it stops short of full routing guidance.

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