Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

lululemon_category

Browse a lululemon category's product listing to retrieve products with pricing, sale detection, sizes, colors, and style numbers.

Instructions

Browse a lululemon category's product listing. Returns one lululemon category's product listing page: products with pricing, sale detection, sizes, colors, and style numbers. category and cdp_hash are the two path segments of a lululemon category URL (https://shop.lululemon.com/c/{category}/{cdp_hash}), e.g. women-new-styles and n14f1wz6o10 -- both are also available from lululemon-categories's own category and cdp_hash fields. Pagination is page-based and real: requesting a page beyond the category's real last page returns a normal response with an empty products array rather than an error. An unrecognized category/cdp_hash pair returns 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, one-based, defaults to 1
categoryYeslululemon category slug, from a category URL's first path segment
cdp_hashYeslululemon category id, from a category URL's second path segment
page_sizeNoResults per page, 1 to 100, defaults to 24

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.14.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses page-based pagination semantics (requesting beyond the last page returns an empty products array rather than an error) and that an unrecognized pair returns 404. It lacks notes on rate limits or auth, but the error and pagination behavior is substantially more than the schema provides.

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?

Front-loaded with the core action and return contents, then the parameter sourcing, then pagination and error behavior. Somewhat dense, but every sentence conveys distinct, useful information; no filler.

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?

For a browse/list tool with no output schema and no annotations, the description covers return fields, pagination behavior, invalid-input handling, and where the parameters come from. Complete enough to invoke correctly, with only minor gaps (no auth/rate-limit notes).

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 coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining that category and cdp_hash are the two URL path segments, giving the URL template, and concrete examples. This helps an agent map values from a category URL rather than just reading types from the schema.

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

Purpose5/5

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

States a specific verb and resource ('Browse a lululemon category's product listing') and immediately clarifies the returned scope (products with pricing, sale detection, sizes, colors, style numbers). This distinguishes it from sibling tools like lululemon_categories and lululemon_product without the agent 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.

Usage Guidelines4/5

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

It explains how to obtain the required inputs by pointing to lululemon-categories's own category and cdp_hash fields, which is a clear routing hint. It does not, however, explicitly state when to prefer this over lululemon_product or other alternatives, so it stops short of full when/when-not guidance.

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

Deploy Server

Other Tools