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

Annotations already declare this a safe, idempotent, closed-world read, so the bar is lower, yet the description still adds real context: the leads:read scope requirement, the retry_after/backoff polling contract, and the important caveat that "an accepted batch does not mean all people were unlocked." That last line prevents a costly misreading of results and is exactly the kind of expectation-setting the annotations cannot convey.

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?

Four short sentences, each carrying a distinct payload: purpose and return contents, auth scope, polling behavior, and the unlocked-count caveat. The purpose leads, and there is no filler, though the caveat sentence could be tightened further.

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 with no output schema, the description does the heavy lifting well by naming the returned fields (status, verified leads, charged credits) and the polling contract. The remaining gap is input-side: nothing tells the agent the accepted batch_id formats or what happens on an unknown or expired batch.

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 0% and the description adds nothing about batch_id, not even that it must be a batch previously created by the calling key. The schema's anyOf encodes two accepted shapes (UUID and the opaque fmt_..._ token), but neither is explained in prose, so an agent has to reverse-engineer which form to supply from the pattern 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?

"Read this key's batch status, verified leads and exact charged credits" gives a specific verb plus the resource and the payload, which is stronger than the title alone. It does not distinguish itself from close siblings like fairvalid_get_job or fairvalid_get_results, so an agent cannot rule those out from the description.

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?

Polling guidance ("Honor retry_after and poll with backoff from 5 to 30 seconds") is operational how-to, not when-to-use. There is no explicit statement of when to call this instead of get_job, get_results, or get_leads, leaving the choice to be inferred from the word "batch".

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