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

No annotations provided, so description is the sole source. Mentions batch limit and credit cost, but lacks disclosure on what enrichment entails or what happens on failure. Adequate but not rich.

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?

Extremely concise: two sentences plus a bullet point. Front-loaded with primary action and value. 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 simple batch enrichment tool with good schema, the description is sufficient. Lacks output description but no output schema exists, so not required. Slightly above baseline for 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?

Schema coverage is 100% and schema descriptions are detailed. The description adds minimal extra value (e.g., credit info). Baseline 3 for full coverage.

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 verb 'enrich' and the resource 'up to 10 people', and distinguishes itself from sibling tool 'enrich_person' by highlighting batching and same credit cost.

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 'Best for: enriching a batch of contacts at once' and contrasts with 'enrich_person', also notes 'Works on free Apollo plan'.

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. It discloses cost ('Costs 1 Apollo credit'), works on free plan, and lists return fields. Does not cover rate limits or authentication, but is sufficient for an enrichment 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?

Description is well-structured with a clear opening, 'Best for', details, returns, and examples. Slightly verbose in returns list but still efficient.

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, but description fully enumerates return values. Also covers cost, plan compatibility, and usage alongside other tools, making it complete for a simple enrichment 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 has one parameter with description; description adds list of returned fields, usage context, and examples, enhancing meaning beyond the schema alone.

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 starts with a specific verb 'Enrich' and resource 'company's full firmographic profile' by domain, clearly distinguishing it from sibling tools like enrich_person or Hunter email tools.

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 it is 'Best for: company intelligence that Hunter doesn't provide' and recommends 'Use this alongside Hunter email tools', providing clear guidance on when to use this tool versus alternatives.

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 full burden. It discloses credit costs (1 normal, 8 with phone), required identifiers, and that some options require a paid plan. However, it does not explicitly state whether the tool modifies data or is read-only, nor describe rate limits or error behavior. Still, it is fairly transparent about key behavioral traits.

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 concise (three sentences plus a list) yet packs purpose, use case, cost, and identifier requirements. It is front-loaded with the core action and progressively adds details. Every sentence adds value, and there is 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?

While the description covers cost, required identifiers, and suggests alternatives, it lacks a description of the return value (what fields are returned upon enrichment). With no output schema, this omission hurts completeness for an 8-parameter tool. It also does not mention failure scenarios (e.g., no match).

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 each parameter already has a detailed description (e.g., 'Strongly recommended — significantly improves match accuracy' for domain). The description adds context about requiring at least one identifier and cost implications, but the schema already handles meaning well. Baseline of 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?

The description clearly states the tool enriches a person's B2B profile by name and an identifier. It distinguishes itself from the sibling 'enrich_person_by_email' (for email-only) and suggests 'hunter_find_email' as a cheaper alternative. The verb 'enrich' plus resource 'person's B2B profile' is specific and actionable.

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 says 'Best for: enriching a contact when you have name + employer but no email yet' and suggests considering 'hunter_find_email first'. It also notes cost differences for reveal_phone_number. This provides clear guidance on when to use this tool and when to consider alternatives.

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 burden. It discloses cost (1 credit), plan availability (free plan), and return data (job title, seniority, LinkedIn, company, phone). Does not mention failure modes or rate limits, but provides sufficient behavioral context for safe invocation.

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?

Extremely concise: two sentences plus a line for best-for context. No redundant words. Front-loaded with purpose. Every sentence adds value.

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 output schema, the description explains return values (job title, seniority, LinkedIn, company, phone). Covers cost, plan, workflow context. Distinguishes from siblings. Complete for a simple enrichment 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 clear parameter descriptions. The description adds workflow context (lead-gen) and plan requirements, but does not add new parameter-level details beyond the schema. 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?

The description clearly states the tool enriches a person's full B2B profile using email. It specifies the resource (person), action (enrich), and scope (by email). It distinguishes from siblings like bulk_enrich_people and enrich_company by calling it the 'fastest and most reliable Apollo enrichment path'.

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?

