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

With no annotations, the description carries the burden and does the essential part: it declares the operation is non-mutating ("Changes nothing") and specifies the preview payload (name, deletable contact count). It does not cover edge cases an agent might hit, such as what happens if the id does not exist or whether the preview consumes credits, so it stops short of full behavioral disclosure.

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 short sentences, front-loaded with the dry-run nature and the mandatory pre-call rule; no filler or restated field names. Every sentence contributes a distinct fact (what it shows, that it is safe, when to call it).

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 one-parameter, non-destructive preview with no output schema and no annotations, the description supplies all the essentials: the non-mutating guarantee, the returned information, and the required call ordering. Nothing an agent needs in order to invoke it correctly is missing.

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?

Only one parameter exists and the schema already documents it at 100% coverage ("Custom audience id (UUID)"). The description reinforces that the target is an audience whose name and contact count will be shown, adding slight meaning beyond the schema, which is a modest lift above the baseline of 3 for a fully documented single param.

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 (dry-run preview of deleting a custom audience) and explicitly says what it returns: the audience name and how many contacts would be deleted. It is clearly separable from delete_custom_audience and from get_custom_audience because it frames itself as a non-mutating pre-check.

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?

"ALWAYS call before delete_custom_audience" gives an explicit ordering rule and names the alternative tool that performs the real action. The "dry-run ... Changes nothing" clause makes the when-to-use condition (before a destructive delete) unambiguous.

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