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

Annotations already declare readOnly/openWorld/non-destructive, but the description goes further: it discloses server-side execution, price-quoting before costly runs, per-platform credit ranges, forwarding error.fix, and instructing the human via billing.display. That is real operational context beyond the structured fields. It loses a point for being cryptic rather than stating plainly what happens to credits on failure.

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 purpose is front-loaded, but the credit table is a dense, hard-to-parse run of numbers that inflates the description and would be better as structured data. The remaining sentences ('Runs on our side', 'Pass links whole') are terse to the point of ambiguity.

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?

With six parameters, full schema coverage, annotations and no output schema, the description covers the shape of the result (accounts, followers, engagement, evidence strength) and the cost/confirmation flow. Nothing essential for a correct call is missing, though the return format is only sketched.

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 per-parameter descriptions already explain scale, handle, confirm, platforms and max_cost_credits. The prose adds only two small facts ('the answer names them' for default platforms, 'Pass links whole, as given'), which is baseline-level value when the schema is already complete.

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 concrete verb-and-resource: it resolves one creator's accounts across platforms and returns followers, posts, engagement and evidence strength per account. An agent can picture the output. It stops short of naming how it differs from siblings like find_creators or account, so it does not fully route by itself.

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 quote-before-cost behavior ('A costly or long run quotes its price first') and the confirm/max_cost_credits mechanics imply when the tool will spend, but no alternative is named. There is no 'use find_creators when you want X' guidance, so an agent must infer the choice against the 17 siblings.

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