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

Annotations already declare this a read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds non-obvious behavior the annotations cannot: results are policy-scoped by storefront, some prices are hidden and therefore unsortable, and technical constraints are treated as mandatory rather than soft signals. It doesn't describe pagination limits or result shape, which keeps it below a 5.

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 dense sentences, front-loaded with the searchable facets, then ordering policy, then sort restrictions — no filler. The phrase 'inherits public storefront brand/lifecycle policy' is compact to the point of being cryptic for an agent unfamiliar with the underlying policy model.

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 7-parameter tool with nested filter objects and no output schema, the description covers intent, ordering and one hard constraint but leaves result pagination (limit/offset bounds) and language behavior unexplained. It is adequate to start a call but not complete enough for an agent to fully predict retrieval behavior.

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%, so the description carries the burden, and it does explain the intent of q (SKU, free text, engineering requirements), sort (msrp-only, in the stated currency) and implicitly the technical filter object. However, limit, offset, language and the availability/maxMsrp filters go unmentioned, leaving several parameters with no semantic guidance anywhere.

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 verb and resource ('Find products by SKU, product text, engineering requirements or visible MSRP/status'), which tells an agent exactly what surface area is searchable. It implicitly separates itself from get_products (lookup) and search_product_analogs, but never names a sibling, so differentiation is inferred rather than stated.

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?

It gives real when/when-not guidance: sort is only for an explicit price order, hidden prices cannot be sorted, and default ordering follows storefront brand/lifecycle policy. It stops short of naming alternatives such as get_products or search_product_analogs and doesn't say when a direct lookup should replace a search.

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