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

Annotations already mark the tool as read-only and non-destructive, so the bar is lower. The description adds the key behavior that it resolves the family hierarchy first and returns parent plus all child ASINs, enabling the recommended PPC workflow. It also gives a concrete parent-SKU example, though it does not disclose rate limits or authentication-specific behavior.

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 longer than average but front-loads the core purpose and usage decision. The repeated emphasis on parent SKU not being a campaign name is somewhat redundant, but it reinforces a critical disambiguation and each sentence contributes to correct tool selection or invocation.

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 adequately states what is returned: parent product info and all child variants with their ASINs. It covers when to use the tool, what to expect, a concrete input example, and the next step in the workflow, so an agent has enough context to invoke it 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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by showing a real parent-SKU example ('SEAMLESS-LARGE-SPATULAS'), clarifying that the search covers product identifiers rather than campaign names, and explaining the recommended ASIN-based follow-up query.

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 clear verb and resource: look up parent/child product hierarchy from the product library. It also lists the exact trigger references (parent SKU, parent ASIN, product family, listing) and explicitly contrasts this with campaign names, making it easy to distinguish from sibling PPC lookup tools.

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 description gives explicit when-to-use guidance: use it when a user references a parent SKU, parent ASIN, product family, listing, or any product identifier that isn't a campaign name. It also names the follow-up tool, ppc_advertised_products, with the required asins parameter, and warns against misinterpreting a parent SKU as a campaign name.

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