Skip to main content
Glama
Sign In

beyond-wine

by wine.beyond
OverviewDiscussionsAdmin

Search claims

search_claims
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. 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.

Input Schema

NameRequiredDescriptionDefault
pageNo
limitNo
claim_typeNo
entity_slugNo
entity_typeNo
reliability_classNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / claim_type / enum
      Added value: +[
+  "atomic_fact",
+  "structured_fact",
+  "editorial_claim"
+]
    • removedInput schema / properties / claim_type / minLength
      Removed value: -1
  2. First observed

TDQS

A3.9/5.0
Behavior5/5

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.

Conciseness2/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All beyond-wine toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources