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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely non-obvious behavior: two fields degenerate to duplicates without campaign message settings, and tierCounts is computed before exclusions. Those are real data-interpretation caveats not derivable from any structured field.

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?

Three sentences, front-loaded with what is returned, then the two field caveats. No filler. The second sentence is dense ("here they only repeat eligibleNow and 0") but each clause carries a distinct warning.

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?

There is no output schema, and the description usefully names several result fields and their caveats, which is the right place for the bunching since no output schema exists. However, with a nested query object at 0% schema coverage, the parameter side is under-specified, leaving an agent to guess valid channel values.

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 never documents the parameters. "Saved audience" loosely implies the id and "chosen channel" loosely implies the destination_requirement query field, but the four enum values and the default email_or_linkedin are nowhere mentioned, so an agent cannot select a channel value from the description 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?

"Returns how many contacts in a saved audience are eligible for the chosen channel and why others are excluded" gives a specific verb (returns/counts), resource (contacts in a saved audience), and output (eligibility counts plus exclusion reasons). It is clearly distinct from list-style siblings, though it never names an alternative such as previewAudience or getAudiencePreflight.

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?

It implies usage context (eligibility for a chosen channel on a saved audience) and gives a firm usage rule about never citing messageReadyNow/messageBlocked without a campaign's message settings. It does not say when to prefer this over sibling tools like checkAudienceAvailability, getAudiencePreflight, or previewAudience, so the routing guidance is only partial.

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