email-verifier

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

No annotations provided, but the description fully carries the burden: discloses generation of 50 permutations, SMTP verification, synchronous wait, return of best match or not_found, and cost. This exceeds minimal expectations.

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, each earning its place: purpose, method/behavior, and cost. Front-loaded with verb and resource. No redundancy.

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

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

Despite no annotations or output schema, the description covers input semantics, process (generating, verifying, returning), cost, and possible output 'not_found'. Complete for a single-email finder with good 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 coverage is 100%, so baseline is 3. Description adds value by noting middle_name is 'Optional middle name for more permutations', which explains its behavioral effect beyond 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?

Description explicitly states it finds ONE person's business email from name and company domain, clearly distinguishing it from sibling 'find_emails' which suggests multiple results. The verb 'Find' and resource 'business email' 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?

Implies usage for single email lookup but does not explicitly state when to use this tool versus alternatives like verify_email or find_emails. Mentions 10 Fox Credits cost, which is relevant for cost-aware selection.

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, so description carries full burden. Discloses submission, wait, return of emails or jobId, and billing. Sufficiently transparent for a read-heavy but mutating (credit-burning) 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?

Three concise sentences, front-loaded with purpose, no filler. Efficiently conveys all key behaviors.

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?

Describes return value (email or jobId), limits, and billing. No output schema, so description adequately covers expected response. Lacks error behavior explanation but still complete enough.

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 description adds minimal value. It mentions 'name + company domain each' clarifying the pattern, but no extra detail beyond schema. Baseline 3 justified.

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?

Clear purpose: bulk-finds business emails for a list of contacts, each with name and company domain. Distinguishes from sibling 'find_email' by specifying list processing and bulk nature.

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?

Describes usage context: up to 1000 contacts, charges 10 Fox Credits per contact, and async polling with jobId for large lists. Lacks explicit when-not-to-use or alternatives, but provides sufficient guidance.

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 provided, so description carries full burden. Discloses that it is free ('no credits charged') and implies read-only. Could mention rate limits or response format, but adequate for a simple balance check.

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 front-loading purpose and key behavioral trait. Every sentence adds value with 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?

Covers purpose, cost, and usage context. Lacks specification of return format (e.g., data type), but for a balance check the expected result is simple enough that missing output schema doesn't severely hinder usability.

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?

No parameters exist, schema coverage 100%. Baseline of 4 applies; description adds no parameter info because none needed.

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

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

Uses specific verb 'Get' and resource 'Fox Credit balance' with account context. Clearly distinguishes from sibling tools that perform verify/find operations.

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 states when to use: 'check remaining balance before a big verify/find run'. Provides credit costs for sibling tools, guiding the agent on planning.

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 full burden. It discloses that the tool returns results if finished or status otherwise, indicating a non-destructive, read-only behavior. No hidden side effects are implied.

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 with no wasted words. The main purpose is front-loaded, and guidance follows directly. Every sentence serves a clear purpose.

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 simplicity of the tool and good annotations (though none), the description covers primary functionality. It could mention that job_id is returned by the parent tools, but it's implied. No output schema exists, so explaining return values is sufficient.

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%, but the description adds value by connecting parameters to the submitting tools ('Job ID from verify_emails...' and 'type shown in the submitting tool's response'), which is not in 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 it checks async jobs started by verify_emails, find_email, or find_emails. It specifies what it returns (results or status), distinguishing it from the sibling tools that initiate jobs.

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 tells when to use the tool (after starting a job with those tools) and how to determine the 'type' parameter. It lacks explicit when-not-to-use instructions, but the context makes it clear there are no direct alternatives within this group.

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 well: it discloses that each call costs 1 Fox Credit, that a repeat within 24 hours is answered from a result cache yet still billed, and that the return includes a 0-100 quality score. It does not cover auth/prerequisite requirements or failure/timeout behavior, which keeps it short of full transparency.

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 with no filler: purpose, method, and return shape come first, then the billing and cache caveat. Every sentence earns its place and the cost caveat is front-loaded enough to matter before invocation.

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, and the description compensates by stating the return is a 0-100 quality score, plus the billing and cache semantics an agent needs before calling. Missing details are error handling and what the score thresholds mean, but the essentials are covered for a two-parameter tool.

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

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

Schema description coverage is 100%, so both parameters (email and proxy) are already documented in the schema. The description adds nothing parameter-specific beyond stressing a single address, so it neither helps nor harms relative to the baseline 3.

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

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

The description names a specific verb (verify) and resource (ONE email address) and enumerates exactly what is checked (syntax, MX, SMTP, catch-all, disposable, free-provider, role). The capitalized 'ONE' signals the single-address scope and implicitly contrasts with the plural sibling verify_emails, though no sibling is named outright.

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 context is implied by 'ONE email address' and the per-check credit price, which suggests this is the single-address path while verify_emails handles batches. However, the description never explicitly says when to prefer a sibling or when not to use this tool, leaving the routing to inference.

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 fully discloses behavior: submits entire list, waits for completion (or returns jobId), returns one result per email, charges per email, and recommends polling for large lists. No contradictions.

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, each adding value: purpose, behavior/pricing, and fallback for large lists. Front-loaded and 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?

Given lack of output schema, description covers input, behavior, and output format (same as verify_email). It mentions pricing and polling but omits error handling or rate limits. Still reasonably complete for a bulk verification tool.

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

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

Schema coverage is 100% with parameter descriptions. The description adds context on 'wait' behavior (default true, set false to get jobId) and implies email array is a list, but does not add new constraints beyond 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 verifies a list of emails (bulk), using specific verbs and resource. It distinguishes from siblings like verify_email (single) and find_emails (search).

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 'Best for cleaning lead lists' and mentions polling with get_job for large lists. It implies use for bulk but does not explicitly exclude single email verification (use verify_email) or when not to use it.

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