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

Annotations already declare the important traits (readOnlyHint=false, idempotentHint=true, destructiveHint=false), lowering the bar. The added 'Does not send' is a genuinely useful side-effect boundary, but the description says nothing about permissions, what happens on an invalid/unrecognized source, or how contactIds interacts with source. Minimal value beyond structured fields.

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 tight sentences with the core purpose front-loaded and the routing rule second. The 'APP:' prefix and the reference to update_campaign's dataSource/selectedSheetTab parameters are slightly noisy for this tool, but they earn their place as disambiguation.

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?

An output schema exists, so return values need not be described, and the annotations cover idempotency and safety. What remains missing is meaningful given the complexity: how source and contactIds combine, what the idempotencyKey and external* identifiers are for, and what happens when a source connector is not configured.

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% across 9 parameters, so the description carries the full burden. It references only two inputs implicitly ('known contact ids' → contactIds, 'a supported source' → source) and never enumerates the five allowed source values. Six parameters (name, idempotencyKey, and the four external* correlation ids) get no mention at all, which is a large gap for a tool with no schema documentation.

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 concrete verb and resource ('Builds a Sendblox audience') and narrows the input modes to 'known contact ids or a supported source'. It also names a sibling (update_campaign) to route CRM sources away from this tool. It does not, however, distinguish itself from the closely related preview_audience sibling, leaving that selection to inference.

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?

Gives an explicit exclusion with an alternative: Salesforce, Zoho, and other CRMs are configured via update_campaign with dataSource/selectedSheetTab, 'not here'. That is real when-not-to-use guidance. It stops short of a general when-to-use statement (e.g., before preview_audience or preflight_campaign in the campaign lifecycle).

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