Skip to main content
Glama

Get context

get_context
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 token-bounded context bundle for a Beyond Wine topic, including entity summary and optional claims or graph data. 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.

Input Schema

NameRequiredDescriptionDefault
topicYes
includeNo
max_tokensNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already establish readOnly/openWorld/non-destructive, and the description adds genuinely non-redundant behavior: token bounds, the has_more flag meaning 'not full inventory', the scan-limit semantics of not_found_in_scanned_claims, and the fact the evidence object covers only alcohol/ingredients_technique/sensory claims while excluding offer-tagged claims. These are tool-specific behavioral traits an agent could not get from the annotations or schema.

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

Conciseness2/5

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

Roughly 600 words, of which the actual tool behavior is a single sentence; the remainder is catalogue policy, refusal scripting and citation rules that belong in a system prompt. The purpose statement is neither front-loaded nor visually separable from the surrounding prose, so an agent must scan the whole block to find what the tool does.

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

Completeness4/5

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

For a three-parameter tool with no output schema, the description does disclose the shape of the return (entity summary, optional claims/graph, evidence object fields, has_more flag), which is more than most. The main gap is undefined topic semantics, but overall an agent has enough to call and interpret the tool.

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 coverage is 0%, so the description must compensate. It partly does: 'entity summary and optional claims or graph data' effectively explains the include enum values, and 'token-bounded' gestures at max_tokens. But the required 'topic' parameter is never defined — no indication whether it is a name, slug or entity id — and no defaults or bounds for max_tokens are given.

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

Purpose4/5

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

The operative sentence — 'Retrieve a token-bounded context bundle for a Beyond Wine topic, including entity summary and optional claims or graph data' — gives a specific verb, resource and payload. It is clear but buried roughly two-thirds of the way into the text, and there is no differentiation from siblings such as get_entity, which retrieves what sounds like a subset of the same data.

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

Usage Guidelines3/5

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

There is real guidance, but it is about follow-up tooling ('Call get_claim or search_claims for omitted, missing, contradictory or deeper evidence') rather than about when to choose get_context over get_entity, get_beverage or search_beverages. The many 'decline without a lookup' rules imply usage boundaries without ever stating what a user request that should trigger this tool looks like.

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