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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine non-annotation context: prices are fixed, billing is by invoice after publication, and the article is buyer-supplied and must be fact-checked and labelled. It does not cover pagination or the shape of the returned feed, which matters given there is no output schema.

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: identity and pricing first, product detail second, next step last. Nothing is redundant, though the catalog detail is spent on a single product rather than on how to call the tool.

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?

With no output schema, the description usefully sketches the product payload and the feed_version token, and its attribution to a single product sets expectations. Against four fully undocumented nested parameters, however, it leaves an agent without enough to fill the request body correctly.

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 four parameters, including nested brand and account objects, yet the description says nothing about what brand, account, max_results or if_feed_version control. Only feed_version is touched, and only as a return value to forward, not as the if_feed_version input parameter.

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 states a specific verb and resource ("AdCP list_products: the placements Agentry sells, with fixed prices") and describes the single catalog item in concrete terms, including supply, fact-checking, labelling and price. It does not differentiate itself from the sibling get_products, which an agent could plausibly confuse with a catalog listing.

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 chaining instruction "Pass the returned feed_version to buy_products" makes the downstream workflow clear, so an agent knows this is a pre-purchase step. However, there is no statement of when to prefer this over get_products or any exclusion, so choice between catalog-reading siblings is left to inference.

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