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

Annotations only flag idempotency and non-destructiveness; the description adds substantial non-obvious behavior: 4 credits per newly delivered verified email, zero cost for unavailable/already-owned contacts, maximumCredits as a user-approved ceiling plus workspace balance and the key's shared lifetime cap, and test keys using no real credits. It also spells out the exact retry contract under uncertainty and timeout, which is the highest-risk ambiguity for this 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?

Front-loads the action and cardinality, then moves in a logical order through cost, ceilings, retry semantics, and polling. Sentences are dense and occasionally telegraphic (e.g., 'Reuse the same idempotency_key and unchanged ids/maximumCredits on retries'), but every sentence carries operational 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?

For a paid, idempotent, asynchronous mutation with no output schema, the description supplies everything an agent needs: cost model, budget ceiling, permission requirement, confirmation requirement, retry contract, and the instruction to poll batch_id. Nothing material about correct invocation is left unstated.

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%, so the description must compensate: it does so for maximumCredits by explaining it is the user-approved ceiling bounded further by workspace balance and the key's lifetime cap, and for ids via the 1-to-50 bound. The idempotency_key stability rule is reinforced in prose; only the exact shape of ids items remains unelaborated.

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 action and scope: 'Start a durable batch for 1 to 50 selected people,' and the credit model ('newly delivered verified work email') makes clear the output is unlocked contact emails. It does not explicitly name the closely related siblings (fairvalid_quote_leads, fairvalid_get_job) even though it references the quote and polling steps, so sibling differentiation is only implicit.

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 concrete prerequisites and sequencing: obtain a quote and explicit user confirmation first, requires the leads:acquire scope, then poll batch_id with backoff. Retry guidance is explicit ('reuse the same idempotency_key... including after a timeout'; 'Never repeat with a new key'). It stops short of naming which sibling tools to call for the quote or the poll, leaving that inference to the agent.

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