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

Goes well beyond the annotations by disclosing billing behavior (5 credits per email, no email = no charge), free-tier conditions, a promotion with a daily cap, and a privacy constraint ('Only show emails to this user; never publish them'). This explains why readOnlyHint=false for what looks like a read, resolving potential confusion.

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 core action, then layers billing/privacy conditions. Sentences are dense and information-rich; a reader must parse the free-vs-paid branches, but no sentence is 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?

No output schema exists, yet the description covers what is returned (public contact emails, per user only) and the cost model. It is nearly complete; only the exact return shape (e.g., per-creator missing-email handling) is left implicit.

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 50% (search_id documented, creator_ids only constrained). The description compensates by explaining search_id's role in billing and by reinforcing the 20-creator cap on creator_ids. It adds real meaning beyond the schema, though it does not detail creator_ids format.

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 a specific verb and resource ('Get public contact emails') plus a concrete scope ('for up to 20 creators'). An agent can immediately distinguish this from siblings like lookup_creators (which finds creators) or get_account. The privacy note further pins down what is returned.

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?

Clearly explains the conditions that select this tool: pass search_id for creators from a prior search (already paid), or unlock creators found via lookup_creators at 5 credits each. It gives strong when-to-use context via the pricing branches but does not explicitly state when NOT to use it or name an alternative tool to reach for instead.

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