GlanceAI Fashion MCP
Server Details
Fashion product discovery and virtual try-on via the Glance catalog
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 15 of 15 tools scored. Lowest: 2.7/5.
Most tools have distinct purposes, but some overlap exists between image retrieval tools (get_selfie, get_uploaded_image) and upload widgets (request_user_selfie, upload_image). Descriptions and usage instructions help differentiate them, but an agent could still misselect.
All tools follow a consistent verb_noun pattern in snake_case (e.g., check_selfie, get_product_details, wishlist_add). There are no deviations or mixed conventions, making the naming predictable and clear.
With 15 tools covering search, display, try-on, wishlist, and selfie management, the count is well-scoped for a fashion MCP server. Each tool serves a clear need without exceeding a manageable number.
The tool set covers core fashion workflows: search, product details, try-on (single and multi), wishlist management, and mix-and-match. Minor gaps like purchase or reviews are absent but reasonable given the server's focus on try-on and outfit building.
Available Tools
15 toolscheck_selfieCheck SelfieARead-onlyIdempotentInspect
Check if the user has already uploaded a selfie photo. Call this BEFORE requesting a new selfie or initiating a try-on. If a selfie exists, skip straight to try_on_product — do NOT ask the user to upload again.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds valuable context about flow integration (e.g., skipping to try_on_product), which exceeds what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded and contain no filler words. Every sentence serves a clear purpose: first defines the action, second gives usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, simple check), the description fully specifies its behavior and context. No output schema is needed; the return value is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description does not need to add parameter details; it's perfectly adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check if the user has already uploaded a selfie photo' which is a specific verb+resource. It distinguishes from siblings like 'request_user_selfie' and 'get_selfie' by focusing on existence checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this BEFORE requesting a new selfie or initiating a try-on. If a selfie exists, skip straight to try_on_product — do NOT ask the user to upload again.' This provides clear when-to-use and when-not-to-use, including the alternative tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mix_and_matchGet Mix and MatchCRead-onlyIdempotentInspect
Build a Mix & Match outfit widget for a fashion product.
AGENT INSTRUCTIONS — follow these steps before calling this tool:
Call search_fashion_products ONCE with all garment types as separate entries in the
queriesarray — one QuerySpec per garment type (e.g. [{query: "slim jeans", categories: ["bottomwear"]}, {query: "white oxford shirt", categories: ["topwear"]}, {query: "white sneakers", categories: ["footwear"]}]). This runs all searches in parallel. Do NOT make multiple sequential search_fashion_products calls.From the returned query_results, pick one SKU per category to build outfit combinations.
Build 2–4 outfit combinations. Each outfit should contain 2–5 items. Assign each product a slot based on its garment type (top, bottom, accessory, shoes). You may include up to 2 accessories per outfit. Fill every slot: top, bottom, shoes, and at least one accessory. If the anchor item is a dress or full-length outfit, skip the separate bottom slot.
Give each outfit a short, evocative collection name that captures its mood or occasion — e.g. "Coastal Sunday", "Urban Edge", "Garden Party", "Date Night". Keep it 2–3 words, title case.
Call this tool with the outfits array.
IMAGE-DRIVEN FLOW: When the user wants to mix and match with their own clothing item and has not uploaded an image yet, call upload_image first. Once they upload, call get_uploaded_image to analyse the item — extract its garment type, colour, and style. Use that description as the anchor query in step 1 to find the closest catalog match. That matched product SKU MUST appear as an item in every outfit you build — assign it its correct slot (e.g. top, bottom) and fill the remaining slots with complementary items.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | ||
| country | Yes | ||
| outfits | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, read-only behavior. The description adds that the tool 'builds' a widget, which could be interpreted as creating a view without side effects. No contradiction, but the description does not disclose return format or any side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and includes a verbose agent instruction list that belongs to a workflow guide, not a tool definition. It front-loads purpose but then expands with procedural steps, making it inefficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fails to describe the tool's output or behavior. It focuses on pre-call steps involving other tools (search_fashion_products) and omits details about the widget's appearance or what the tool returns. Key parameter information is missing for country and caption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains the 'outfits' parameter structure (items, slots, labels, limits) but provides no details for the 'country' (required) or 'caption' parameters. Partial coverage leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a Mix & Match outfit widget for a fashion product.' It distinguishes from sibling tools by its specific function of creating a composite widget, though it does not explicitly contrast with alternatives like show_products_carousel or try_on_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive procedural steps for preparing the input but does not explicitly state when to use this tool versus others. It implies usage for presenting outfit combinations but lacks comparative guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsGet Product DetailsARead-onlyIdempotentInspect
Fetch a single product by SKU and render a detail card with attributes, price, and CTAs.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | ||
| country | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds that it 'renders a detail card', which implies a presentation side effect but is consistent with a read operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource. It efficiently conveys the main purpose and expected output. However, it could be more concise by omitting 'attributes, price, and CTAs' if those are standard, but overall it's appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and annotations, the description is mostly complete. It specifies the output as 'detail card with attributes, price, and CTAs', compensating for missing output schema. It does not cover error cases or behavior when SKU not found, but basic functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears full burden for parameter explanation. It mentions 'by SKU' indicating sku identifies the product, but 'country' is left unexplained. No enum values or format hints are given, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'single product by SKU', and the outcome 'render a detail card with attributes, price, and CTAs'. It distinguishes from siblings like 'search_fashion_products' (search vs fetch) and 'show_products_carousel' (multiple products).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single product by SKU but does not explicitly state when to use this tool versus alternatives like 'search_fashion_products' or 'show_products_carousel'. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_selfieGet SelfieARead-onlyIdempotentInspect
Retrieve the user's selfie photo as an image block so you can analyse it (e.g. skin tone, outfit, body type). Call this when you need to visually inspect the user's photo.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. Description adds that the output is an 'image block' for analysis, which is useful context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and usage cue. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with annotations, the description adequately covers what the tool does and why. Could mention output format (e.g. base64 vs URL) and behavior when no selfie exists, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but this is appropriate given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'retrieve' and resource 'user's selfie photo', and specifies the analytic purpose (e.g. skin tone, outfit, body type). It distinguishes from sibling tools by focusing on the user's selfie specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this when you need to visually inspect the user's photo', providing clear context. However, it does not mention when not to use or alternatives like request_user_selfie.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_uploaded_imageGet Uploaded ImageARead-onlyIdempotentInspect
Retrieve the image the user most recently uploaded via the upload_image tool as an image block for analysis. WHEN TO CALL: Immediately after the user confirms their upload (message says 'Image uploaded successfully'). WHAT TO DO AFTER: Analyse the image and continue the original flow — describe what you see, extract style/colour/product details, and use that information to fulfil the user's request. Never wait for further instruction before analysing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds context about retrieving the image as an image block and the timing, but does not cover edge cases like missing upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus explicitly labeled sections (WHEN TO CALL, WHAT TO DO AFTER) make it concise and well-structured. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully covers purpose, usage timing, and post-action steps. It is complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description does not need to add parameter info. It correctly implies no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (retrieve), resource (most recently uploaded image), and distinguishes from siblings like upload_image. It explicitly mentions the context of analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
WHEN TO CALL and WHAT TO DO AFTER sections provide explicit timing and follow-up instructions, including never waiting for further instruction. This differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_looksGet User's AI LooksARead-onlyIdempotentInspect
Fetch the user's saved virtual try-on looks (avatar images generated from their selfie). Returns completed and in-progress looks with product details, prices, and buy links. Use this to show the user what outfits they have already tried on.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return content (looks with product details, prices, buy links). Annotations already indicate read-only and idempotent, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters and annotations covering safety, the description adequately covers the tool's purpose and return value, though pagination behavior is implied rather than explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the 'limit' and 'offset' parameters, leaving the agent to infer pagination from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches user's saved virtual try-on looks, which distinguishes it from siblings like get_mix_and_match and get_product_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context ('show the user what outfits they have already tried on') but does not specify when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_user_selfieRequest User SelfieAIdempotentInspect
Present an image upload widget so the user can share a selfie or photo. Use this for virtual try-on, visual search, or any feature that needs the user's image. The widget will notify when the upload is complete.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint, destructiveHint, and openWorldHint. The description adds that the widget notifies on upload completion, which is key behavioral info. No contradictions. Could mention privacy or permissions, but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every sentence adds value: what it does, when to use, and behavioral note. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and annotations present, the description covers purpose, usage context, and behavior. It lacks details on return value (e.g., what the widget returns), but that's acceptable as output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter info. It correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presents an image upload widget for sharing a selfie/photo. The verb 'present' and resource 'upload widget' are specific, and the tool is distinguished from siblings like 'upload_image' (general upload) and 'get_selfie' (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: virtual try-on, visual search, or any feature needing the user's image. While it doesn't mention when not to use or contrast with siblings like 'upload_image', the provided context is sufficient for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fashion_productsSearch Fashion ProductsARead-onlyIdempotentInspect
Search Glance's fashion catalog. Returns a text summary of matching products (SKUs, prices, brands). Shows a brief animated search preview — no interactive carousel. To display products visually in a browsable carousel, follow up with show_products_carousel passing the SKUs you want to highlight.
MULTI-QUERY GUIDANCE: For mix & match or outfit requests that require searching multiple garment types at once (e.g. top + bottom + shoes), pass all requirements as separate entries in the queries array in a SINGLE tool call. This runs all searches in parallel and returns one result row per query. Do NOT make multiple sequential search_fashion_products calls for the same user request.
| Name | Required | Description | Default |
|---|---|---|---|
| gender | Yes | ||
| country | Yes | ||
| queries | Yes | ||
| currency | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral details: returns a text summary, shows a brief animated search preview but no interactive carousel. No contradictions with annotations; it enriches agent understanding of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear purpose and separate guidance section. Front-loaded with essential information. Slightly lengthy due to multi-query details, but each sentence adds value. Could be trimmed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool complexity (many parameters, no output schema), the description covers purpose, usage boundaries, multi-query handling, and output expectation. However, lacks parameter details, which impacts completeness. Otherwise, context is well-provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only explains the `queries` array structure and multi-query usage, but does not describe other parameters like `brand`, `categories`, `max_price`, `occasion`, etc. Agents lack guidance on parameter semantics, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Glance's fashion catalog and returns a text summary of matching products, distinguishing it from visual display tools. It specifies the output format (SKUs, prices, brands) and the animated preview, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use (searching products) and when not to (for visual display, use show_products_carousel). Provides multi-query guidance for outfit requests, instructing to use a single call with array instead of multiple sequential calls. This effectively differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_products_carouselShow Products CarouselARead-onlyIdempotentInspect
Display a curated set of fashion products in an interactive scrollable carousel. Call this after search_fashion_products whenever the user wants to browse or view products — e.g. "show me", "let me see", "what options", "browse", or any phrasing that implies the user wants to see product images.
Pass only the SKUs you want to highlight, in relevance order.
Do NOT call for silent/background searches. Only call when the user actively wants to see products.
SUGGESTION: When presenting products from multiple distinct searches or categories (e.g. "tops and bottoms", "casual and formal options", "results for Alice and Bob"), make a separate show_products_carousel call for each group rather than mixing all SKUs into one. Use the header field to label each group. This gives the user clearly organised, scannable sections instead of one undifferentiated list.
| Name | Required | Description | Default |
|---|---|---|---|
| skus | Yes | ||
| header | No | ||
| country | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: displays a carousel, highlights SKUs in relevance order, and uses header for grouping. It reinforces safety and adds meaningful details beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by usage guidelines and a suggestion. It is well-structured and not excessively long. The suggestion part is valuable but slightly lengthy; overall earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no enums, the description covers main purpose, usage conditions, and parameter guidance for 'skus' and 'header'. It does not explain 'country' or what the carousel return format looks like, but annotations indicate read-only. Reasonably complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'skus' (pass SKUs to highlight in relevance order) and 'header' (label each group). However, 'country' is not explained despite being required. Partial coverage but adds value for two of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool displays a curated set of fashion products in an interactive scrollable carousel. It distinguishes from siblings by specifying it should be called after search_fashion_products for browsing/viewing, and gives examples of user intents like 'show me' or 'browse'. This is specific and differentiates effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call (after search_fashion_products when user wants to browse) and when not to call (silent/background searches). It provides a suggestion for organizing multiple groups with separate calls and header field, but does not explicitly compare with alternative sibling tools like show_wishlist, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_wishlistShow WishlistARead-onlyIdempotentInspect
Display the authenticated user's saved wishlist items in a scrollable fashion carousel. Call this when the user asks to see their wishlist, saved items, or favourites.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe operation. The description adds visual context ('scrollable fashion carousel'), which goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with function and usage. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description fully covers purpose and usage. No output schema required for such a simple display operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for zero parameters is 4; description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Display' and resource 'wishlist items', and specifies the format 'scrollable fashion carousel'. It distinguishes from sibling tools like wishlist_add and wishlist_remove by focusing on viewing saved items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'when the user asks to see their wishlist, saved items, or favourites'. While it doesn't mention when not to use or alternatives, the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
try_on_productVirtual Try-OnAInspect
Initiate a virtual try-on for a product. Requires a user selfie — if no selfie exists, call request_user_selfie first. The selfie widget will notify when the upload is complete, then call this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | ||
| gender | No | female | |
| country | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not destructive (destructiveHint=false). The description adds the user selfie requirement and the dependency on 'request_user_selfie', but does not disclose what the tool returns or initiates beyond the action of starting a try-on. No mention of output or side effects beyond the prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with no schema descriptions and no output schema, the description should provide more context on parameter meanings, expected behavior (e.g., what happens after initiation, success/failure responses), and error conditions. The dependency on a selfie is noted, but the overall completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description contains no information about any of the three parameters (sku, gender, country). It does not explain what 'sku' represents, the role of 'country', or the effect of 'gender' defaulting to 'female'. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Initiate a virtual try-on for a product' and specifies a prerequisite (selfie), differentiating it from siblings like 'get_mix_and_match' and 'try_on_products' (plural). The resource is a specific product identified by SKU.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool (when a selfie exists) and when not (if no selfie, call 'request_user_selfie' first), and provides a sequence instruction ('The selfie widget will notify when the upload is complete, then call this tool'). No alternative tools mentioned but the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
try_on_productsMulti-Product Virtual Try-OnAInspect
Initiate a virtual try-on for a complete outfit or collection — use this when the user wants to try on multiple products together (e.g. 'Try on Coastal Sunday', 'try on the full look', 'try on this outfit'). Collect all product SKUs that belong to the named outfit or collection from context (e.g. from a Mix & Match widget) and pass them as the skus array. Use try_on_product instead when the user refers to a single item. Requires a user selfie — if no selfie exists, call request_user_selfie first.
| Name | Required | Description | Default |
|---|---|---|---|
| skus | Yes | ||
| gender | No | female | |
| country | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is non-destructive and has a closed world (fixed parameters). The description adds critical behavioral context: it requires a user selfie and explains the prerequisite handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph. It front-loads the core purpose, then provides usage context, alternative guidance, and a prerequisite. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), the description is highly complete. It explains the main parameter, usage context, prerequisite, and fallback action. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the 'skus' array thoroughly (collecting SKUs for the outfit/collection). However, it does not explain 'gender' (default 'female') or 'country' beyond being required. Still, the description adds significant meaning for the most important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: initiating a virtual try-on for multiple products. It uses specific verbs ('Initiate a virtual try-on') and identifies the resource (complete outfit or collection). It distinguishes from the sibling tool 'try_on_product' by explicitly contrasting single-item vs multi-item use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool (when the user wants to try on multiple products together) and when to use an alternative (try_on_product for single items). It also specifies a prerequisite (user selfie) and instructs to call 'request_user_selfie' if missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_imageUpload ImageAIdempotentInspect
Present an image upload widget to the user. WHEN TO CALL: Any Glance flow that requires a user-provided image (visual search, outfit inspiration, style matching, product comparison, or any image-based analysis) and the user has NOT already uploaded one in their message. Do NOT ask the user to attach an image manually — call this tool instead to open the upload widget. WHAT TO DO AFTER: Once the user confirms the upload, immediately call get_uploaded_image to retrieve the image, analyse it, and then continue the flow based on what you see in the image.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds useful context that it presents a widget and is a UI action. While it could mention behavior on failure or cancellation, the existing detail is sufficient and consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear sections (WHEN TO CALL, WHAT TO DO AFTER). Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and annotations covering safety, the description is complete. It explains the tool's action, when to use it, and the follow-up step. No output schema is needed as the tool's effect is presentation of a widget.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so baseline is 4. The description correctly omits parameter details since there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Present an image upload widget to the user.' It uses a specific verb and resource, and distinguishes from sibling tools by specifying when it should be used (when user hasn't already uploaded an image) and that it opens a widget instead of manual attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'WHEN TO CALL' and 'WHAT TO DO AFTER' sections, providing clear guidance on when to use the tool (any Glance flow requiring user-provided image when user hasn't uploaded) and what to do next (call get_uploaded_image). It also instructs not to ask the user to attach manually, differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wishlist_addAdd to WishlistAIdempotentInspect
Save one or more fashion products to the authenticated user's wishlist.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, so the description adds moderate value by specifying 'authenticated user' context. However, it does not disclose behavior like duplicate handling or response format, which are left inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence of 12 words efficiently conveys the tool's purpose without extraneous text. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no output schema) and the annotation coverage, the description is adequate for basic understanding but lacks parameter details, usage guidance, and behavioral clarifications, leaving gaps for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should significantly explain parameters but only vaguely mentions 'one or more fashion products'. It does not clarify the 'id' and 'region' fields or any constraints, providing minimal additive value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Save', the resource 'fashion products', and the target 'authenticated user's wishlist'. It distinctively separates from sibling tools like 'wishlist_remove' and 'show_wishlist'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding items to the wishlist and mentions 'authenticated user', but it does not explicitly state prerequisites (e.g., requires authentication) nor when not to use (e.g., duplicate items). No alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wishlist_removeRemove from WishlistCDestructiveIdempotentInspect
Remove a fashion product from the authenticated user's wishlist.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| region | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds little beyond annotations: it confirms destructive behavior but does not clarify edge cases (e.g., removing a non-existent item) or authentication requirements. Annotations already indicate idempotent and destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence but lacks necessary details. It is front-loaded but does not earn its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, two parameters, and no parameter descriptions, the description is incomplete. It does not mention return values, error handling, or prerequisites beyond 'authenticated user'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain what 'id' and 'region' represent. It does not, leaving parameters ambiguous (e.g., is id a product ID?). No details on expected values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'fashion product from the authenticated user's wishlist', distinguishing it from sibling tools like wishlist_add and show_wishlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as checking if the item is in the wishlist first or using wishlist_remove instead of other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!