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

The key behavioral trait—asynchronous execution returning a search id rather than the final email—is disclosed beyond what the annotations provide. With readOnlyHint=false, this two-step job behavior is consistent and useful, though failure modes or timeout expectations are not mentioned.

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 short sentences carry the purpose, the input constraint, and the async protocol with no redundant wording. The most important information is 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 start-search tool with no output schema, the description explains what is returned (search id) and the next tool to call (get_email_result), and parameter semantics are fully handled by the schema. It does not address bulk or verification sibling tools, but they are separate workflows and are not required to invoke this 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?

The schema already documents all parameters, so the baseline is 3. The description adds a valuable cross-field rule that the schema's required array does not capture: at least one of company_domain or company_name must be supplied, and they serve as alternative company keys.

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 action and object: 'Find a professional email address from a name and a company domain or name.' It also distinguishes this tool from the get_email_result sibling by stating it is asynchronous and returns a search id to poll.

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 gives a clear usage precondition ('At least one of company_domain or company_name is required') and an explicit follow-up action ('then poll get_email_result'). It does not name exclusions such as using find_emails_bulk for multiple lookups or verify_email for validation, so it stops short of full alternative routing.

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?

The description reveals the key behavioral trait that annotations cannot convey: the operation is asynchronous and returns a batch id for polling. This adds meaningful context beyond the readOnlyHint, openWorldHint, and destructiveHint flags. It does not mention potential rate limits or error handling, but the async disclosure is the most critical behavioral detail needed to call the tool correctly.

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 zero filler. The purpose and scale are front-loaded, followed immediately by the asynchronous workflow. Every sentence earns its place; the polling instruction is directly actionable.

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 core purpose and async flow, and names the polling sibling. However, for a 4-parameter tool with no output schema and a nested search object, it leaves gaps: the required search fields, the meaning of country_code/retrieve_gender, and how results are structured are not explained. The guidance is sufficient for a basic call with the required parameter, but not for confident use of the optional enrichment parameters.

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 only 50%: searches and retrieve_company_info have brief descriptions, while country_code and retrieve_gender are undocumented. The tool description does not compensate by explaining the structure of search objects (e.g., fullname is required) or the effect of the optional parameters. An agent would have to infer the meaning of country_code and retrieve_gender from names 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 clearly states the verb ('Find'), the resource ('multiple email addresses'), and the mode ('in bulk'), with a specific batch limit of 5,000. This naturally distinguishes it from the single-email find_email and the verify_emails_bulk sibling tools, while the asynchronous note separates it from get_emails_bulk_result.

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 outlines the required workflow: start the bulk operation, receive a batch id, then poll get_emails_bulk_result. This tells the agent exactly how to use the tool in sequence with its sibling. It does not explicitly state when to prefer bulk over single email lookup, but that is reasonably implied by the tool name and the batch limit caveat.

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?

The description discloses the asynchronous behavior—returns a search id, then requires polling get_phone_result—which is critical context not present in the annotations. It avoids contradicting readOnlyHint=false or destructiveHint=false, and adds useful behavioral depth beyond what annotations provide.

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 core purpose is front-loaded, and the async caveat is placed immediately after, giving the agent the essential information in minimal space.

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 five optional parameters and no output schema, the description covers the main input variants and the follow-up polling step. It does not describe the result payload or polling timeout, but the explicit reference to get_phone_result compensates for that gap.

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. The description adds meaningful selection guidance by marking linkedin_url as recommended and indicating first_name, last_name, and company_name can be used as a combined lookup. However, it omits any mention of company_domain, leaving part of the schema unaddressed in the narrative.

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 identifies a specific action ('find') and resource ('mobile phone number'), and states the two input modes: LinkedIn URL or name + company. This clearly distinguishes it from email-oriented siblings like find_email and bulk variants.

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 recommends LinkedIn URL as the preferred input and provides the alternative name + company lookup. It also tells the agent to poll get_phone_result after receiving a search id, which is a concrete next step. It does not contrast with find_phones_bulk, but the guidance is sufficient for basic routing.

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?

