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

With no annotations, the description carries the full burden and provides strong context: per-buy scoping, the relationship to sync_creatives, the status lifecycle from 'pending_review' to 'approved', moderation behavior, and cursor-based pagination. However, it claims the library does not model variables, assignments, or snapshots while the schema exposes include_assignments, include_variables, and include_snapshot, which creates some ambiguity about whether those flags have any effect.

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?

The description is well-structured with WHEN TO USE, RETURNS, and EXAMPLE sections, and the core purpose is front-loaded. However, it is verbose and contains rhetorical all-caps statements like 'OUR LIBRARY IS PER-BUY, AND THIS SAYS SO' and 'never an invented concept_id to look richer than we are,' which add noise beyond the essential guidance.

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 15-parameter tool with no output schema and very low schema coverage, the description provides useful return-field details, pagination semantics, and an example, which is enough for a basic call. It is not complete for advanced usage: many include_* flags, filters, sort/fields behavior, and default behaviors are left unspecified.

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 only 13%, so the description needed to explain the many parameters, but it only meaningfully addresses include_assignments and media_buy_ids through the example and when-to-use bullets. Most parameters—sort, fields, account, context, include_items, include_purged, include_pricing, include_snapshot, include_variables, webhook_activity_limit, include_webhook_activity, and pagination controls—receive no semantic guidance.

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?

The description opens with a specific action and resource: 'List the creatives this buyer has on file with us.' It further distinguishes the tool by emphasizing the per-buy scope and that creatives are projections of the caller's own buys, which separates it clearly from related sibling tools like list_creative_formats and sync_creatives.

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?

The 'WHEN TO USE' section gives explicit, practical scenarios: confirming a creative landed, checking its review status, finding its attached media buy, and checking implications before cancelling a buy. It clearly states the per-buy limitation ('never someone else's assets'), though it does not explicitly name alternative tools or say when not to use this one.

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