Public wine registry and guides: search wines, grapes, regions, appellations. No account.
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.5/5 across 7 of 7 tools scored.
Each tool addresses a distinct concern: registry search, wine detail, vintage-specific drink windows, similarity recommendations, guide listing, guide reading, and server metadata. No two tools serve the same purpose, and the descriptions clearly indicate when to use each.
Most tools follow a consistent verb_noun pattern (list_guides, read_guide, search_registry, get_wine, get_source_info, find_similar_wines). 'drink_window_for' is an outlier, using a noun phrase instead of an imperative verb, which introduces a minor inconsistency.
With seven tools, the server is well-scoped and avoids bloat. Each tool provides a distinct capability, and the count is appropriate for a wine registry server covering search, details, drink windows, similar wines, guides, and metadata.
The core registry workflow is well covered: search_registry for identification, get_wine for details, drink_window_for for aging advice, and find_similar_wines for recommendations. However, multiple descriptions reference search_bottles for user-owned bottles, yet that tool is not provided, leaving a notable gap for user-specific queries.
drink_window_forDrink window for a wineASommelier-curated drink windows for a registry wine: per vintage, when it is young, at peak, and in late maturity, with where the vintage stands right now. Call for "when should I drink ", aging questions, or buy-now-drink-later advice. Only sommelier-REVIEWED vintages are returned — an empty result means no curated window exists yet (reason from grape/region/structure yourself, and say it is an estimate).
| Name | Required | Description | Default |
|---|---|---|---|
| vintage | No | One vintage year; omit for all curated vintages of the wine | |
| wine_id | Yes | Registry wine id (from search_registry) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint) by explaining the drink window stages and the meaning of empty results (no curated window exists yet). It provides guidance to reason from grape/region/structure, which is helpful for agent decision-making. 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 a single, well-organized paragraph that front-loads the main purpose, immediately followed by usage scenarios and edge-case behavior. Every sentence is informative and necessary, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the absence of an output schema, the description adequately describes the output format (young, peak, late maturity, current status) and handles the empty-result case. Given the low complexity and strong annotations, the description is complete and leaves no critical 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?
The input schema already has 100% description coverage, with clear explanations for both wine_id and vintage (including that omitting vintage returns all curated vintages). The description reinforces this but does not add new semantic meaning beyond the schema, so baseline score of 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 provides sommelier-curated drink windows for registry wines, detailing per vintage stages (young, peak, late maturity) and current status. It includes example queries like 'when should I drink <wine> <vintage>', making the purpose specific and distinguishable from sibling tools such as find_similar_wines or get_wine.
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 the tool: for 'when should I drink' questions, aging queries, or buy-now-drink-later advice. It also clarifies that only sommelier-reviewed vintages are returned and advises how to handle empty results. While it doesn't explicitly say when not to use it, the context and sibling tool list provide sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_winesFind similar wines ("more like this")AGiven a registry wine_id (or, on an authenticated connection, one of the user's bottle_ids), returns wines with the closest taste/style profile from the shared registry, using vector similarity over wine embeddings. Call for "more like this", "what else is like my favourite Barolo", or to seed purchase ideas from a wine the user loves. Only wines that have been embedded are searchable — an empty result does not mean nothing similar exists. Ids must be 24-hex Mongo ids from search_registry or search_bottles — a name or slug is not an id. Returns at most 10.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-10, default 8; larger values are capped, not rejected) | |
| wine_id | No | Registry wine id (24-hex) from search_registry or a bottle's wine | |
| bottle_id | No | Alternatively: one of the user's bottle ids (24-hex). Needs an authenticated connection — not available on the public endpoint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation, such as the vector-similarity mechanism, authentication requirement for bottle_id, the caveat that an empty result does not prove absence of similar wines, and the id format restriction. This gives the agent a clear behavioral model without any contradiction with the 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 that pack essential details: function and inputs, use cases, and critical caveats. It is front-loaded with the primary purpose and avoids repetition or filler, making it efficient for an agent to parse.
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 modest complexity (3 optional params, read-only, no output schema), the description covers all necessary operational aspects: input origins, authentication, result count cap, and interpretation of empty results. It is sufficiently complete for an agent to invoke the tool correctly without ambiguity.
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?
While the schema already covers all parameters (100% coverage), the description adds important semantics: wine_id vs. bottle_id roles, the need for an authenticated connection for bottle_id, and that ids must be Mongo hex ids from specific sources. This goes beyond the schema's basic descriptions, though limit is only lightly touched ('at most 10').
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 function: 'returns wines with the closest taste/style profile from the shared registry, using vector similarity over wine embeddings'. It specifies the input types (wine_id or bottle_id) and output (up to 10 similar wines), distinguishing it from sibling tools by focusing on similarity search rather than generic registry lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Call for "more like this", "what else is like my favourite Barolo", or to seed purchase ideas'. It also provides a clear exclusion: ids must be 24-hex Mongo ids from search_registry/search_bottles, not names/slugs, and notes the limitation about embedded wines, giving practical guidance on interpreting empty results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_source_infoAbout this Cellarion instanceAReturns what Cellarion is, the version this instance is running, the open-source repository, and the license. Call this when the user asks what Cellarion is, which version they are on, whether it is open source, where to find / contribute to the code — or how to support the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it specifies the exact returned information (Cellarion, version, repository, license). Annotations already indicate read-only and non-destructive behavior, so the description complements them without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and usage. Every sentence earns its place; no fluff 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?
Given no output schema, description fully covers what the tool returns. Includes common user queries (open source, support). Context of sibling tools (wine-related) makes this independent tool 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?
No parameters exist, so schema description coverage is 100%. The description adds no param info, which is appropriate. Baseline for zero parameters is 4.
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 returns specific information: what Cellarion is, version, repository, and license. It uses specific verbs and resources, distinguishing it from sibling tools like get_wine or find_similar_wines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to call the tool (user asks about Cellarion, version, open source, etc.). It lacks explicit when-not-to-use or alternatives, but given the sibling context, the usage is clear and well-guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_wineGet one registry wineAFull registry record for one wine: producer, region, appellation, classification, grapes, community rating, and the AI tasting profile when the wine has been enriched. Vintage-neutral (bottles carry the vintage). Call after search_registry when the user wants depth on a specific wine.
| Name | Required | Description | Default |
|---|---|---|---|
| wine_id | Yes | Registry wine id from search_registry or a bottle's wine |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds behavioral context: vintage-neutral, AI tasting profile conditionally included, and lists returned fields. Provides useful detail 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 concise sentences: first describes output, second gives usage guidance and a behavioral note. No wasted words, front-loaded with key 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 low complexity (1 param, no output schema), the description provides sufficient information: fields returned, when to use, and vintage nuance. Could mention what happens if wine not found, 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?
Single parameter wine_id has full schema coverage. Description reinforces its source (from search_registry or bottle's wine) and suggests usage order, adding context beyond the schema 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?
Description clearly states the tool retrieves a full registry record for one wine, listing specific fields. It differentiates from sibling tools like search_registry by specifying 'Call after search_registry when the user wants depth on a specific wine.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after search_registry for depth on a specific wine, giving clear context. Lacks explicit when-not-to-use or alternatives, but the sibling list and context cover most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_guidesList wine guides & articlesACellarion's published guides and blog articles (cellar management, drink windows, storage, buying) — title, slug, excerpt and tags. Call when the user wants a how-to or background reading; follow with read_guide for the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag | |
| limit | No | How many to return (1-20, default 10; larger values are capped, not rejected) | |
| offset | No | Skip this many (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, and the description adds context about the returned fields (title, slug, excerpt, tags) and the relationship to read_guide. This is useful beyond the annotations, though it omits any ordering or pagination behavior (which is partially covered by schema params).
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 purpose and followed by usage guidance. No wasted words; 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?
Despite lacking an output schema, the description enumerates the returned fields, which addresses the main unknown. It also provides follow-up context (read_guide) and the tool is simple enough that no further detail is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning, but the schema already documents tag, limit, and offset well.
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 what the tool does: lists Cellarion's published guides and articles with metadata fields. It distinguishes itself from sibling read_guide by noting it returns excerpts and pointing to read_guide for full text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use ('when the user wants a how-to or background reading') and names the alternative (read_guide) for full text. This is clear, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_guideRead a guide / articleAThe full text of one published Cellarion guide or blog article, by slug (from list_guides). Public website content — quote or summarise freely, and link the public_url when pointing the user to it.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug from list_guides |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; description adds that it is public website content, which reinforces safety and clarifies the nature of the output without contradicting 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 with no wasted words, front-loaded with the core action, and includes essential tips on 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?
For a simple read tool with one parameter and no output schema, the description fully covers what the tool returns, how to use it, and the expected behavior.
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 the single parameter 'slug'; the description restates the schema description, adding no new meaning 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?
The description clearly states it reads the full text of a guide/article by slug from list_guides, which is a specific verb+resource and distinguishes it from sibling tools like list_guides.
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 advises to quote or summarise freely and link the public_url, providing clear usage context and telling the agent how to reference the content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_registrySearch the shared wine registryASearches Cellarion's shared wine database (vintage-neutral wines, community data) by name, producer, region or grape. Returns up to 10 matches. Call to identify a wine the user mentions, before recommending, or to check whether a wine exists in the registry. This searches ALL known wines — use search_bottles for what the user owns.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Wine name, producer, appellation or grape |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds that it returns up to 10 matches and searches by specified fields. No contradictions, but some behavioral details like pagination or ordering are missing.
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 four sentences, front-loading the main purpose and then adding usage context. It is relatively concise but could be tightened by merging sentences 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?
For a single-parameter search tool with no output schema, the description covers purpose, input semantics, result limit, usage scenarios, and an alternative tool, making it fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear parameter name 'query' and description. The tool description restates valid search fields but does not add new semantics beyond the schema, so baseline score of 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 searches the shared wine registry by name, producer, region, or grape, and distinguishes from the sibling tool 'search_bottles' by noting this searches all wines versus user-owned bottles.
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: to identify a wine mentioned, before recommending, or to check existence. It also advises when not to use it (use search_bottles for user-owned wines), providing clear context.
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!