The description discloses a key behavioral trait beyond the annotations: the operation is asynchronous and returns a batch id rather than immediate results. This is essential for an agent to invoke and handle the tool correctly. It also communicates the batch size limit. Annotations are not contradicted; readOnlyHint=false is consistent with creating a batch job.

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 with no filler. The first sentence gives the core action and batch limit; the second explains the async flow and points to the poll endpoint. All information is front-loaded and directly useful.

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, a straightforward schema, and no output schema, the description covers the essential operational details: bulk limit, async behavior, and the complementary polling tool. It does not describe potential errors or result structure, but those are not strictly necessary here, given the schema and sibling tools. Overall adequate and complete for 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%—the only parameter 'searches' is described as an array of search objects with max 3,000. The tool description repeats the batch limit but does not add deeper semantics about the inner fields (last_name, first_name, etc.). With high schema coverage, baseline 3 is appropriate, and the description offers no extra parameter-level 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 clearly states the action ('Find multiple phone numbers in bulk'), the resource ('phone numbers'), and the batch limit (up to 3,000 per batch). It also distinguishes itself from siblings like find_phone (singular) and get_phones_bulk_result (result polling) by explicitly framing this as the bulk lookup operation.

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 a clear usage flow: it is asynchronous, returns a batch id, and requires polling get_phones_bulk_result. While it does not explicitly mention when not to use it (e.g., for single lookups use find_phone), the bulk context and sibling names make this fairly obvious. Slight gap remains in explicit exclusion 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds useful context about what the account info contains, but it does not disclose additional behavioral traits such as authentication requirements, rate limits, or response formatting. The description is consistent with the annotations and adds modest value beyond 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 one short sentence that leads with the action and resource, then parenthetically specifies the key return items. Every word earns its place; there is no repetition of the tool name or schema and no filler.

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 account-info retrieval tool, this description is fully sufficient. It names the tool's purpose and the main contents of the result, and the annotations cover the read-only and open-world behavior. No additional context is required 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?

The tool has zero parameters and schema description coverage is 100%, so the schema already fully documents the parameter surface. With no parameters to explain, the baseline is 4. The description does not need to compensate for any parameter gaps, and it instead clarifies what the returned account information covers.

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 ('Get'), names the exact resource ('your Enrow account info'), and enumerates the scope ('credit balance and registered webhooks'). This clearly differentiates it from the sibling tools, which all deal with email/phone lookups and verification rather than account-level data.

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 gives clear context: use this tool when you need account-level information such as credit balance or registered webhooks. Since there are no sibling tools that serve the same account-info purpose and the tool takes zero parameters, explicit exclusionary guidance is less critical. It does not explicitly name when not to use it, but the intent is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, establishing that this is a safe retrieval operation that may be affected by external changes. The description adds the context that this returns a previously launched search's result, aligning with the annotations. It does not disclose behavior like whether results may be incomplete, whether polling is required, or what happens with an invalid id, but given the simple retrieval nature and annotation coverage, a 3 is appropriate.

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 a single, focused sentence with no wasted words. It front-loads the verb and object and avoids restating the tool name or listing trivial details. This is an ideal length for a tool of this simplicity.

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 one-parameter, read-only retrieval tool with a fully described schema and useful annotations, the description is largely sufficient. It clearly identifies what the tool returns and the source of the id. It could be improved by noting whether the result may be pending or how to handle an incomplete search, but those are minor gaps given the simplicity of the operation.

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 fully documents the single 'id' parameter with the description 'Search ID returned from find_email', so schema coverage is 100%. The tool description itself does not add additional parameter meaning, but the schema already provides clear provenance for the parameter. Baseline 3 is correct because the schema carries the semantic weight and no gaps remain.

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 action ('Retrieve') and the resource ('result of a previously launched email search'), making the tool's purpose immediately understandable. It does not explicitly name a sibling alternative, but the singular 'email search' differentiates it from bulk result tools like get_emails_bulk_result. Overall, the verb and resource are specific enough for an agent to know what this tool returns.

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 implies the tool should be used after launching an email search, and the schema's parameter description states the id comes from find_email. However, there is no explicit guidance on when to use this versus get_emails_bulk_result or get_verification_result, nor any mention of polling behavior or error conditions. Usage context is present but only implied, not clearly delineated.

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?

