beyond-wine
Server Details
Claims-based knowledge base for no/low ABV specialty beverages (producers, beverages, people).
- Status
- Healthy
- Uptime
- 100.0% over 80 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 11 tools
The search/get pairs (search_beverages→get_beverage, search_producers→get_producer, search_claims→get_claim) are cleanly split by resource, but get_entity explicitly also returns full beverage profiles with evidence, overlapping get_beverage, and get_context bundles entity+claims+graph, overlapping nearly everything. The 700-word boilerplate shared by every description buries the discriminating paragraph, so an agent must read to the end of each tool text to tell them apart.
Every tool is verb_noun snake_case with a small verb set (get_, search_, list_), e.g. get_beverage, get_producer, search_beverages, list_entities. The pattern is predictable and consistent across all 11 tools.
11 tools is a well-scoped count for a read-only reference with beverages, producers, claims, entities, graph and ontology. The count is slightly inflated by meta-tools (get_context, get_graph, get_ontology) whose value relative to the core search/get pairs is marginal.
The surface covers the full read lifecycle for its domain: discovery (search_beverages/search_producers/list_entities), retrieval (get_beverage/get_producer/get_entity), evidence drill-down (get_claim/search_claims), plus graph and ontology. Gaps are minor: there is no keyword search across arbitrary entity types (restaurants, people) and no offers/seller-oriented tool, forcing agents to rely on embedded profile data.
Available Tools
11 toolsget_beverageGet beverageBRead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| condensed | No |
TDQS
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.
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.
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.
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.
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.
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.
get_claimGet claimARead-onlyInspect
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 claim with provenance.sources and version history. Copy claim_uid from a profile or claim search. On a beverage, use this when evidence is missing, cropped or contradictory, or when a deeper source or version history is needed. Use this to check a source behind a profile claim preview; cite an actual returned source or citation_url and preserve its attribution. One claim does not establish that no other records or sources exist. If the inspected evidence does not establish the requirement, keep the candidate conditional. Do not call it only to repeat a source already returned on evidence. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_uid | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive and open-world, and the description reinforces rather than contradicts them, adding that it returns provenance sources and version history (valuable since there is no output schema). It also discloses an open-world caveat the annotations only hint at: 'One claim does not establish that no other records or sources exist,' and warns against inferring alcohol absence. Much of the surrounding text is refusal policy for the server overall rather than behavior of this call, which caps it below 5.
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 dominated by material unrelated to invoking this tool: catalogue scope, refusal scripts for ordering and alcohol guarantees, and offer-price quoting rules. The tool's actual contract arrives near the end, so the text is back-loaded and the agent must read several hundred words before learning what get_claim does. Substantial pruning would improve selection accuracy.
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 read tool with no output schema, the description does cover return content (provenance.sources, version history) and open-world limits, so it is not missing critical facts. But the signal is diluted by server-wide policy, and the shape of the returned claim (fields beyond sources) is left vague, so completeness is offset by poor prioritization.
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?
There is one parameter and schema coverage is 0%, so the description must carry the load. It does tell the agent where the value comes from ('Copy claim_uid from a profile or claim search'), which is genuinely useful, but it adds nothing about format, stability, or what happens with an unknown uid. Adequate but thin for the sole required input.
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 tool's function is stated specifically: 'Retrieve a published claim with provenance.sources and version history,' with a clear verb and resource. It also differentiates from siblings, directing agents to use it over a profile claim preview when 'evidence is missing, cropped or contradictory' or a deeper source is needed. The problem is placement rather than content: the purpose sits roughly two-thirds of the way through the description, behind several hundred words of catalogue-scope and refusal policy.
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?
Genuine invocation guidance is present and explicit: use it on a beverage when evidence is missing, cropped or contradictory, or when version history is needed, and 'Do not call it only to repeat a source already returned on evidence.' It also names the alternative (profile claim preview, search_claims) and the input source ('Copy claim_uid from a profile or claim search'). No explicit when-not beyond that one negative case, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contextGet contextARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| include | No | ||
| max_tokens | No |
TDQS
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.
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.
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.
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.
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.
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.
get_entityGet entityBRead-onlyInspect
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 entity profile with structured data and claim previews. When the entity is a beverage, read its evidence object for scanned recorded statements in alcohol, ingredients_technique and sensory only. Offer-tagged claims are not in that object, and has_more false is not full inventory coverage. The claims array is still only a preview. Use a source already on evidence when it is sufficient. Follow up only for an omitted, cropped, missing, contradictory or deeper record, and do not repeat a source already returned. Cite actual returned source or claim URLs. Profiled entities (producers, beverages, people, restaurants) are independent businesses documented by Beyond Wine, not brands of it. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| condensed | No | ||
| entity_type | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses substantial behavioral constraints: the connection cannot place orders or take payments, offer prices must come only from data.offers, evidence objects cover only alcohol, ingredients_technique, and sensory, and has_more false is not full coverage. It also explains not_found_in_scanned_claims and the difference between recorded offers and current stock or delivery guarantees.
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 extremely long, repetitive, and not front-loaded around what get_entity does. It repeats rules about offer-tagged claims, has_more, and source reuse multiple times, so many sentences do not earn their 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?
For a three-parameter read-only lookup with no output schema and no schema descriptions, the description over-explains policy while leaving key invocation details unclear. It partially describes profile and evidence return semantics, but it does not explain slug, condensed, or the full entity_type enum, and it never routes the agent away from specialized sibling tools.
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 0%, so the description must explain slug, condensed, and entity_type. It mentions producers, beverages, people, and restaurants, but omits ingredient, technique, and prepared_ingredient from the enum, and it never explains slug format or the condensed flag.
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 does state a specific action and resource: 'Retrieve a published entity profile with structured data and claim previews.' However, that purpose is buried under extensive catalogue-scope policy text, and the description never distinguishes get_entity from sibling tools such as get_beverage or get_producer.
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?
It gives some follow-up guidance, such as using returned source evidence first and calling get_claim or search_claims only for omitted or contradictory evidence. But it does not clearly say when to use get_entity instead of get_beverage, get_producer, or other sibling lookups, so the primary selection guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_graphGet graphCRead-onlyInspect
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 direct relationship neighbors for an entity profiled in the Beyond Wine knowledge base.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| entity_type | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, open-world, non-destructive behavior. The description adds that it returns 'direct relationship neighbors' for an entity 'profiled' in the knowledge base, which clarifies traversal depth and the existing-entity requirement, but it does not describe the return shape, relationship types, or error behavior.
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 extremely long and front-loaded with unrelated scope and refusal policy. The actual purpose of get_graph appears only in the final sentence, so it is badly structured and not concise.
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 two-parameter graph retrieval tool with no output schema, the description should explain what neighbor data is returned and how entity_type affects traversal. Instead, it mostly covers global catalogue policy and gives only a minimal statement of the tool's graph 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 description coverage is 0%, and the description never mentions the required 'slug' or 'entity_type' parameters. It does not clarify the enum values for entity_type or how slug should be formed, so it fails to compensate for the undocumented 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 final sentence states a specific verb and resource: 'Retrieve direct relationship neighbors for an entity profiled in the Beyond Wine knowledge base.' This is clear enough to identify the operation, but it does not differentiate get_graph from siblings such as get_entity, get_context, or get_ontology.
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 contains extensive catalogue scope and refusal guidance, but almost none of it explains when to use get_graph instead of get_entity, get_context, or other sibling tools. There is no explicit when-to-use or when-not-to-use guidance for the graph retrieval operation itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ontologyGet ontologyCRead-onlyInspect
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 the Beyond Wine ontology, entity types, relationship types, and semantic scales.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context beyond that: the catalogue's inclusion/exclusion scope, that the connection cannot take orders or payments, and the rule that exclusions are explained rather than probed with empty searches. Most of this policy concerns sibling tools, but it is real context an agent would not get from 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?
Roughly a dozen sentences of catalogue policy precede the one sentence that defines the tool, so the purpose is back-loaded and an agent skimming the first line would misidentify it as a scope statement. Large portions (offer pricing, delivery_text, claim-source evidence) belong to get_beverage and get_claim, not here.
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 and no annotation detail about the response, the description should say what the ontology payload contains (entity types, relationship types, semantic scales) and how to use it — it lists these terms only in the final clause without explaining their structure or how an agent should consult them when interpreting other tools' 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?
The single 'format' parameter (enum json | json-schema) has 0% schema description coverage, so the description must compensate — and it says nothing about the parameter or what the two formats return. The agent is left to guess what json-schema output means in this context.
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 actual function is only stated in the final sentence: 'Retrieve the Beyond Wine ontology, entity types, relationship types, and semantic scales.' Everything before it describes the catalogue's domain scope and refusal policy rather than what the tool does. There is no differentiation from siblings like get_graph or get_context, so an agent cannot tell from this text which tool yields the ontology versus the graph.
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 is full of when-to-refuse guidance, but almost none of it tells an agent when to call get_ontology versus get_graph, get_context, or list_entities. The one relevant implication is that ontology knowledge underpins valid entity/relationship types, but that is never stated as invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_producerGet producerBRead-onlyInspect
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 specific producer documented by Beyond Wine. Includes the producer's published beverage lineup under data.beverages. Use search_producers first when the producer slug is unknown. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| condensed | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the result includes the producer's published beverage lineup under data.beverages, but it says nothing about not-found behavior or how the condensed flag changes the response.
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 text is a long, unbroken policy dump whose opening sentences describe Beyond Wine's catalogue scope rather than this tool. The actual get_producer instruction is buried mid-paragraph, so the definition is neither concise nor front-loaded.
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 read-only two-parameter lookup with no output schema, the description does not fully explain the returned producer shape beyond data.beverages, does not cover not-found behavior, and leaves condensed undefined. The extensive policy content does not compensate for these tool-specific 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 0%, and the description only indirectly documents the required slug by referring to 'the producer slug' and advising search_producers when it is unknown. The optional condensed boolean is never explained, leaving one of the two parameters with no semantic guidance in either the schema or the 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 eventually states 'Retrieve a specific producer documented by Beyond Wine' and notes that the response includes the producer's published beverage lineup under data.beverages, then routes unknown slugs to search_producers. That is a clear verb and resource with a named sibling alternative, though it is buried behind extensive domain policy rather than front-loaded.
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?
It explicitly says 'Use search_producers first when the producer slug is unknown,' which is the key alternative for this tool. It also sets broad when-not-to-look-up policies for excluded categories and ordering requests, but does not directly compare get_producer with get_beverage or get_entity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_entitiesList entitiesCRead-onlyInspect
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. List published entity profiles in the Beyond Wine knowledge base by type. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| entity_type | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine domain context (what the catalogue includes and excludes, that membership says nothing about alcohol content, that prices in claim sources are not offer prices), which is useful behavior beyond the annotations. However, it discloses nothing about the listing operation itself, such as pagination, result ordering, or whether entity_type filters strictly.
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 long policy essay with the actual tool purpose stranded in the middle of it. Many sentences are about refusals, price provenance and alcohol-wording rules that belong in the domain instructions or other tools' descriptions, not in a list tool's definition.
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?
There is no output schema, so the description should explain what a list_entities result looks like (profile summaries vs full profiles, pagination metadata) and clarify how entity_type values like prepared_ingredient behave. It instead spends its budget on refusal policy, leaving the tool's own contract underspecified.
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 0%, so the description carries the full burden for three parameters including a required enum. It never mentions entity_type, the allowed values, page, limit, or defaults, so an agent gets no help from the description at all on parameters. This is a clear failure to compensate for the schema gap.
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 actual purpose appears late in a single sentence: "List published entity profiles in the Beyond Wine knowledge base by type." That is a clear verb+resource, but roughly 90% of the description is catalogue policy and refusal rules, so the core function is buried rather than front-loaded. It does not distinguish itself from siblings like get_entity or search_beverages beyond the word "list".
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?
There are extensive when-not-to-use rules (no ordering, no catalogue-wide alcohol guarantees, handling excluded categories and price questions), but these are scoping rules for the Beyond Wine domain rather than guidance on when to call list_entities instead of search_beverages, get_entity, or get_graph. The agent is told many things it must not do with the connection, but nothing about when this paginated entity listing is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_beveragesSearch beveragesARead-onlyInspect
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. Find a beverage by name or alias. Start here for drink names, not search_producers. q matches a beverage name, alias OR producer name; a combined producer-plus-product phrase may not match. For a recorded ingredient, pass ingredient and do not put that ingredient in q. ingredient is one exact published name, slug or complete alias; matching is case-insensitive and not a substring. The only whole-string fallback is strawberries to strawberry, and it does not run when a published literal identity, including a literal alias, already matches. Producer search still matches an ingredient as a substring; this bottle search does not. Results are recorded eligible relationships, not complete recipes or every drink in existence. Do not combine ingredient with preferences. If a name search is empty, try a distinctive product word or search the producer separately and inspect its lineup. Optional preferences takes the exact words dry, bright, tannic, earthy, smoky or floral, at most 6 unique values. Translate an ordinary dinner question into those words, for example a dry floral glass with no maker named, or something bright to open the meal. This tool does not parse an arbitrary sentence in q. dry is an explicit drink-level dry or not-sweet tasting statement, not dried fruit, storage, process, semi-dry, low sugar, acidity, fruit aroma, a product name, a dry tannin or a catalogue ABV. A paired dish, an ingredient, an intermediate process and a tasting tag alone are not proof. An offer tag is neither proof nor a contradiction, even with a tasting or alcohol tag, a dry or floral sentence, or a price in the source excerpt. Every requested word must be supported by a current public sensory claim. A miss is this candidate window, not the whole catalogue. Use producer with an exact producer slug to list its drinks. Verify the returned beverage name and producer, copy its exact slug into get_beverage and read its evidence. Call get_claim only for omitted, missing, contradictory or deeper evidence. Use source evidence already returned on the profile where it is sufficient. Do not infer nonexistence from an empty search or silently substitute another product. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| page | No | ||
| limit | No | ||
| category | No | One in-scope category: tea_infusion (Tea Infusion), botanical_infusion (Botanical Infusion), sparkling_tea (Sparkling Tea), fermented_tea (Fermented Tea), juice (Juice), nonfermented_blend (Non-Fermented Blend), fermented_blend (Fermented Blend). | |
| producer | No | ||
| ingredient | No | One exact published ingredient name, slug or complete alias. Use this instead of q for an ingredient question. strawberries maps to strawberry only when no published literal identity matches. Not a substring. Do not combine with preferences. | |
| preferences | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/non-destructive; the description adds substantial behavior the agent could not otherwise know — no order placement, no catalogue-wide zero-alcohol guarantee, empty results are not evidence of absence, results are recorded eligible relationships rather than complete recipes, and `not_found_in_scanned_claims` semantics. These are exactly the failure modes an agent would otherwise get wrong.
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?
A single undifferentiated block of well over a thousand words with no headings or paragraph breaks, mixing scope, refusals, parameter rules, and alcohol-wording policy. Several instructions are stated two or three times almost verbatim (e.g. "use source evidence already returned" and "call get_claim or search_claims for omitted, missing, contradictory or deeper evidence"), and the sentence naming the tool's actual action is not front-loaded.
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 7-parameter open-world search with no output schema and only 29% schema coverage, this covers essentially everything an agent needs: candidate-window vs. full-catalogue caveats, how to verify via get_beverage and its evidence object, when follow-up claims lookups are mandatory, and how to preserve declared alcohol wording. Nothing material is missing.
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?
At 29% schema coverage the description carries the load and does: `q` matches name, alias OR producer name and does not parse arbitrary sentences or combined producer+product phrases; `ingredient` is exact, case-insensitive, non-substring, with a single strawberries→strawberry fallback; `preferences` accepts only six literal words and cannot be combined with `ingredient`. Only `page` and `limit` go unmentioned, which is a minor omission given their schema defaults.
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 operative statement is specific: "Find a beverage by name or alias. Start here for drink names, not search_producers" gives a verb, a resource, and an explicit sibling contrast. However, it is buried roughly a third of the way in, after a long preamble about catalogue scope and refusal handling, so an agent skimming the opening sentences gets domain context rather than the tool's action.
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-use (drink names, ingredient questions via `ingredient`, producer lineup via `producer`), when-not-to-use (excluded categories such as NA beer, mocktails, dealcoholized wine; ordering/payment requests), and named alternatives for each case (search_producers, get_beverage, get_claim, search_claims). It also specifies recovery paths for empty results (try a distinctive product word, search the producer separately) and forbids substitution or inferring nonexistence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_claimsSearch claimsARead-onlyInspect
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. Find published claims with their source provenance. To answer about a specific drink or producer, supply BOTH entity_type and its exact returned entity_slug. For a sourced statement, these two filters are normally sufficient: omit claim_type and reliability_class unless needed. claim_type is a record format (atomic_fact, structured_fact, editorial_claim), not a topic such as ingredients or collaboration. Inspect provenance.sources and describe producer statements, interviews, and independent reporting with their actual attribution. When a beverage profile already returned evidence, use that source where it is sufficient; follow-up for claims past that scan. Use this for a missing, cropped, contradictory or deeper record, not only to repeat a source already returned. Follow meta.has_more pagination before making negative findings about the queried records and filters. Limit those findings to sources actually inspected; completing pagination does not establish that evidence is absent elsewhere. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| claim_type | No | ||
| entity_slug | No | ||
| entity_type | No | ||
| reliability_class | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/destructiveHint already covering the safety profile, the description still adds substantial behavioral context beyond annotations: that provenance.sources must be inspected and attributed, that source excerpts may contain historical or expired prices that must not be used as offer prices, that pagination is exposed via meta.has_more, that negative findings must be bounded to sources actually inspected, and that alcohol wording must be preserved verbatim. No claim conflicts with the readOnly/openWorld 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 dense block run to roughly 400 words, and the majority of it is server-level commercial policy (orders, payments, where-to-buy, offer prices, catalogue-wide alcohol guarantees) that is irrelevant to selecting or invoking search_claims. Front-loading is poor: purpose and parameters appear late, and an agent must read through refusal scripts before learning what the tool returns.
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?
There is no output schema, and the description compensates by naming the return structures an agent will encounter: provenance.sources, data.offers with price/currency/size/date, and meta.has_more for pagination. Together with pagination-completion rules and negative-finding limits, it is complete enough to call the tool correctly, though the unexplained reliability_class enum remains a residual gap.
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 0% across 6 parameters, so the description must carry the load. It does well on entity_slug (must be the exact returned slug) and claim_type (explicitly "a record format... not a topic such as ingredients or collaboration"), which corrects a likely misuse. But reliability_class's four enum values (primary/secondary/tertiary/editorial) are never explained, and page/limit semantics are only implied by the meta.has_more pagination note.
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 core statement "Find published claims with their source provenance" is a specific verb+resource and is reinforced by the differentiation from get_claim ("follow-up for claims past that scan... not only to repeat a source already returned"). However, this purpose sentence is buried roughly two-thirds of the way down a description dominated by catalogue-scope, ordering and pricing policy, so an agent skimming the opening gets no signal about what the tool does.
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?
It gives strong, concrete routing rules: supply BOTH entity_type and its exact returned entity_slug for a specific drink or producer, omit claim_type and reliability_class for a sourced statement, use this for a missing/cropped/contradictory/deeper record, and follow meta.has_more before making negative findings. It also names explicit when-nots (excluded beverage categories, ordering/payment, catalogue-wide zero-alcohol guarantees) with the instruction to decline without a lookup. The gaps are that most of these exclusions are domain refusals rather than tool-alternative routing, and no explicit contrast is drawn with search_beverages or search_producers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_producersSearch producersARead-onlyInspect
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. Find producers by name, country, city, ingredient or technique. This searches producers, not beverage names: use search_beverages for a drink. If empty, try a shorter producer name or remove extra filters. Copy the exact returned slug into get_producer, whose data.beverages contains the lineup. Alternatively, use search_claims with both entity_type producer and the exact returned slug. A producer profile does not include beverage evidence. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| city | No | ||
| page | No | ||
| limit | No | ||
| region | No | ||
| country | No | ||
| technique | No | ||
| ingredient | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/openWorldHint already declared, the description still adds real behavioral context specific to this call: an empty result must not be used to establish an excluded category, the connection cannot order or pay, and slug values are what downstream tools consume. Much of the remaining text describes get_beverage/get_claim behavior rather than this tool's own, which dilutes but does not contradict 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 purpose sentence appears near the end of a very long block dominated by alcohol-evidence and pricing policy that pertains to other tools. Front-loading is absent and many sentences do not earn their place in a search_producers definition.
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?
Enough is present to call the tool correctly and to route results into get_producer/search_claims, and there is no output schema to explain. However, with 8 undocumented parameters and no description of result shape or pagination, the definition is padded with off-topic policy rather than the missing calling detail.
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 0% across 8 parameters, so the description must compensate. It does map q, country, city, ingredient and technique to searchable fields, but says nothing about region, page, limit, defaults (20), or the 100 max. Partial compensation only, so a 3.
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?
Late in the description it states a concrete verb and resource: 'Find producers by name, country, city, ingredient or technique' and 'This searches producers, not beverage names: use search_beverages for a drink.' That is a clear, sibling-differentiating purpose. It is undermined only by being buried after several paragraphs of domain scope and refusal policy.
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 routing exists: use search_beverages for a drink, copy the exact returned slug into get_producer, or use search_claims with entity_type producer and the slug. It also names a fallback ('If empty, try a shorter producer name or remove extra filters'). It loses a point because the majority of the usage text concerns refusals and price policy for the whole server rather than when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search_beverages1 field changed- added
Input schema / properties / ingredientAdded value: +{ + "description": "One exact published ingredient name, slug or complete alias. Use this instead of q for an ingredient question. strawberries maps to strawberry only when no published literal identity matches. Not a substring. Do not combine with preferences.", + "type": "string" +}
1 tool update
- Changed
search_beverages3 fields changed- added
Input schema / properties / category / descriptionAdded value: +"One in-scope category: tea_infusion (Tea Infusion), botanical_infusion (Botanical Infusion), sparkling_tea (Sparkling Tea), fermented_tea (Fermented Tea), juice (Juice), nonfermented_blend (Non-Fermented Blend), fermented_blend (Fermented Blend)." - added
Input schema / properties / category / enumAdded value: +[ + "tea_infusion", + "botanical_infusion", + "sparkling_tea", + "fermented_tea", + "juice", + "nonfermented_blend", + "fermented_blend" +] - removed
Input schema / properties / category / minLengthRemoved value: -1
1 tool update
- Changed
search_beverages1 field changed- added
Input schema / properties / preferencesAdded value: +{ + "items": { + "enum": [ + "dry", + "bright", + "tannic", + "earthy", + "smoky", + "floral" + ], + "type": "string" + }, + "maxItems": 6, + "minItems": 1, + "type": "array" +}
1 tool update
- Changed
search_claims2 fields changed- added
Input schema / properties / claim_type / enumAdded value: +[ + "atomic_fact", + "structured_fact", + "editorial_claim" +] - removed
Input schema / properties / claim_type / minLengthRemoved value: -1
1 tool update
- Changed
search_beverages1 field changed- added
Input schema / properties / producerAdded value: +{ + "minLength": 1, + "type": "string" +}
11 tool updates
- First observed
get_beverage - First observed
get_claim - First observed
get_context - First observed
get_entity - First observed
get_graph - First observed
get_ontology - First observed
get_producer - First observed
list_entities - First observed
search_beverages - First observed
search_claims - First observed
search_producers
Related MCP Connectors
Machine-readable entity discovery with provenance, trust and verified source evidence.
Human-verified directory of non-alcoholic bars: 1,500+ venues in 70 cities, rated and re-checked.
Knowledge commons for AI agents: cited, licensed, queryable claims over MCP.
Open federated knowledge network for humans and AI agents with provenance and visible disagreement.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides a compiled knowledge substrate, extracting atomic claims from an append-only capture log and querying a bitemporal claim graph over MCP. Read-only by default, with opt-in writes for trusted sources.4MIT
- AlicenseNot gradedqualityAmaintenanceServes AI clients on demand with atomic, provenance-tracked claims about your people, teams, systems and decisions, exposing search, open, timeline, correct and define tools so assistants can pull what is currently true rather than stale document fragments. It also lets clients correct or define knowledge in place, so retrieved facts stay accurate and reversible over time.27 PyPIMIT
- AlicenseNot gradedqualityBmaintenanceEnables agents to query a single-source ontology of types, entities, statements, evidence, and controlled vocabulary, including bitemporal "as of" and "as recorded" fact lookups. Supports writing by letting agents propose candidate statements while keeping approval, review transitions, and authoritative reasoning restricted to approved facts.MIT
- AlicenseNot gradedqualityAmaintenanceProvides AI agents a shared long-term memory layer with evidence-backed, auditable claims, enabling persistent, explainable, and conflict-aware recall across sessions.92 PyPI7MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.