nike_product_details

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does a solid job: states the data source ('same anonymous mobile backend Nike's own app uses'), the scope (product-group rollup, all color variants), and what fields are included (pricing, sizes, images). It could go further by mentioning rate limits, authentication expectations, or error behavior, but for a product-details read operation the disclosed behavior is sufficient.

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 front-loaded with the core purpose and then elaborates with necessary detail: what 'full' entails, the source of group_key, and the contrast with nike-product. Every sentence contributes to selection or invocation. It could be trimmed slightly (e.g., 'sourced from the same anonymous mobile backend Nike's own app uses' is nice context but not essential), so it earns a 4 rather than a 5.

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?

Given a single required parameter, no output schema, and no annotations, this description is remarkably complete. It tells the agent where to obtain the parameter (nike-search), what the tool returns (shared copy plus all color variants with pricing, sizes, images), and how it differs from the closest sibling. An agent has everything needed to decide to call it and 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%, as the schema describes group_key as 'Product rollup key, from a search result's products[].group_key field.' The description adds some semantic context by explaining group_key is the product's rollup key and that the value matches nike-search's products[].group_key, but this largely reinforces rather than extends the schema. Baseline 3 is appropriate since the schema already documents the parameter fully.

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 uses a specific verb and resource ('Get full Nike product details') and precisely defines what 'full' means: every purchasable color variant across width groupings, each with pricing, sizes, and images. It clearly distinguishes itself from the sibling nike-product tool by stating that nike-product returns only one color variant by slug/style_color, while this tool returns every color in one response.

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 explicitly tells the agent when to use this tool versus the sibling nike-product: 'Unlike nike-product (which returns one color variant by slug/style_color), this returns every color of the product in one response.' It also explains the provenance of the required parameter: 'the same value nike-search returns as a products[].group_key field,' effectively instructing the agent to first call nike-search. This is clear routing with a named alternative and a differentiating condition.

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