The readOnlyHint and openWorldHint annotations already convey that this is a safe read operation, and the description merely restates 'retrieve.' Nothing is disclosed about asynchronous bulk-job semantics, whether results can be fetched more than once, or how the result payload is structured.

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 a single front-loaded sentence with no filler. It states the core operation immediately and does not waste tokens.

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 one-parameter, read-only retrieval tool with full schema coverage, the description is minimally adequate. The lack of an output schema means the description could have usefully explained what a bulk email search result looks like, but it does not; it also omits any polling or availability caveats.

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 id parameter is documented as the batch ID returned from find_emails_bulk, so the schema carries the parameter meaning. The tool description adds no independent parameter guidance, which is acceptable given the full schema 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 identifies the action (Retrieve) and the resource (results of a bulk email search), which distinguishes it from singular/verification siblings. However, it largely paraphrases the tool name and title without adding operational specifics such as what the returned results contain.

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 phrase 'bulk email search' implies this tool is used after starting a bulk search, but the description never explicitly says to use it with the ID from find_emails_bulk or mentions alternatives like get_email_result for single searches. The only concrete pairing hint lives in the schema's id description, not in the tool description.

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 declare readOnlyHint=true and openWorldHint=true, and the description's 'Retrieve' is consistent with a read-only operation. The description adds the useful context that the operation returns a result from an earlier launch, but it does not disclose behavior around missing, expired, or not-yet-ready results; the annotations already carry much of the safety profile.

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 sentence with no filler, front-loading the core retrieval action and the connection to a previously launched search. Every word contributes to understanding the tool's 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?

For a one-parameter read-only retrieval tool, the description plus schema sufficiently cover what the tool does and how to identify the correct search. There is no output schema, so exact return shape is unspecified, but the description's 'result' wording provides adequate conceptual completeness; a minor gap is lack of detail on error or not-ready behavior.

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%, with the only parameter 'id' documented as the search ID returned by find_phone. The tool description itself adds no additional parameter semantics beyond that, so the baseline score of 3 applies because the schema does the heavy lifting.

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 ('Retrieve') and resource ('result of a previously launched phone search'), clearly indicating this is the async result-fetching counterpart to find_phone. It is distinguished from bulk sibling tools by its singular 'phone search' scope, though it does not explicitly name any alternative.

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 usage context is implied: this should be called after a phone search has been launched, since it retrieves a 'previously launched' search result and the id parameter is described as the ID returned from find_phone. However, there is no explicit when-not-to-use guidance or mention of alternatives like get_phones_bulk_result.

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 establish readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the context that this is a bulk result-retrieval operation, but it does not disclose relevant behavior such as whether results are available immediately, require polling, or may be partial if the bulk search is still running.

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 a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and resource.

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 fully documented parameter, no nested objects) and the annotations cover safety, so the definition is minimally usable. However, there is no output schema and the description does not describe the shape of the returned results or the asynchronous relationship with find_phones_bulk, which are the main gaps.

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 'id' parameter is clearly documented as the batch ID returned by find_phones_bulk. The description itself adds no extra parameter semantics, but none are needed because the schema already carries the full meaning.

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 ('Retrieve') and a specific resource ('results of a bulk phone search'), clearly identifying this as the result-fetching counterpart to find_phones_bulk and distinguishing it from single-result get_phone_result. It states exactly what the tool does rather than merely repeating the name.

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 does not explicitly state when to use this tool versus alternatives. The parameter description ('Batch ID returned from find_phones_bulk') implies that the agent should call find_phones_bulk first, but this is in the schema, not the description, and there is no guidance about polling or choosing between get_phone_result and this 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?

