Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

yoox_search

Browse and search YOOX products by department, applying filters for designer, color, size, price, and sale. Returns product info including brand, price, stock, and image.

Instructions

Search YOOX products. Searches or browses YOOX products in the required department. Optional filters are q, category, designer, color, size, price_min, price_max and on_sale; sort takes relevance, newest, price_asc, price_desc or discount; limit is 1 to 100. Each product has brand, name, price, currency, stock status, image and URL, with facets for colors, sizes and sorts. May return 503.

Input Schema

NameRequiredDescriptionDefault
qNoFree-text search
pageNo1-based page
sizeNoSize filter
sortNoSort
colorNoColor filter
limitNoResults per page
on_saleNoSale items only
categoryNoCategory slug from yoox-categories
designerNoDesigner slug from yoox-designers
price_maxNoMaximum price
price_minNoMinimum price
departmentYesDepartment

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the behavioral burden and does add useful context: it discloses returned product fields, facets, the 1-100 limit range, and that a 503 may occur. It still omits pagination behavior and does not explicitly state read-only semantics, but for a search tool the disclosed behavior is reasonably transparent.

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?

The description is compact and front-loaded, covering the core purpose, filters, sort values, limit range, return shape, and error possibility without excessive prose. There is slight redundancy between 'Search YOOX products' and the following sentence, but overall it is appropriately sized for a 12-parameter tool.

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 complex search tool with 12 parameters, no annotations, and no output schema, the description is fairly complete: it covers required department, optional filters, sort options, limit bounds, result fields, facets, and 503 behavior. The main gap is that the page/pagination parameter is not mentioned, and usage against sibling lookup tools remains implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the parameters and enum values. The description adds a little meaning by listing filters and stating 'limit is 1 to 100,' but most parameter semantics are already available in the schema, including the category and designer slug references.

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 gives a clear verb and resource: 'Search YOOX products' and 'searches or browses YOOX products in the required department.' It is specific enough to distinguish a product search/browse operation, though it does not explicitly differentiate itself from siblings like yoox_product, yoox_categories, or yoox_designers.

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

Usage Guidelines3/5

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

It explains that a required department is necessary and that optional filters can be used to search or browse, which implies the usage context. However, it does not explicitly say when to use this tool instead of yoox_product or when to use category/designer lookup tools first.

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