Skip to main content
Glama

discover_products

Read-only

Find fashion products using natural language and/or structured filters. Provide a query for semantic ranking via multimodal text+image embeddings ("oversized wool coat", "black leather jacket", "minimalist gold jewelry", "linen shirt for a beach wedding under $200") — best for open-ended discovery. Keep queries concrete: noun-led with up to one or two modifiers works best ("summer linen shirt" beats "breathable linen shirt perfect for summer"). Provide only structured filters (category, brand, colors, gender, price, etc.) for pure browse — results are recency-ranked and paginate cleanly. Combine both for filtered semantic search. At least one of query or a filter must be provided.

Example calls (notice the sparse filter population — descriptive attributes stay in query, not in structured fields):

  • "linen wedding guest dress under $200" → {query: "linen wedding guest dress", gender: "women", max_price: 200, materials: ["linen"]}

  • "wool coat under $300" → {query: "wool coat", gender: "women", max_price: 300, materials: ["wool"]}

  • "browse women's black dresses $100-$300" → {gender: "women", category: "clothing/dresses", colors: ["black"], min_price: 100, max_price: 300}

  • "Acne Studios outerwear" → {query: "outerwear", brand: "Acne Studios", gender: "women"}

Returns compact product cards: AI-generated summary, price, images, tags, and compact availability by color/size; variant price differences are nested under the availability dimension that determines price. For merchant description, store info, SKU-level variants, exact variant prices, and all product images, call get_product with a product ID from these results. Multi-currency prices supported (e.g. "under 200 zł" or min_price=200 + currency="PLN"); returned prices render in the requested currency when provided.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number.
brandNoFilter by brand name
limitNoPage size (1-20, default 12)
queryNoNatural language search query — be descriptive for best results. Can include price with currency symbols (e.g. "white coat under 200 zł") which will be parsed automatically. Optional: when omitted, results are filtered by the structured fields below and ranked by recency. Provide either a query, structured filters, or both.
colorsNoFilter by lowercase colors: e.g. ["black", "navy", "sage green"]
genderNoGender filter.
seasonNoSeason filter. Soft descriptor — set ONLY when the user explicitly named the season. The `query` field already captures season semantically; over-specifying is the most common cause of zero-result calls.
stylesNoStyle filter (OR semantics — a product matches if any of its `styles` values is in this list). Pass a single value to filter by one style ("styles": ["minimalist"]); pass several to span a related set ("styles": ["basics", "minimalist", "preppy", "sportswear"] for a "Casual" bucket). Soft descriptor — set ONLY when the user explicitly named one or more styles. The `query` field already captures style semantically; over-specifying is the most common cause of zero-result calls.
countryNoOptional shopper location as an ISO-3166-1 alpha-2 country code (e.g. "US", "GB", "DE"). Recorded for analytics and used to improve future offer geo-matching. Omit if unknown — absence preserves current behavior.
patternNoPattern filter (e.g. solid, stripe, checked, floral). Soft descriptor — set ONLY when the user explicitly named the pattern. Default for unspecified ("solid") leaks into queries and zeros the candidate set; omit when unsure.
sleevesNoSleeve style filter. Soft descriptor — set ONLY when the user explicitly named the sleeve style. Do not infer from category or query.
categoryNoCategory slug, e.g. "clothing", "clothing/jackets", "clothing/jackets/bomber-jackets". Accepts last-segment shortcuts when unambiguous — e.g. "loafers-and-slip-ons" resolves the same as "shoes/loafers-and-slip-ons", and "bomber-jackets" resolves the same as "clothing/jackets/bomber-jackets".
currencyNoISO 4217 currency code for min_price/max_price (e.g. "PLN", "EUR", "GBP"). Prices are converted to USD for filtering. Omit for USD.
necklineNoNeckline filter. Soft descriptor — set ONLY when the user explicitly named the neckline. Do not infer from category or query.
occasionNoOccasion filter. Soft descriptor — set ONLY when the user explicitly named the occasion. The `query` field already captures occasion semantically; over-specifying is the most common cause of zero-result calls.
materialsNoFilter by lowercase materials: e.g. ["cotton", "silk", "leather"]
max_priceNoMaximum price (in the currency specified by "currency" param, or USD if omitted)
min_priceNoMinimum price (in the currency specified by "currency" param, or USD if omitted)
silhouetteNoSilhouette/fit filter (e.g. fitted, slim, regular, relaxed, oversized). Soft descriptor — set ONLY when the user explicitly named the fit. The `query` field already captures silhouette semantically; over-specifying is the most common cause of zero-result calls.
color_matchNoColor matching mode. "any" (default): product has at least one of the queried colors. "exact": product has at least one image where the ONLY colors are the queried colors — use for mono-color searches like "all black".any
store_domainNoFilter by store domain (e.g. "thereformation.com"). Accepts forms with protocol, www, locale subdomain, or path — they are normalized to match the registered store.
exclude_colorsNoExclude products with these colors: e.g. ["white", "beige"]
is_sustainableNoTrue when the user explicitly wants products with sustainability claims.
available_sizesNoFilter by available size labels, e.g. ["s", "m", "38"].
exclude_materialsNoExclude products with these materials: e.g. ["polyester", "nylon"]

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
productsYes
marketUrlYes
hasNextPageYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses behavioral nuances: semantic ranking vs recency ranking, pagination, output format (compact product cards), multi-currency handling, and the zero-result risk from over-specifying filters. It also explains nested variant price differences, adding meaningful context not available in annotations.

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 long but well-structured with clear sections, examples, and a logical flow from purpose to usage to output. Every paragraph adds operational detail without filler. Given the tool's 25-parameter complexity, the length is justified, though it is more verbose than strictly necessary in places.

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

Completeness5/5

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

The description covers discovery modes, price parsing, currency conversion, output card content, and the explicit handoff to get_product for deeper data. With an output schema already present, it still adds context on return semantics and edge cases, making it complete for the tool's complexity.

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

Parameters5/5

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

Input schema has 100% coverage, so baseline is 3. The description adds substantial value: concrete query-construction tips ('noun-led with up to one or two modifiers works best'), example mappings from natural language to sparse filter populations, and explicit warnings that soft descriptors are the most common cause of zero-result calls. It clarifies category shortcuts, store domain normalization, and currency conversion—all beyond the schema's per-parameter descriptions.

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?

The description opens with a clear verb+resource ('Find fashion products') and explains the three operation modes (semantic query, structured browse, hybrid). It also positions itself against get_product, the deep-dive sibling, making its role as a discovery endpoint unmistakable.

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

Usage Guidelines5/5

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

Explicitly tells when to use semantic query vs structured filters vs both, and explicitly directs users to get_product for deep product details: 'For merchant description, store info, SKU-level variants, exact variant prices, and all product images, call get_product...' It also warns against over-specifying soft descriptors, providing actionable when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct resource and action: brands vs. products, discover vs. similarity, filters vs. product details. The boundaries are clear even between discover_brands and find_similar_brands, thanks to explicit descriptions of when to use each.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, using discover/find/get as verbs. The naming is uniform and predictable, with no mixed conventions or ambiguous synonyms.

Tool Count5/5

Six tools is an ideal size for a marketplace discovery server. Each tool has a clear purpose and collectively they cover search, similarity, filters, and retrieval without being bloated or sparse.

Completeness5/5

The tool surface covers the full discovery workflow: finding brands and products, refining by filters, getting similar items, and fetching detailed product data. No significant gaps are evident for the stated purpose of a fashion market search API.