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

Annotations already declare readOnly, idempotent and non-destructive, and the description reinforces this with 'Samples are not saved or sent' and re-runnability. It also discloses the error path ('or the issues that block them'), which is behavior an agent needs. What it omits is that a fit_confirmation token/fingerprint payload is required before any preview succeeds, a substantial prerequisite left undisclosed.

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?

Short and front-loaded, but 'Samples are not saved or sent' and 'It saves nothing, so it can be repeated' restate the same point twice. That wasted sentence could have carried the missing explanation of the fit confirmation instead.

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 tool with a deeply nested required body, no output schema and zero parameter descriptions, the definition does too little. It never explains the fit confirmation prerequisite, the freshness/snapshot concept, or the shape of either the samples or the blocking issues, which is exactly the burden the description should carry here.

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 schema is heavily nested: a required fit_confirmation object with three versioned anyOf variants containing tokens, fingerprint patterns, snapshot IDs and a snapshotFreshUntil field. The description adds no meaning about any of this, not even that the body exists or what the confirmation represents, so an agent has to reverse-engineer the schema 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?

States a specific verb and resource: returns sample messages for a few contacts in a draft campaign's audience, plus the blocking issues. That is clearly distinct from siblings like previewCampaignAudience or previewAudience, though it never names them directly. The purpose is unambiguous without opening the schema.

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?

Usage is implied by the phrase 'in a draft campaign's audience' and the note that it can be repeated, which suggests a safe pre-send check. There is no explicit when-not guidance and no routing among the many preview siblings (previewCampaign, previewCampaignAudience, previewCampaignAudienceSegment, previewAudience), which is a real gap in this crowded family.

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