nike_product

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

With no annotations, the description carries full behavioral disclosure, and it does so well: it states the operation is a read that returns 'normalized' data, targets exactly one color variant rather than the entire product, and names the output dimensions. It also reveals the slug/style_color relationship to Nike's canonical URL. It stops short of mentioning failure/error behavior or currency/locale assumptions, but nothing here contradicts the tool's read-only nature.

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 sentences accomplish three jobs with no wasted words: the scope declaration (one color variant), the output summary (fields returned), and the input key provenance (nike-search tie-in + URL). The riskiest detail, that it is a single-variant fetch, is front-loaded instead of buried.

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?

The tool has no output schema and no annotations, but the description gives the agent the essential contract: what is required (slug, style_color), where those come from, what data comes back, and the exact URL it maps to. The omissions (error behavior, currency, image size conventions) are tolerable for a single-product 'get' call, making this near-complete.

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 the baseline is 3 even with no parameter prose. The description adds meaningful semantics on top: slug and style_color 'together reproduce Nike's own product page URL' and are derived from the same colors[] array in search results. This relational information strengthens the two separate opaque identifiers into a compound key with a known URL format.

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 and resource ('Get a Nike product') and immediately narrows scope to 'one color variant' with an enumeration of returned fields (title, description, pricing, images, sizes, alternate colors). This distinguishes it clearly from siblings such as nike_search (query results), nike_product_reviews (feedback), and nike_categories (menu structure), so an agent can tell it apart even before reading the 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?

The description establishes the intended call pattern by stating that both inputs come from a preceding nike-search result's colors[].slug and colors[].style_color fields, so an agent knows it should follow a search with this detail lookup. It does not explicitly name alternatives to avoid (e.g., 'use nike_product_reviews for reviews'), but the clear field-level provenance is strong contextual guidance.

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