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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuine context by enumerating that the response includes live stock and a public URL, signaling dynamic/fresh data rather than a cached record.

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?

One front-loaded sentence delivering purpose and return scope, followed by a tight Args block. No filler sentences; every clause adds information.

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?

An output schema exists, so return values needn't be spelled out, and the description still previews the payload. All parameters are accounted for and the id/slug fallback is covered, leaving little an agent needs and cannot find.

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 does so well: it names all three params and explains the conditional relationship (product_id required unless slug given; slug used when product_id is empty). Minor gap: no format or format-of-id detail.

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?

States a specific verb+resource+scope: 'Get one product' with the enumerable contents (options, variants, live stock, public URL). The word 'one' cleanly distinguishes it from the sibling list_commerce_products without opening either schema.

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?

Usage is implied by the singular 'one product', and the args section hints at the product_id-vs-slug routing condition, but there is no explicit when-to-use guidance or named alternative (e.g., when to prefer list_commerce_products or get_commerce_collection). Minimum viable.

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