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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=true; the description goes beyond them by explaining exactly how idempotency behaves (same key plus same input returns the first result) and by disclosing that some candidates are admitted and others excluded, which signals filtering shrinkage the agent would otherwise not anticipate. It does not say what happens with an empty body or whether a snapshot expires, minor gaps given the annotation coverage.

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, each front-loaded with the action first, then return values, then retry semantics — no filler. Slightly terse for the payload complexity, but nothing is wasted and the ordering matches what an agent needs before calling.

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?

The description usefully covers the return payload (snapshot ID plus admitted/excluded counts) in lieu of an output schema, and addresses the idempotency contract. For a create tool taking a nested body of 13 optional fields with no required source, it leaves a real hole: an agent cannot tell from the definition what a valid selection looks like or how filters interact with explicit id lists.

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 50%; only idempotencyKey and available_again carry schema descriptions. The description compensates by naming the source categories that map to request_ids, icp_ids, company_card_ids, lead_ids and include_pipeline, but it says nothing about filters, new_only, recontact_lead_id or destination_requirement, and does not clarify whether the source fields are mutually exclusive or combinable — a significant omission for a 13-property nested body.

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 ("saves an audience snapshot") and enumerates the source types it can be built from (requests, ICPs, companies, contacts, pipeline), which maps onto the ids fields in the body. It is clearly a creation/materialization tool, distinct from read-oriented siblings like previewAudience or listAudiences, though it never names an adjacent tool such as saveLeadEngineAudience, which reads similarly.

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?

"For use in a new campaign" implies the downstream context, and the retry sentence gives practical guidance for repeated calls. However, there is no explicit when-not guidance, no mention of previewAudience/previewCampaignAudience as the natural dry-run step before saving, and no stated prerequisite (e.g., whether the audience must be checked via checkAudienceAvailability first).

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