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

Goes well beyond the readOnly/idempotent/destructive annotations: duplicates are deduped to one lookup, a single contact failure never fails the batch, results return in input order with summary counts, and pricing is spelled out (x402 upto on Base, $0.08 per address returned). It also discloses that this MCP call returns payment instructions for POST /v1/email/batch and that no email is ever sent.

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?

Front-loads purpose and scope in the first clause, then layers output equivalence, failure semantics, pricing, and safety. It is a single dense paragraph that is slightly overloaded with payment detail, but every sentence carries actionable information.

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 return fields, failure isolation, ordering, pricing, and safety, and an output schema exists so return-value detail is optional. The one gap is the two-step flow: it says the MCP call returns payment instructions for POST /v1/email/batch, without clarifying how the agent completes the payment and submission, leaving some ambiguity for a paid 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 domain/first_name/last_name/full_name/found_only semantics are already documented, including the 1-25 bounds and the per-contact name requirements. The description reinforces the batch size and dedup behavior but adds no format or syntax detail beyond the schema, so 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?

Specific verb and resource ('Find work emails'), explicit scope ('1-25 people in one call'), and it directly distinguishes itself from the sibling email_lookup by stating results share the same fields and labels. An agent can differentiate this from email_lookup without opening either schema.

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?

Gives clear usage context ('for cleaning a whole prospect list') and anchors equivalence to email_lookup, implying the batch is the multi-contact counterpart. It never states an explicit exclusion versus basic_lookup/enriched_lookup or when a single lookup is preferable, so it falls short of full routing guidance.

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