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?

Discloses cost (1 Fox Credit per uncached email) and checks performed, but no annotations exist. Missing details on rate limits, error handling, or 'uncached' definition.

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

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

Two sentences, front-loaded with purpose, then details and cost. 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?

No output schema, so description should clarify return values. Mentions quality score but incomplete (e.g., no mention of success/failure response, additional fields). Adequate but not fully comprehensive.

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 covers 100% with descriptions for both parameters. Description adds marginal value (cost note) but doesn't elaborate on parameter behavior 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 email deliverability and lists specific checks (syntax, MX, SMTP, etc.) and returns a quality score. It distinguishes from siblings like 'verify_emails' by specifying 'ONE 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?

Usage is implied (verify a single email), but no guidance on when to use this vs 'verify_emails' or 'find_email', and no exclusions or prerequisites mentioned.

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.