Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

nike_product

Retrieve full details for a single Nike color variant—title, description, pricing, images, all sizes, and other colors—using slug and style_color from search results.

Instructions

Get a Nike product. Returns product-detail data for one color variant: title, description, pricing, images, every offered size, and every other available color. slug and style_color together reproduce Nike's own product page URL (nike.com/t//<style_color>) and are both returned by nike-search's product colors[].slug and colors[].style_color fields.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>",
      "style_color": "<style_color>"
    },
    "name": "nike_product"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	Yes	Product-detail URL slug, from a search result's colors[].slug field
`style_color`	Yes	Style-color id, from a search result's colors[].style_color field

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.14.0Aug 21, 2026

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. "Get" implies a safe read, and the description usefully enumerates the returned payload (title, description, pricing, images, sizes, colors), but it discloses nothing about auth requirements, rate limits, or other operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, then return payload, then the parameter relationship. No filler, though the final sentence is dense and packs both the URL fact and the sourcing hint together.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema present, the description correctly compensates by enumerating the returned fields, and it explains where the required inputs originate. For a read-only product fetch this is nearly complete; only auth/operational context is absent, which is low-stakes for a GET.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds genuine semantic value: it explains that slug and style_color must be used together and that they compose Nike's own product URL (nike.com/t/<slug>/<style_color>). That compositional meaning goes beyond the per-field schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ("Get a Nike product") and pins down the granularity as a single color variant, which is more precise than a generic product fetch. It does not explicitly distinguish itself from close siblings like nike_product_details or nike_product_reviews, so an agent could still hesitate between them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context by naming nike-search as the upstream source of both required inputs (colors[].slug and colors[].style_color), effectively telling the agent to run a search first. However it offers no explicit when-not conditions or direct comparison against alternative product-detail tools.

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

Deploy Server