Skip to main content
Glama

GlanceAI Fashion MCP

by com.glance

Get Mix and Match

get_mix_and_match
Read-onlyIdempotent

Build a complete, multi-item Mix & Match outfit widget — several coordinated looks, each with multiple garments styled together. Use this when the shopper wants a full outfit or styling help, NOT a specific named item.

Three modes: • ANCHOR mode (anchor_sku): build outfits around one specific catalog product the shopper already has/likes. • QUERY mode (query): design complete outfits from an open-ended styling request with no anchor product — every item in every look is found via catalog search. • IMAGE mode (context_image_ref): style outfits around an uploaded image. Call request_context_image first to get a ref_id, then pass it here. If query and anchor_sku are both provided, query mode takes precedence. At least one of anchor_sku, query, or context_image_ref must be supplied.

DO NOT USE for a search where the shopper names a specific item/category with no styling ask (e.g. "red shoes", "blue dress", "men's oxford shoes") — that is a plain search, not an outfit request, even if a color/occasion/price filter is attached.

Examples:

  • "give me an outfit for a wedding" (no item named) → query mode: { query: "outfit for a wedding" }

  • "style me for a beach day" → query mode: { query: "beach day outfit" }

  • "what goes with my blue jeans" (jeans is a specific catalog SKU already shown) → anchor mode: { anchor_sku: "" }

  • "complete this look" (after showing/selecting a product) → anchor mode with that SKU

  • (after an uploaded photo) "build an outfit around this" → image mode: { context_image_ref: "" }

  • "red shoes" or "blue dress under 1000" → NOT this tool, just a plain product search

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSemantic styling request, e.g. 'casual summer outfit for a beach day' or 'smart-casual look for a business dinner'. The AI stylist designs complete outfits from scratch — every item is sourced from the catalog. Required field — pass an empty string "" if not applicable. Leave empty when there is a specific anchor product or an uploaded image instead.
genderYesGender of the products to search for. This is a catalog filter — NOT the user's own gender. Users may search for any gender's products regardless of who they are. Infer from context (e.g. 'men’s jacket' → MALE, 'ladies kurta' → FEMALE). If the query gives no clear signal, ask the user which gender’s products they want — do not assume.
captionNoOptional widget headline. Defaults to 'Ways to style <name>' or 'Outfits for <query>'.
countryNoISO country code the shopper is buying in, e.g. 'IN', 'US'. Scopes pricing, availability, the anchor lookup, and every complementary product search. Defaults to 'IN'.IN
occasionNoOptional occasion context, e.g. 'casual', 'party', 'work', 'wedding'.
max_priceNoOptional price ceiling for items.
tenant_idNoOptional tenant identifier. Forwarded to catalog search as context.tenant_id and used to select the brand DNA that drives the stylist prompt.
anchor_skuYesSKU of the anchor product to build outfits around, for anchor mode. Required field — pass an empty string "" if not applicable. Leave empty when using query mode or image mode.
context_image_refYesref_id returned by request_context_image. Pass it here to style outfits around the uploaded image — no anchor_sku or query needed. Required field — pass an empty string "" if not applicable. Call request_context_image first if the user has not uploaded an image yet.

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses critical behavioral rules: query mode takes precedence when query and anchor_sku are both provided, at least one of three mode identifiers must be supplied, and image mode requires calling request_context_image first. These behaviors are not inferable from the schema or annotations alone.

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?

The description is front-loaded with the core purpose, then organized into three clear mode bullets, a DO NOT USE warning, and illustrative examples. Although long, the length is justified by the tool's complexity (3 modes, 9 parameters) and every section earns its place.

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 complex, 9-parameter tool with no output schema, the description covers all invocation concerns: when to use, when not to use, mode selection, parameter semantics, precedence, and a prerequisite dependency. An agent can correctly select and invoke this tool based on the description alone.

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?

Even though schema coverage is 100%, the description adds meaning beyond the schema: it explains the three modes and their corresponding parameters, clarifies the one-of requirement and precedence, and gives examples that map natural-language requests to exact parameter values. This turns the parameter list into an actionable decision procedure.

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 first sentence states a specific verb and resource: 'Build a complete, multi-item Mix & Match outfit widget' with 'several coordinated looks, each with multiple garments styled together.' It immediately distinguishes this from plain product search by adding 'NOT a specific named item,' which separates it from sibling search_fashion_products.

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?

The description gives explicit when-to-use guidance ('Use this when the shopper wants a full outfit or styling help'), explicit when-not-to-use guidance ('DO NOT USE for a search where the shopper names a specific item/category'), and concrete examples mapping shopper statements to modes and parameter values. It also names the prerequisite sibling request_context_image for image mode.

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

All GlanceAI Fashion MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation3/5

Most tools target a clear resource (search, details, mix-and-match, wishlist, try-on), but search_fashion_products explicitly claims all styling/outfit requests while get_mix_and_match also handles outfit building, and both list 'what goes with my blue jeans' as an example. The selfie upload guidance also conflicts with try_on_product's built-in upload widget. Still, the detailed descriptions narrow most boundaries.

Naming Consistency4/5

All names use snake_case and a verb-first pattern (get_, request_, search_, show_, try_on), making the set predictable. Minor inconsistency: get_mix_and_match and get_user_looks are less noun-like than the rest, and the retrieve-style verbs vary between get, show, and request.

Tool Count5/5

8 tools is within the ideal 3-15 range and maps naturally to a shopping/styling assistant: search, detail, outfit, try-on, wishlist, saved looks, and uploads. No tool feels redundant enough to cut, and adding more would risk bloat.

Completeness4/5

The set covers the main shopper journey: search/browse, product detail, outfit building, virtual try-on, saved looks, and wishlist. The main gaps are wishlist mutation (add/remove) and an explicit way to manage/inspect selfies or context images, but these are workable around the existing tools.

Resources