Swiss merchant ARVI SA: 27,000+ fine & rare wine labels, 300,000+ bottles ready to ship. No auth.
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.
Average 4.6/5 across 6 of 6 tools scored. Lowest: 3.9/5.
Each tool has a clearly distinct purpose: search, facets, product details, vintages, similar products, and shop info. Descriptions explicitly guide when to use which, minimizing ambiguity.
All tool names follow a consistent verb_noun pattern (find_similar_products, get_catalog_facets, etc.), using snake_case throughout. No deviations.
With 6 tools, the server is well-scoped for a wine catalog: search, details, vintages, similar, facets, shop info. Each tool earns its place; not too many or too few.
The tool surface covers the full discovery workflow: from broad exploration (facets, search) to specific comparisons (vintages, similar) and purchase (details with links, shop info). No obvious gaps.
find_similar_productsAlternatives to a productAInspectAlternatives around a reference product id: other vintages and formats of the same wine, other wines from the same producer, and comparable in-stock wines from the same region and price band. Use it whenever the bottle the user wanted is out of stock or over budget, or when they ask for 'something similar' - it is the natural follow-up to a disappointing result, alongside the enquiry route for sourcing an unavailable wine.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Reference product id. | |
| limit | No | Max results per section. Default 8. | |
| locale | No | Catalog language code. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, whether it modifies data, or any other side effects. For a tool that likely queries a catalog, this omission is significant.
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 the core functionality and followed by usage guidance. No redundant text, 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?
While the description adequately explains when to use the tool and what types of results to expect, it does not describe the output format or structure. Without an output schema, this lack of detail could leave an agent unsure about how to process results.
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 parameter descriptions. The description adds context about the 'id' parameter by explaining how alternatives are derived (vintages, producer, region/price), but does not add new semantic information for 'limit' or 'locale' beyond what the schema provides.
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 defines the tool's purpose: finding alternatives to a reference product, listing specific types of alternatives (vintages, producer, region/price). It distinguishes itself from siblings like 'search_shop_catalog' or 'get_product_details' by focusing on similarity, not general search or 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?
Explicitly states when to use this tool: when the desired product is out of stock, over budget, or when user asks for 'something similar'. Also positions it as a natural follow-up to a disappointing result, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalog_facetsCatalog overview (facets)AInspectAggregated map of the ARVI catalog: top producers, countries, regions and categories, vintage range and distribution by decade, price bands in CHF and bottle formats, each with product counts. Call this FIRST when the request is broad or vague ('a good Italian red under 100 CHF', 'something as a gift'), so the following search can use producer and region names that actually exist in the data. Skip it when the user already named a specific wine or producer. Default in_stock_only is true.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Catalog language code. Defaults to 'en'. | |
| in_stock_only | No | Compute facets over available products only. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as returning aggregated data facets and states the default for 'in_stock_only'. While it doesn't explicitly say it is read-only, the context makes it clear. It could mention that no modifications occur.
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 that are front-loaded with purpose, followed by usage guidance and a default note. 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?
With no output schema, the description provides a thorough list of returned facets (producers, countries, regions, etc.) and their counts, which is sufficient for an agent to understand the output. It could detail the response structure more, but it is 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?
Schema coverage is 100%, so the description adds limited value beyond the schema. It reinforces the default for 'in_stock_only' and implicitly mentions locale when referring to 'in CHF', but does not add new parameter details.
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 provides an 'aggregated map of the ARVI catalog' with specific facets like producers, countries, regions, categories, etc. It differentiates itself from sibling tools by explicitly advising to call it first for broad or vague requests.
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 gives explicit when-to-use ('broad or vague', 'something as a gift') and when-to-skip ('user already named a specific wine or producer') instructions, and explains how the output can inform subsequent searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailsGet one productAInspectFull record for one product id returned by search: description, producer, vintage, bottle format, price in CHF, availability and the exact purchase link. Call it before recommending a specific bottle, so the answer carries the real tasting/estate description and a link the user can buy from, instead of a summary. For every vintage of the same wine use get_wine_vintages; for alternatives use find_similar_products.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id from search results. | |
| locale | No | Catalog language code. Optional. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description fully explains what is returned (fields including purchase link and real tasting description). Idempotent read behavior is implied. Could mention no side effects, but sufficient.
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: output fields, use case, alternatives. No wasted words, front-loaded with 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?
Complete for a simple read tool with 2 params and no output schema. Lists return fields, use case, and sibling differentiation.
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 100%, so baseline is 3. Description restates that id comes from search results, which is already in schema. No additional parameter meaning 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?
Clear verb+resource: returns full record for a product id. Lists fields and distinguishes from siblings like get_wine_vintages 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?
Explicit when to call ('before recommending a specific bottle') and when not to (use get_wine_vintages for vintages, find_similar_products for alternatives).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shop_infoAbout the shopAInspectFacts about the merchant ARVI SA plus live catalog statistics: currency, contact, how a purchase is completed, the 48-hour delivery commitment across Switzerland, how the wines are transported and stored, and the sourcing service for bottles not currently in stock. Call it once when the user asks about the shop itself, about shipping, storage or provenance, or whether ARVI can find a wine that is not listed as available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the kind of information returned (currency, contact, purchase process, delivery commitment, transport, storage, sourcing), with no annotations to contradict.
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, efficient and front-loaded with key information. Could be slightly more structured but still clear.
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 input or output schema, the description fully covers what the tool does and when to use it, making it self-contained for agent decision.
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 (0 required, 0 total), so baseline is 4. The description does not need to add parameter details.
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 title 'About the shop' and description clearly state the tool provides facts about the merchant ARVI SA and live catalog statistics, distinguishing it from sibling tools like search_shop_catalog or 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 explicitly states when to call it: 'Call it once when the user asks about the shop itself, about shipping, storage or provenance, or whether ARVI can find a wine that is not listed as available.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wine_vintagesVintages & formats of one wineAInspectThe complete vertical for ONE wine: every vintage and bottle format ARVI lists for it, each with price and availability. Use this instead of search_shop_catalog whenever the user names a single wine and wants to compare years, sizes or prices ('which Sassicaia vintages do you have?', 'is there a magnum?'). Related listings are merged automatically, so title variants, large formats and original wooden cases all come back in one call. Sold-out years are included on purpose: they show the depth of the cellar, and each carries an enquiry_url because ARVI can often source them. Identify the wine by product id or by name.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | A product id of any vintage/format of the wine. | |
| query | No | Wine name, e.g. 'Sassicaia' (used if no id is given). | |
| locale | No | Catalog language code. Defaults to 'en'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully covers behavioral traits: merging of related listings, inclusion of sold-out years with enquiry URLs, and automatic handling of title variants and formats. 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?
Three sentences, front-loaded with purpose, then usage, then behavior. Every sentence adds distinct value with no redundancy or 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 no output schema, the description explains return contents (vintages, formats, price, availability, enquiry_url for sold-out). It covers merging and sold-out inclusion but stops short of specifying pagination or limits, which are not critical for this 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 100% with descriptions for all 3 parameters. The description adds value by explaining when to use id vs query ('Identify the wine by product id or by name') and notes locale default, enhancing understanding beyond the 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 complete vertical for ONE wine: every vintage and bottle format ARVI lists for it', specifying the verb (get), resource (vintages/formats), and scope (single wine). It distinguishes from sibling 'search_shop_catalog' by explicitly directing when to use this tool instead.
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?
Usage is explicitly stated: 'Use this instead of search_shop_catalog whenever the user names a single wine and wants to compare years, sizes or prices'. Examples are given, and it clarifies that sold-out years are included for a specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_shop_catalogSearch the ARVI wine catalogAInspectSearch the live catalog of ARVI SA (arvi.ch), a Swiss merchant of fine and rare wines and spirits. Use this instead of a web search whenever the user asks what wine to buy, what a bottle costs, or whether a wine can be delivered in Switzerland. Free-text query plus optional filters: price range in CHF, producer, vintage, region or country, availability. Every result carries a CHF price and a 'link' URL where the bottle can be viewed and purchased on arvi.ch. Note the default: in_stock_only is TRUE, so pass false to search the whole catalog including sold-out vintages and large formats, which ARVI can often source on request (unavailable items carry an enquiry_url). Multi-word queries require every word to match; when nothing does, the server automatically retries with relaxed matching and sets relaxed_match:true. Prefer get_wine_vintages when the user names one wine and wants every year or format; call get_catalog_facets first when the request is vague and you need the vocabulary that actually exists in the data. Read-only, no authentication, 120 requests per minute.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per page. Default 10. | |
| query | No | Free-text search over title, producer, category and description, e.g. 'Barolo 2019' or 'Sauternes'. | |
| locale | No | Catalog language code, e.g. 'en'. Defaults to 'en'. | |
| offset | No | Pagination offset. Default 0. | |
| vintage | No | Filter by vintage year, e.g. 2019. | |
| category | No | Filter by category, region or country substring, e.g. 'Wine', 'Accessories', 'Piemonte', 'Bordeaux', 'Italy'. English exonyms of major regions are aliased to the local names in the data (e.g. 'Piedmont' matches 'Piemonte'). Coverage of region/country depends on feed data. | |
| producer | No | Filter by producer / brand, e.g. 'Gaja'. | |
| max_price | No | Maximum price (CHF). | |
| min_price | No | Minimum price (CHF). | |
| in_stock_only | No | Only products currently available. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: default in_stock_only=true, multi-word matching behavior, relaxed retry, rate limit, and output format (price, link, enquiry_url).
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 thorough but slightly verbose; however, every sentence adds value and the structure is well-organized, front-loading purpose and usage.
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 10 parameters, no annotations, and no output schema, the description covers all pertinent aspects: usage, parameters, behavior, error handling, rate limits, and output format, making it fully 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?
The description adds significant value beyond the schema, explaining matching semantics, default override behavior, alias resolution, and the meaning of unavailable items with enquiry_url.
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 searches the ARVI wine catalog and distinguishes it from siblings like get_wine_vintages and get_catalog_facets, specifying when to use each.
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 use this tool (user asks about buying wine, cost, delivery) and when to use alternatives (vintages or facets), including a note to prefer a web search otherwise.
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.
No comments yet. Be the first to start the discussion!