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.5/5 across 6 of 6 tools scored.
Each tool targets a distinct functionality: brand discovery, product discovery, similar brands, similar products, filters, and product details. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using underscores (e.g., discover_brands, get_filters), making them predictable and easy to understand.
With 6 tools, the set is well-scoped for a fashion marketplace discovery server. Each tool has a clear purpose, and the count feels appropriate for the domain.
The tool set covers brand and product discovery, similarity, filters, and detail retrieval. A minor gap is the lack of a get_brand tool for brand-specific details, but core workflows are complete.
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 indicate readOnlyHint=true. The description adds valuable behavioral context: query is optional, country adjectives are parsed server-side (no translation needed), and brand/shipping signals are best-effort. 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 concise (~80 words) and front-loaded with the core purpose. Every sentence adds value: examples, parsing details, optionality note. No wasted or redundant information.
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 output schema exists, 8 parameters, and annotations, the description is complete. It covers usage modes, parameter interactions, and key caveats. No missing critical information for tool selection.
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%, baseline 3. The description adds meaning beyond schema: it explains that query and structured filters can be combined, clarifies the parsing of country adjectives, and notes the best-effort nature of brand shipping signals. This adds 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 'Find fashion brands using natural language, structured filters, or both' with specific query examples. It identifies the resource (brands) and verb (find), but does not explicitly differentiate from sibling tools like find_similar_brands within the description itself.
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 examples of appropriate queries ('Best for queries like...') and clarifies that query is optional, but does not explicitly state when NOT to use this tool or mention alternatives. The guidance is implicit through examples.
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 (readOnlyHint=true) indicate safety; description adds behavioral context: returns compact product cards with summary, price, images, tags, availability; variant price differences nested; multi-currency support. 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?
Description is lengthy but well-structured with examples and clear sections. Front-loaded with purpose and guidelines. Could trim some redundancy, but thoroughness is justified given complex params.
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, many with enums and soft descriptors, the description is exceptionally complete. Covers usage, return format (compact product cards), multi-currency, and references sibling tools. Output schema exists, so return details are covered.
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 has 100% description coverage, but description adds value beyond schema with usage patterns (e.g., 'Keep queries concrete: noun-led...'), examples mapping natural language to structured params, and warnings against over-specifying soft descriptors.
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 products using natural language and/or structured filters, with examples that distinguish it from siblings like get_product (detailed info) and discover_brands (brand discovery). The verb 'discover' plus resource 'products' is specific.
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?
Explicit guidance on when to use query vs structured filters, combined usage, and warnings against over-specifying soft descriptors (e.g., 'season', 'styles') which cause zero results. Examples illustrate correct usage.
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 safe read. The description adds details about the underlying vectors and the return limit, providing useful behavioral context 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?
Two sentences, front-loaded with purpose, no waste. Every sentence serves a purpose.
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 output schema exists, the description sufficiently covers input, method, and limit. It could mention that results are based on shared vectors, but overall complete.
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 67% schema description coverage, the description adds context for 'limit' by stating 'Returns up to 20 brands', complementing the schema. However, it does not elaborate on 'country' beyond the schema's 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 similar brands' and the resource 'brands', with a specific method 'using brand-profile vectors'. It distinguishes from siblings like 'discover_brands' and '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?
The description explicitly states the prerequisite 'Given a brand name', indicating when to use. It does not explicitly exclude alternatives, but sibling tool names provide context for differentiation.
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?
The description adds significant behavioral context beyond the annotations (readOnlyHint: true). It specifies that the tool returns compact product cards (not full variants), paginates with max 3 pages and up to 20 results per page, and provides a hasNextPage indicator. It also warns about what information is missing and where to get it (get_product). 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 three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, use case, what it returns, what it doesn't, and where to go for more detail. No unnecessary words or 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?
The description is fairly complete given the presence of an output schema (which is not shown but assumed). It covers what the tool does, its limitations, pagination, and alternatives. However, it could mention the sibling tools find_similar_brands or discover_products more explicitly to help the agent differentiate. But overall, it provides enough context for a 4.
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 100% description coverage, so the baseline is 3. The description adds value by explaining the behavioral impact of parameters (e.g., page limited to 1-3, limit up to 20, country for analytics, currency conversion fallback). It also explains the purpose of the product_id parameter (from previous search result). This improves understanding beyond the raw 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?
The description clearly states the tool's action ('find similar products') and the input ('Given a product ID'). It provides the use case ('more like this' recommendations, finding alternatives) and distinguishes from sibling tools like get_product (full variant detail) and find_similar_brands (brands vs 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 explicitly tells when to use this tool (for recommendations/alternatives) and when to use an alternative (get_product for full details). It also mentions pagination limits (max 3 pages, up to 20 results). However, it does not explicitly state when not to use it or compare with find_similar_brands or discover_products, which are siblings.
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?
Description adds behavioral context beyond readOnlyHint annotation: categoryTree ordering and hierarchy, brand_search effect only on brands, gender scoping, and country analytics recording. 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?
Well-structured with front-loaded purpose, then detailed parameter guidance. Slightly lengthy but each sentence adds value. Could be tighter but effective.
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 5 parameters, full schema descriptions, and an output schema, the description covers all aspects: default return set, parameter usage, categoryTree details, and links to sibling tool. No gaps.
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%, and description adds significant extra meaning: explains default behavior of fields, categoryTree structure, brand_search usage, gender scoping, and country purpose. Each parameter's semantic is well-explained.
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 returns available filter values in the catalog, listing default dimensions. It distinguishes from siblings by focusing on filter metadata, not products or brands directly, and mentions using categoryTree values with discover_products.category.
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: use 'fields' for specific dimensions to reduce data, 'brand_search' for brand prefix searching, and 'gender' to scope categoryTree. Implicitly suggests when to use this before discover_products. Lacks explicit exclusion criteria but overall helpful.
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 declare readOnlyHint=true (safe read) and openWorldHint=false. The description adds value by explaining that it retrieves detailed product data and requires a product_id from a previous search. No contradictions. It could mention rate limits or auth, but with annotations covering safety, this is adequate.
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, then usage guidance and listing of returned data. No fluff, every sentence 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?
The tool has an output schema, so return details are documented. The description covers the key items an agent needs to decide if this is the right tool (images, variants, prices, purchase link). No gaps noted given the 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?
Schema coverage is 100% for all 3 parameters. The description adds context beyond schema: 'Recorded for analytics', 'absence preserves current behavior', 'Defaults to USD' for currency. Also reinforces that product_id comes from a previous search, improving understanding.
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 'Get the detailed response for a specific product ID' (verb+resource). It distinguishes from siblings by specifying use after discover_products or find_similar_products and listing the detailed fields returned (merchant description, store info, images, SKU variants, etc.).
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 clear context: use this tool after discover_products or find_similar_products. Implicitly excludes other scenarios. Does not explicitly state when not to use, but the context is sufficient for an agent to decide.
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.