Provides clear best-use scenario: having an email and wanting full profile. Implicitly recommends over alternatives by calling it 'fastest and most reliable'. Mentions cost and plan compatibility. Lacks explicit when-not-to-use or alternatives, but context is clear.

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 full burden. It discloses that the tool is free, does not consume credits, and returns specific fields (plan name, monthly quota, requests used, credits remaining). It does not explicitly state read-only behavior, but given the context, it's 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?

The description is concise with two short paragraphs, front-loaded with the main purpose. Every sentence is informative, covering purpose, best use case, cost, and output fields with no fluff.

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 tool with no input schema and no output schema, the description is complete. It explains what the tool does, when to use it, its cost, and what the output contains, fully preparing 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?

There are no parameters, so the schema covers everything. The description adds value by explaining the output contents, which is appropriate for a parameterless tool.

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 returns Hunter.io account info including remaining credits, using a specific verb ('Return') and resource ('account info'). It effectively distinguishes from sibling tools that focus on enrichment/verification.

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 says 'Best for: checking how many finder and verifier credits remain before running a large enrichment batch,' providing clear guidance on when to use. It does not mention when not to use, but the context is clear given the sibling tools cover other purposes.

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, but description discloses it's free, returns count broken down by department and seniority, and implies no destructive action. Adequate transparency for a simple count 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?

Concise and front-loaded: first sentence states action and resource. Subsequent lines add usage guidance and return info without 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?

For a simple 1-param tool with no output schema or annotations, the description covers purpose, when to use, cost, and expected output. 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% with one parameter described. Description adds value by noting free usage and return structure, going beyond schema details.

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 uses specific verb 'Count' and resource 'email addresses indexed for a domain'. Clearly distinguishes from sibling tools like hunter_find_emails_by_domain which retrieve actual emails.

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 'Best for: quickly checking data availability before spending credits on a full domain search' and 'FREE — does not consume any credits or quota', guiding when to use and that it's cost-free.

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?

Without annotations, the description fully carries the burden of behavioral disclosure. It explains the cost (1 credit), the return format (guessed email with confidence score 0-100, sources, verification status), and provides a reliability threshold (score above 70). 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?

The description is four short, purposeful sentences with no wasted words. The purpose is front-loaded, and every sentence adds value.

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 output schema, the description explains the output structure, cost, and reliability guidance. The parameter set is simple and fully documented. The tool is complete for its intended use case.

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 each parameter is already well-documented. The description adds no new parameter details beyond mentioning 'name and employer', which is already captured in schema. 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?

The description clearly states the tool finds the most likely work email for a specific person, with a specific verb and resource. It distinguishes from siblings like 'hunter_find_emails_by_domain' which finds multiple emails for a domain.

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: finding a contact email when you know the person's name and employer,' providing clear context. It also mentions the cost (1 credit). However, it does not explicitly state when not to use it or name alternative 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?

No annotations provided, so description carries full burden. It discloses cost (1 Hunter request), that it doesn't consume per-email credits, and describes return fields. However, it lacks details on rate limits or caching, but covers key behavioral aspects.

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?

Five well-structured sentences with no waste. The opening sentence states the core action and resource. Each subsequent sentence adds distinct value: use cases, cost, return fields, and a precursor action.

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 4 parameters, no output schema, and 0 annotations, the description sufficiently covers return values, cost, and best practices. It suggests using hunter_count_emails first, providing actionable context for an agent.

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 clear descriptions. The description adds value by noting that department accepts comma-separated values and lists options. It also contextualizes email_type by explaining the returned address styles, exceeding schema 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?