The annotations already declare readOnlyHint=true, so the description is not required to restate safety. It adds a small behavioral cue by specifying the result is for a previously launched verification, implying an asynchronous polling pattern, but it does not disclose details like whether results are one-time retrievable, stale, or how quickly they become available. This is acceptable but not richly transparent.

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 sentence that fully communicates the tool's purpose without filler. It is front-loaded and every word contributes to the agent's understanding.

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 retrieval tool with one well-documented parameter, read-only annotations, and no nested objects, the description is sufficient. The agent knows what the tool does, when to use it, and what input to provide.

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 the single parameter 'id' is already described as the verification ID returned from verify_email. The tool description adds no additional parameter meaning, 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?

The description uses a specific verb ('Retrieve') and identifies the exact resource: the result of a previously launched email verification. It clearly distinguishes this from sibling tools like verify_email (which launches a verification) and get_verifications_bulk_result (which is bulk-oriented).

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 phrase 'previously launched' clearly signals that this tool should be used after verify_email has been called, not as a standalone operation. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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?

The description states a read-only retrieval, matching readOnlyHint=true, so there is no contradiction. It adds no behavioral details beyond that – no polling semantics, no rate limits, no note that results may be partial or cached. With annotations already covering the safety profile, the description contributes little behavioral context, so it under-delivers.

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. Every word earns its place and the core purpose is immediately visible.

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 one-parameter read tool, the description and schema together tell an agent what to call and with what argument. However, the meaning of the returned 'results' is unspecified and the distinction from get_verification_result is left implicit. Slightly above minimal but not rich enough to fully orient 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?

The single id parameter is fully documented in the schema as 'Batch ID returned from verify_emails_bulk', so schema coverage is complete. The tool description says nothing about the parameter beyond its existence, which is fine because the schema carries the 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 the verb 'Retrieve', the resource 'results of a bulk email verification', and the bulk scope, which separates it from the singular get_verification_result. It does not name the sibling alternatives or the originating verify_emails_bulk call, but the resource is clear.

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 offers no explicit guidance on when to call this tool versus get_verification_result or get_emails_bulk_result. The word 'bulk' implies a batch scenario, but the prerequisite (batch ID from verify_emails_bulk) is only stated in the schema, not the tool description. This leaves 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?

The description discloses two important non-obvious behaviors beyond the annotations: the operation is asynchronous and requires polling, and it works on catch-all domains. This is substantial added context with no contradiction to the 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 two tight sentences with no filler. The purpose is front-loaded, and the async polling detail is placed immediately after, making it easy for an agent to parse.

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 async tool, the description is nearly complete: it states what the tool does, its catch-all support, and the next step in the workflow. It could mention polling timing or potential failure behavior, but the referenced sibling tool likely covers the result details.

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 email parameter is already well documented as 'Email address to verify'. The description adds no additional parameter-level detail, so the 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 states a specific verb ('Verify'), a specific resource ('email address'), and the precise goal ('deliverable'). It also adds a distinguishing capability ('Works on catch-all domains') that helps separate it from lookup-style siblings like find_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?

It clearly explains the required asynchronous workflow: returns a verification id, then poll get_verification_result. However, it does not explicitly state when to prefer this over the bulk variant verify_emails_bulk or the find_email sibling.

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 indicate the operation is not read-only, but the description adds genuinely useful context: the call is asynchronous, returns a batch id, and requires polling for the final result. This goes beyond the annotations and helps the agent understand the interaction model.

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 tightly packed sentences communicate scope, limit, asynchronicity, and the follow-up tool with no filler. Every word 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?

For a single-parameter async tool with no output schema, the description covers the essential workflow: provide emails, get batch id, poll the result tool. It could add minor details about error or polling behavior, but nothing critical is missing 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?

The schema only documents 'emails' as an array of strings, so the description adds meaningful parameter semantics by specifying the 5,000-per-batch limit and clarifying the bulk, asynchronous nature of the request.

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 action ('Verify multiple email addresses in bulk') and differentiates itself from single-verification and result-polling siblings by specifying batch size and asynchronous behavior. This lets an agent immediately distinguish verify_emails_bulk from verify_email and get_verifications_bulk_result.

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 says to poll get_verifications_bulk_result after receiving a batch id, which gives a concrete next step. It also implies the single-email alternative by saying 'multiple' and 'bulk', though it does not explicitly name verify_email as the tool for one-off verification.

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