market
Server Details
Search and get fashion products recommendations across multiple e-ecom stores
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- vistoya/vistoya-mcp
- GitHub Stars
- 0
- Server Listing
- Vistoya
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.4/5 across 6 of 6 tools scored. Lowest: 3.6/5.
Each tool targets a distinct purpose (brand search, product search, brand similarity, product similarity, filter retrieval, product detail) with no overlapping functionality.
All tool names follow the verb_noun pattern consistently (discover_brands, discover_products, find_similar_brands, find_similar_products, get_filters, get_product).
Six tools cover the full product discovery workflow (search, recommendations, filters, detail) without unnecessary bloat or missing core operations.
The tool set covers all essential operations for a fashion discovery API: searching brands and products, finding similar items, retrieving filtering metadata, and fetching detailed product information.
Available Tools
6 toolsdiscover_brandsARead-onlyInspect
Find fashion brands using natural language, structured filters, or both. Best for queries like "Italian streetwear brands", "Scandinavian minimalist brands", "Japanese technical outerwear", "brands with avant-garde tailoring", or "brands like Rick Owens". Country adjectives ("Italian", "Scandinavian", "Nordic", "Japanese", "Iberian", "Benelux") are parsed server-side into shipping-origin filters; you don't need to translate them to ISO codes. query is optional — provide a query, structured filters, or both. Brand country/shipping signals are best-effort and separate from product availability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of brands to return (1-20, default 8). | |
| query | No | Natural language brand search query, e.g. "Italian streetwear brands", "Scandinavian minimalist brands", "Japanese technical outerwear", or "brands like Rick Owens". Country adjectives are parsed server-side — no need to translate them into ISO codes. Optional: when omitted, results are filtered by the structured fields below. | |
| style | No | Optional style filter, e.g. streetwear, minimalist, elegant, avant-garde, techwear. | |
| country | No | Optional 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. | |
| price_tier | No | Optional brand price-tier focus filter. | |
| gender_focus | No | Optional brand audience focus filters. | |
| category_focus | No | Optional brand category focus filters, e.g. ["clothing", "shoes"]. | |
| ships_from_country | No | Optional ISO-3166 alpha-2 country filter for best-effort store shipping origin, e.g. "IT", "US", "GB". This is not the same as brand origin. |
Output Schema
| Name | Required | Description |
|---|---|---|
| brands | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds behavioral details: best-effort country/shipping signals, parse behavior, and separation from product availability. 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?
Description is 5 sentences, front-loaded with purpose, and contains no unnecessary words. Efficient and well-structured.
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 complexity (8 optional parameters, mixed query/filter usage) and existence of an output schema, the description covers key contextual information: query semantics, filter optionality, server-side parsing, and best-effort caveats. Complete for reliable 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?
Schema coverage is 100%, so the schema already documents all 8 parameters. The description adds some overall context (e.g., country adjective parsing) but does not significantly enhance individual parameter meanings beyond what is in the schema. Baseline 3 is appropriate.
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 finds fashion brands using natural language, structured filters, or both, with explicit examples. It distinguishes from sibling tools like discover_products and find_similar_brands by focusing on brand discovery.
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?
Provides explicit usage context: examples like 'Italian streetwear brands', explains server-side parsing of country adjectives, and notes that query is optional. Lacks explicit alternatives for when not to use this tool versus siblings, but the context is strong enough for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_productsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| brand | No | Filter by brand name | |
| limit | No | Page size (1-20, default 12) | |
| query | No | Natural 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. | |
| colors | No | Filter by lowercase colors: e.g. ["black", "navy", "sage green"] | |
| gender | No | Gender filter. | |
| season | No | Season 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. | |
| styles | No | Style 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. | |
| country | No | Optional 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. | |
| pattern | No | Pattern 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. | |
| sleeves | No | Sleeve style filter. Soft descriptor — set ONLY when the user explicitly named the sleeve style. Do not infer from category or query. | |
| category | No | Category 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". | |
| currency | No | ISO 4217 currency code for min_price/max_price (e.g. "PLN", "EUR", "GBP"). Prices are converted to USD for filtering. Omit for USD. | |
| neckline | No | Neckline filter. Soft descriptor — set ONLY when the user explicitly named the neckline. Do not infer from category or query. | |
| occasion | No | Occasion 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. | |
| materials | No | Filter by lowercase materials: e.g. ["cotton", "silk", "leather"] | |
| max_price | No | Maximum price (in the currency specified by "currency" param, or USD if omitted) | |
| min_price | No | Minimum price (in the currency specified by "currency" param, or USD if omitted) | |
| silhouette | No | Silhouette/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_match | No | Color 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_domain | No | Filter 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_colors | No | Exclude products with these colors: e.g. ["white", "beige"] | |
| is_sustainable | No | True when the user explicitly wants products with sustainability claims. | |
| available_sizes | No | Filter by available size labels, e.g. ["s", "m", "38"]. | |
| exclude_materials | No | Exclude products with these materials: e.g. ["polyester", "nylon"] |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| products | Yes | |
| marketUrl | Yes | |
| hasNextPage | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds valuable behavioral context: semantic vs recency ranking, pagination, multi-currency support, automatic price parsing from query, return format (compact cards), and what is not included (SKU variants). No contradictions 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 somewhat lengthy due to the complexity of the tool, but it is well-structured with sections for query, filters, examples, and return behavior. Every sentence adds value, though some trimming could improve conciseness 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 25 parameters, an output schema, and read-only annotations, the description is fully complete. It explains usage, return format, and common pitfalls (e.g., over-specifying filters). An AI agent can confidently invoke this tool 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?
All 25 parameters have descriptions in the schema (100% coverage), but the description adds extra meaning beyond schema, such as when to set or omit soft descriptors (season, styles, etc.), explaining color_match modes, and providing normalization details for store_domain.
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 finds fashion products using natural language and/or structured filters. It distinguishes itself from sibling tools like get_product (which returns full details) and discover_brands.
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?
Provides explicit guidance on when to use natural language query vs structured filters, when to combine them, and when to avoid over-specifying certain filters. Includes example calls and directs users to get_product for more detailed data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_brandsARead-onlyInspect
Given a brand name, find similar brands using brand-profile vectors generated during product indexing. Returns up to 20 brands.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name (case-insensitive), e.g. "Rick Owens". | |
| limit | No | ||
| country | No | Optional 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| brands | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds context about the vector-based similarity method and the output limit of 20 brands. However, it does not disclose edge cases or behavior when the brand is not found.
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 concise sentences with no fluff. It front-loads the core purpose and efficiently covers input, process, and output.
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 presence of an output schema, the description adequately covers input (brand name), process (vectors), and output (up to 20 brands). It does not detail error handling or edge cases, but the scope is reasonable for a simple 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?
Schema coverage is 67% with descriptions for 'brand' and 'country' but not 'limit'. The description mentions the output limit but does not explicitly link to the 'limit' parameter. It adds context about the technique but not enough to compensate for the missing parameter description.
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 'find' and the resource 'similar brands', and explains the method using brand-profile vectors. It distinguishes itself from sibling tools like discover_brands and find_similar_products by focusing on brand similarity given a brand name.
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 like discover_brands or find_similar_products. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_productsARead-onlyInspect
Given a product ID, find similar products across the entire catalog. Useful for "more like this" recommendations or finding alternatives. Returns compact product cards, not full variant detail; call get_product for SKU-level variants, exact variant prices, merchant description, store info, and all images. Returns page and hasNextPage. Returns up to 20 results per page, paginated (max 3 pages).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-3) | |
| limit | No | Page size (1-20) | |
| country | No | Optional 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. | |
| currency | No | ISO 4217 currency code to render prices in (e.g. "GBP", "EUR", "USD"). Defaults to USD. Stored native prices are preferred; falls back to FX conversion when a merchant-set price isn't available. | |
| product_id | Yes | The product ID (from a previous search result) |
Output Schema
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| products | Yes | |
| hasNextPage | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive. Description adds pagination constraints (max 3 pages, 20 per page) and output format details (compact cards, hasNextPage). Good complement.
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, no filler. First sentence states core purpose, second clarifies distinction from get_product, third covers pagination. Efficient and well-structured.
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 output schema exists (not shown but present), annotations provide safety profile, and description covers purpose, usage, behavior, and pagination, it is complete for correct agent selection and 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?
Schema covers all parameters with descriptions (100% coverage). Description adds context: country for analytics/geo-matching, currency fallback behavior, and pagination limits tied to page param. Adds value beyond schema.
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?
Clearly states the verb 'find' and resource 'similar products', and explicitly distinguishes from get_product: 'returns compact product cards, not full variant detail'. Sibling context differentiates well.
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?
Explains when to use ('more like this' recommendations, finding alternatives) and when to use get_product instead. Could be more explicit about not using when discover_products or similar would be better, but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filtersARead-onlyInspect
Returns available filter values in the catalog. By default returns categoryTree plus brands, colors, materials, genders, occasions, seasons, styles, silhouettes, currencies, and price range. Use "fields" to request only specific dimensions — faster and less data. "categoryTree" is a flat DFS-ordered list of { value, label } entries; hierarchy is encoded in the value slug (e.g. "clothing/jackets/bomber-jackets"), parents appear before descendants, and every value can be passed directly to discover_products.category. Use "brand_search" to search brands by prefix instead of listing all. Pass "gender" to scope categoryTree to that gender (women/men/girls/boys); omit to see the merged union.
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | Which filter dimensions to return. Omit for all. Example: ["categoryTree", "colors", "priceRange"] | |
| gender | No | Scope categoryTree to this gender. Omit to return the merged union across women/men/girls/boys. | |
| country | No | Optional 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. | |
| brand_page | No | Page number for brands (12 per page). Use with or without brand_search. | |
| brand_search | No | Search brands by name (case-insensitive, prefix matches first). Only affects the brands field. |
Output Schema
| Name | Required | Description |
|---|---|---|
| brands | No | |
| colors | No | |
| styles | No | |
| genders | No | |
| seasons | No | |
| patterns | No | |
| materials | No | |
| occasions | No | |
| currencies | No | |
| priceRange | No | |
| silhouettes | No | |
| categoryTree | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, no contradictions. The description discloses default behavior (returns all fields), data structure of categoryTree (DFS-ordered, hierarchy encoded in slugs), and side effects (country recorded for analytics). It also notes performance implications of using fields parameter.
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 dense and front-loaded with the main purpose. Every sentence adds value, but it is somewhat lengthy. It balances detail with clarity, earning a high score but not perfect conciseness.
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 an output schema (not shown) and 100% schema coverage, the description covers all aspects: default behavior, parameter usage, special data structure, and side effects. It is fully complete for an AI agent to select and invoke the tool 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 coverage is 100% with descriptions for all 5 parameters. The description adds significant meaning beyond schema: explains categoryTree structure, brand_search behavior, default for gender, and that values can be passed to discover_products.category. This exceeds the baseline of 3 for high coverage.
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 'Returns available filter values in the catalog.' with specific verb and resource. It distinguishes from sibling tools (discover_products, discover_brands) by focusing on filter values. Details about default fields and behavior are provided.
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 explicit guidance on when to use specific parameters: 'Use "fields" to request only specific dimensions — faster and less data.', 'Use "brand_search" to search brands by prefix instead of listing all.', and 'Pass "gender" to scope categoryTree to that gender.' It does not explicitly mention when not to use the tool or compare to siblings, but the parameter guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productARead-onlyInspect
Get the detailed response for a specific product ID. Use this after discover_products or find_similar_products when you need merchant description, store info, all images, SKU-level availability variants, SKU, colorKey/size matrix, exact variant prices/compareAtPrice in the requested currency, and the direct link to purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Optional 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. | |
| currency | No | ISO 4217 currency code to render prices in (e.g. "GBP", "EUR", "USD"). Defaults to USD. | |
| product_id | Yes | The product ID (from a previous search result) |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| tags | No | |
| brand | No | |
| price | Yes | |
| store | No | |
| title | Yes | |
| colors | No | |
| gender | No | |
| images | No | |
| inStock | No | |
| sleeves | No | |
| summary | No | |
| category | No | |
| closures | No | |
| currency | Yes | |
| neckline | No | |
| materials | No | |
| productUrl | No | |
| silhouette | No | |
| availability | Yes | |
| isSustainable | No | |
| compareAtPrice | No | |
| relevanceScore | No | |
| similarityScore | No | |
| merchantDescription | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds behavioral context by enumerating return fields and mentioning currency rendering, which extends beyond what annotations provide.
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?
Description is a single sentence that is front-loaded with the main action. It lists many details but each is relevant and earned. Could be slightly more structured, but it's concise for the 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 the presence of an output schema, the description does not need to cover return values. It mentions all key outputs and is complemented by sibling tools list and full schema coverage. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all three parameters with descriptions (100% coverage). The description does not add significant parameter-level detail beyond the schema, but 'requested currency' aligns with the currency param. Baseline 3 is appropriate.
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 states the tool retrieves detailed product information for a specific ID, listing specific data fields (merchant description, store info, images, SKU variants, prices, purchase link). It distinguishes from siblings by specifying it should be used after discover_products or find_similar_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?
Explicitly states when to use: after discover_products or find_similar_products when detailed data is needed. Does not list when not to use, but the context is clear and guides proper invocation.
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!
Your Connectors
Sign in to create a connector for this server.