Skip to main content
Glama

Get beverage

get_beverage
Read-only

Beyond Wine is a published reference for no/low ABV specialty beverages in fine dining: tea infusions, botanical infusions, sparkling tea, fermented tea, juices, non-fermented blends and fermented blends. It excludes non-alcoholic beer, non-alcoholic spirits, mocktails, mixers, dealcoholized wine and blends containing dealcoholized wine. For a request to recommend an excluded category, explain this scope without a catalogue lookup; an empty search is not how to establish this exclusion. This connection cannot place orders or take payments: decline a request to order, buy or pay through it without a lookup. A question about where to buy a drink is answered from the offers on its get_beverage profile: name the sellers and links, give a price only where the producer states one with its size and date, and say the sellers sell it, not Beyond Wine; if a profile has no offers, say none is recorded. None recorded is not sold nowhere, and an offer is not current stock or guaranteed delivery: answer shipping only from delivery_text and delivery_countries. Quote only price, currency, size and date values that are present on data.offers. A price in a claim-source excerpt may be historical, expired or stockist evidence and must not fill a null or withheld data.offers price. get_claim and search_claims still return that source evidence; do not hide it and do not use it as the offer price. Unknown price, size or delivery stays unknown. It cannot guarantee that every drink contains absolutely no alcohol: decline that catalogue-wide guarantee without fetching examples. Individual drink questions may use the tools to check declared wording and evidence. Do not invent a product or producer for these refusals. Retrieve a published beverage profile, a claim preview and evidence. Find the exact slug with search_beverages; never invent it. Check the returned producer against the question. The claims array is a preview of at most 20, not the full inventory. A full or condensed profile scans claims once, at most 100, and keeps that preview. evidence quotes scanned recorded statements and their public sources in alcohol, ingredients_technique and sensory only. Offer-tagged claims are dropped before those categories, even with a mixed tasting or alcohol tag. Offer-tagged claims are omitted. The selection is not the full inventory, even when evidence.has_more is false. get_claim and search_claims are follow-ups for a missing, cropped or contradictory statement or a deeper source, not a repeat of a source already returned. Use a source already on evidence when it is sufficient. Follow claims_api or get_claim only for an omitted, cropped, missing, contradictory or deeper claim. Do not follow claims_api solely because evidence.has_more is true when the needed proof was already returned. not_found_in_scanned_claims means no scanned claim matched the alcohol selector. Returned sources that already support the statement do not need another get_claim. get_claim remains valid for one omitted, cropped, missing, contradictory or deeper claim. Cite an actual returned source or citation_url and preserve its attribution and exact alcohol wording. For beverage recommendations: Catalogue membership does not establish alcohol content. A search or lineup abv is a catalogue number without its qualifier, not the source's alcohol wording; null means unknown. Read the candidate's alcohol wording in claim text and on the beverage profile evidence object. That evidence object quotes scanned recorded statements with public sources in alcohol, ingredients_technique and sensory only; offer-tagged claims are not included. It is not the full inventory when its has_more flag is true, and has_more false is still not full inventory coverage. Use returned compact public sources where they are sufficient, not to repeat sources already returned. Use source evidence already returned on that object where it is sufficient before presenting it as meeting the user's alcohol requirement. Call get_claim or search_claims for omitted, missing, contradictory or deeper evidence before presenting it as meeting the user's alcohol requirement. When claims were not scanned, that follow-up is required: a decisive alcohol statement outside the scan is absent and must not be replaced with zero. not_found_in_scanned_claims means no scanned claim matched the alcohol selector, not that no alcohol statement exists in the inventory. Do not infer zero from that absence or treat the scan as complete. Preserve declared wording; 'non-alcoholic' does not establish 0.0%. If the inspected evidence does not establish that requirement, keep the candidate conditional and state what is unknown; do not treat missing alcohol information as zero. Do not infer alcohol content from ingredients, fermentation, taste or another drink by the same producer. Preserve the source's exact alcohol wording. 0% and 0.0% are different wording, but that difference does not by itself establish different measured trace-alcohol thresholds. 'Below 0.5%' is an upper-bound declaration; these declarations do not by themselves prove measurement or laboratory testing. Do not infer that alcohol is absent from ingredients or production methods. data.offers lists sellers found in sources with links; read data.offers_caveat. Quote only price, currency, size and date fields present on data.offers. A price in a claim-source excerpt must not fill a null or withheld data.offers price. Answer sellers and shipping only from those recorded offers, not as current stock or guaranteed delivery. No offers means none is recorded, not sold nowhere.

Input Schema

NameRequiredDescriptionDefault
slugYes
condensedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the annotations: the claims array is 'a preview of at most 20', a profile scans 'at most 100' claims once, evidence covers only alcohol/ingredients_technique/sensory categories, offer-tagged claims are dropped, and has_more=false still does not mean full inventory coverage. Those are exactly the kind of non-obvious traits an agent cannot get from readOnlyHint. Points withheld only because much of the text concerns answering policy (pricing, ordering refusals) rather than this tool's own behavior, diluting the signal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly a thousand words for a two-parameter read tool, with the same rules restated verbatim three or more times (has_more semantics, offer-tagged claims omitted, price-from-offers). Purpose is buried past the first third of the text and nothing is front-loaded, so every sentence does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does sketch the return surface (claims preview, evidence object, data.offers, offers_caveat), which is genuinely needed. But coverage is unsystematic and the condensed variant is never characterized, so an agent still cannot predict what a condensed call returns versus a full one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden. It does give real slug semantics ('find the exact slug with search_beverages; never invent it'), which is useful. But 'condensed' is never explained functionally — the description only says 'a full or condensed profile scans claims once', leaving what condensing removes or changes entirely unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The actual function appears only in the middle of the block: 'Retrieve a published beverage profile, a claim preview and evidence.' An agent must wade through several hundred words of answer-policy before reaching verb+resource. Once found, it is specific and does distinguish the tool from search_beverages and get_claim, but the opening line describes the catalogue rather than the tool, so selection is harder than it should be.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules are present: 'Find the exact slug with search_beverages; never invent it' and 'get_claim and search_claims are follow-ups for a missing, cropped or contradictory statement..., not a repeat of a source already returned.' It also says which categories of request should be declined without a lookup. The guidance is strong in content but repeated three or four times, so it is harder to parse than a single clean statement would be.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources