Skip to main content
Glama

Search producers

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

Input Schema

NameRequiredDescriptionDefault
qNo
cityNo
pageNo
limitNo
regionNo
countryNo
techniqueNo
ingredientNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness2/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources