Skip to main content
Glama

search_products

[FIND] START HERE when you know what you want. Free-text search across every active RRG listing. This endpoint answers DEFINED intent, not open browse. Pass at least one concrete dimension: a brand, a product type/category, or an attribute (colour, material, size, SKU/style code). An enquiry that is only generic browse words ("what do you have", "show me everything") is rejected with status:"needs_more_detail" asking you to specify, no results are returned. To browse without intent, call list_drops instead. Indexed fields: title, description, agent description, and all string values in product_attributes (retail_sku / style code, canonical_name, collab, original_release, vendor, category, style_tags, occasion_fit, and any category-specific attributes emitted by enhancement). Accepts any of these query patterns:

  • product name or partial name

  • SKU / style code / model number (exact or partial, dash/space insensitive)

  • brand name, or brand + category (" ")

  • collaborator name(s) for collab items

  • attribute keywords from the description ("black suede", "heavyweight cotton", etc.) Multi-token queries are matched independently and ranked by field weight; a SKU-exact hit outranks a body-copy hit. Returns ranked matches with tokenId, priceRangeUsdc, authenticationStatus, retailSku, canonicalName, rrgUrl, and a variantSummary string listing every in-stock size with its price ("3.5=$1583, 4=$1899, 10.5=$770, …").

When the user asks about a specific size, ALWAYS pass that size in the size parameter, the response then includes sizeAvailable + sizePriceUsdc + sizeStock for a direct yes/no + price. For queries like "size 10.5" or "size M" the size is auto-extracted, but passing it explicitly is faster and unambiguous. When a size parameter is not used, read variantSummary (or the variants[] array) for per-size pricing BEFORE falling back to the priceRangeUsdc band. Per-size prices are exact; the band is only a floor→ceiling range.

Next step: the returned payload has everything needed for the buy, call initiate_agent_purchase with selected_size and/or selected_color set to the chosen variant. Pass selected_color whenever the listing has a colour axis (variants[].color non-null) so fulfillment ships the right finish. get_drop_details is optional (adds signed image URLs + shipping context).

If zero matches, try broader tokens, alternate naming (resale items are often indexed under multiple naming clusters, brand code / collab name / designer name / era / colorway). If still zero, call list_drops to browse.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoOptional size filter (e.g. "10.5", "M", "UK 8"). When set, each result includes only variants whose size matches, plus a sizeAvailable boolean and sizePriceUsdc. Results with sizeAvailable=false are still returned (marked unavailable) so the agent can report correctly.
limitNoMax results (default 10)
queryYesFree-text query. Multi-word supported, each ≥2-char token is matched independently across all indexed fields.
brand_slugNoOptional brand slug to scope the search. Call list_brands to see slugs.

TDQS

A5/5.0
Behavior5/5

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

With no annotations, description fully discloses behavior: rejection status on vague queries, indexed fields, match ranking, returned fields, size auto-extraction and exact-price guidance, and variantSummary semantics. Provides exact pricing priority and notes unavailable variants are still returned.

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

Conciseness5/5

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

Long but front-loaded with '[FIND] START HERE'. Every sentence carries unique operational guidance: rejection behavior, query patterns, ranking, size handling, pricing precision, next-step calls, and zero-match fallbacks. Structure uses clear sections and actionable bullets.

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?

For a 4-param tool with no annotations and no output schema, the description is exceptionally complete. It covers purpose, alternative tools, parameter semantics, return payload contents, size-variant behavior, failure handling, and follow-up actions. No critical gaps.

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?

Schema coverage is 100% but description adds substantial meaning: query pattern types (SKU dash/space insensitive, brand+category, collaborator), multi-token independent matching, size parameter behavior vs. auto-extraction, and brand_slug source via list_brands. This far exceeds schema 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?

Description states a specific verb and resource: 'Free-text search across every active RRG listing.' It clearly distinguishes itself from sibling tools by contrasting with list_drops for browsing without intent and get_drop_details for optional detail augmentation.

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: 'START HERE when you know what you want.' Gives exclusions: generic browse words are rejected with needs_more_detail. Names alternatives: 'To browse without intent, call list_drops instead' and describes next-step tool calls.

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

A3.9/5.0
Disambiguation4/5

Most tools have distinct purposes with clear category tags. Minor potential confusion between get_current_brief vs list_briefs and get_brand vs get_brand_mcp_endpoint, but descriptions clarify intent.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using lowercase with underscores, e.g., check_agent_standing, list_drops, submit_design. No mixing of conventions.

Tool Count3/5

32 tools is on the high side, but the server covers a wide domain including browsing, purchasing, design submission, concierge, and marketing. Each tool serves a specific function, though some consolidation could be possible.

Completeness4/5

The tool surface covers the full lifecycle of browsing, purchasing, design creation, commissions, and concierge services. Minor gaps like refund handling are absent, but the core workflows are well-supported.