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

With no annotations, the description carries the full burden and does so: it discloses that results are never part numbers or vehicle-to-part mappings, that fitment is resolved externally against VIN/RPO codes, that output mirrors search_catalog's summary shape, and that UCP calls return structuredContent in UCP shape. These are exactly the behavioral facts an agent needs to avoid over-claiming fitment.

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?

Purpose and scope are front-loaded, and the UCP variant is deferred to the end where it belongs. The fitment warning is repeated three times in slightly different words ('never a vehicle-to-part mapping', 'Do not assert that a product fits', 'resolved against the VIN'), which is defensible for a safety-critical constraint but is genuine redundancy.

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?

No output schema exists, yet the description explains the return shape (summary shape matching search_catalog, full detail via get_product, UCP structuredContent) and covers both the native and UCP input forms across all five parameters. Nothing material is missing for correct invocation.

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 3 is the baseline; the description earns above that by explaining what the slugs actually denote ('category slugs describe GM platforms and applications; tag slugs describe characteristics such as global-a or vin-programmed') and by clarifying that catalog.ids accepts product IDs, SKUs or URL slugs. It does not add anything about limit or the meta profile beyond what the schema already says.

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?

Opens with a specific verb+resource ('List products within a product category or tag') and immediately disambiguates from both siblings by naming search_catalog for discovery and get_product for full detail. It also scopes the tool's limits (platform/application-level only, no fitment), so an agent knows exactly what class of answer this returns.

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?

Explicitly states the prerequisite workflow ('Use search_catalog first to discover which categories and tags exist'), the escalation path ('call get_product for full detail'), and the alternative form ('In the UCP form, look up by catalog.ids instead'). It also gives a clear when-not-to-use rule: do not use this to determine or assert vehicle fitment.

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