yoox_product

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

No annotations are provided, so the description carries the burden of behavior disclosure. It adds useful context by stating the product detail is 'public' and that 'the legacy product URL form remains accepted.' However, it does not describe error behavior, what happens when neither parameter is provided, or the shape of the returned detail, leaving some ambiguity for an agent.

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?

Two sentences with no filler. The core action and resource are front-loaded ('Get a YOOX product'), and the remaining sentence adds the only essential additional detail about the legacy URL form. Every word earns its place.

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 simple product-detail lookup with a fully documented two-parameter schema, the description is largely sufficient. The main gap is the absence of an output schema, so the description does not characterize what 'product detail' contains, but this is minor for a fetch-by-id tool whose invocation requirements are clear.

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 baseline is 3. The description adds value beyond the schema by establishing the semantic relationship between parameters: the item id is the primary identifier and the URL is a legacy alternative that remains accepted. This helps the agent understand they are alternatives, not required together.

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: 'Get a YOOX product' and specifies it returns 'public product detail identified by a YOOX item id.' This is specific and unambiguous, but it does not explicitly differentiate itself from sibling product tools like farfetch_product or modaoperandi_product, though the YOOX-scoped identifier makes the distinction largely implicit.

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 implies when to use this tool: when you have a YOOX item id or a legacy product URL. However, it gives no explicit guidance about alternatives such as yoox_search for finding IDs or yoox_categories for browsing, and it does not state when not to use this tool.

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