The description explicitly states the verb and resource: 'Find all email addresses associated with a company domain.' It lists return fields (confidence scores, names, job titles, LinkedIn URLs) and distinguishes from siblings like hunter_find_email (individual) and hunter_count_emails (gauge availability).

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 opens with 'Best for: prospecting a whole company, building outreach lists, discovering team structure at a target account.' It also advises using hunter_count_emails first. While it doesn't state when not to use, it implies alternatives exist.

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 costs 1 Hunter verification credit, returns a status with values like 'valid' and 'invalid', and includes SMTP and MX record check details. This is transparent about the tool's behavior and output.

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 extremely concise with no wasted words. It front-loads the purpose, uses bullet points for clarity, and every sentence adds value.

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 tool's simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: purpose, usage, cost, and return values. It is complete enough for an AI agent to understand when and how to use it.

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 only one parameter fully described in the schema (email with example). The description adds no additional semantics beyond what the schema provides, but since schema coverage is 100%, baseline score of 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?

The description clearly states the tool's purpose: 'Verify the deliverability of an email address.' It includes specific verb (verify) and resource (email address), and differentiates from sibling tools like hunter_find_email by focusing on deliverability 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 description provides explicit usage scenarios: 'Best for: cleaning a lead list before sending outreach, validating emails found by other tools, reducing bounce rates.' It also advises to only send to 'valid' addresses, giving clear context for when to use the tool.

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 provided, the description carries full burden. It discloses key behaviors: requires Apollo Basic plan (returns 403 on free tier), does not consume credits, and does not return email addresses. This is sufficient for an AI agent to understand side effects and constraints, though it could mention pagination or rate limits.

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 concise with two paragraph-like sections: purpose then prerequisites/caveats. It front-loads the main action and uses line breaks for readability. Every sentence adds information, though the plan requirement could be integrated more seamlessly.

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 no output schema, the description does not explain the structure of results (e.g., company objects, pagination meta). It covers prerequisites, non-consumption of credits, and what not to expect, but lacks details on return format or how to navigate results. This is a notable gap for an AI agent deciding whether to use this 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%, so baseline is 3. The description summarizes parameters as 'keyword, location, or headcount' but does not add deeper semantics beyond what the schema provides. The schema already describes each parameter with examples and ranges, so the description adds minimal value 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?

The description clearly states the tool searches Apollo's company database by keyword, location, or headcount. It uses specific verbs and resources, and distinguishes itself from sibling tools like enrich_company and hunter_find_emails_by_domain by noting what it does not do (return emails) and what alternatives exist.

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 this tool vs alternatives: 'Does NOT return email addresses. To get contacts from results, use hunter_find_emails_by_domain (Hunter) or enrich_company (Apollo) for firmographic details.' Also notes the prerequisite of an Apollo Basic plan, which helps the agent avoid 403 errors.

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. It discloses subscription requirements, credit usage (none), and that emails are not returned. This is good but lacks details on pagination behavior or response structure. Still, it sufficiently informs the agent of key behaviors and limitations.

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 two tight sentences followed by a short paragraph of essential notes. Every sentence adds value (purpose, requirements, limitations, alternatives). No fluff or 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?

Given the tool has 6 parameters (all documented in schema), no output schema, and no annotations, the description covers prerequisites, credit consumption, email availability, and alternative tools. This is sufficient for an agent to understand when and how to use the 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?

The input schema has 100% coverage with good descriptions for all 6 parameters. The description only adds a high-level mention of filters ('by title, location, or seniority'), which doesn't significantly enhance understanding beyond the schema. Hence a baseline score of 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?

The description clearly states the verb 'search' and the resource 'Apollo's people database' and mentions key filters (title, location, seniority). It distinguishes from sibling tools like search_companies and enrich_person by specifying it searches for people, not companies, and by not returning emails, which is a differentiator.

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 states the required plan (Apollo Basic or higher) to avoid 403 errors, clarifies that it does not consume credits, and notes that it does not return emails. It provides clear alternatives (hunter_find_email, enrich_person) for obtaining emails, giving the agent explicit guidance on when to use this tool and when to switch.

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