My Wine

search_offers

Search live purchase offers for wine, scoped to the user's marketplace region.

This is the end of the sommelier flow — call it once you have collected the user's preferences (see the /sommelier prompt). It always returns retail OFFERS (never abstract products): every result is a real listing from a shop with a price and a purchase link.

IMPORTANT:

query MUST be English space-separated keywords, NO commas/prepositions. Use "" if the user specified no wine characteristics. Apply semantic translation (e.g. "шампанское" → "Champagne"; "steak" → "red tannic bold Cabernet Sauvignon"). NEVER include a city, price, currency, shop name, or the word "wine".
price_min and price_max are REQUIRED. If the user named a number with price intent, use it exactly. Otherwise map cheap/mid/premium to the t1/t2/max thresholds from get_user_region. For a range ("от 20 до 50") set BOTH bounds — never drop the lower one.
vintage: set to the exact year AND also include that year in query whenever the user names a specific year. Omit if no year was mentioned.
shop_names: only when the user named a retailer — pass the exact "Name (ID)" strings returned by search_shops (call search_shops FIRST).
Show the result to the user EXACTLY as returned — do not summarize or reformat.

Args: query: English space-separated wine keywords (may be ""). price_min: Minimum price (usually 0.01 unless a lower bound was given). price_max: Maximum price. price_currency: ISO code if the user named a currency (e.g. "EUR"); else "". shop_names: Up to 5 "Name (ID)" strings from search_shops, or omit. vintage: Specific vintage year, or omit if none.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`query`	Yes
`vintage`	No
`price_max`	Yes
`price_min`	Yes
`shop_names`	No
`price_currency`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral burden and does so thoroughly: it discloses that results are real retail listings with price and purchase link, that they must be shown exactly as returned, and it imposes query-construction rules (English keywords, no forbidden tokens, price ranges must keep both bounds). No behavioral surprises are left unstated.

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

Conciseness5/5

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

The definition is long but every sentence is actionable, and it is well-structured: a one-line purpose, a short context paragraph, a bulleted IMPORTANT block, then an Args list. Front-loading the scope and flow makes it easy to scan.

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

Completeness5/5

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

Given a tool with six parameters, zero input-schema descriptions, no annotations, and an output schema that can define return shape, this description is complete: it covers when to call, parameter semantics, sibling dependencies, and exact output-touching behavior. Nothing needed for correct invocation appears to be missing.

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

Parameters5/5

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

Schema description coverage is 0%, but the Args section fully compensates by explaining every parameter: query must be English keywords, price_min defaults to 0.01, price_currency takes ISO codes, shop_names are exact 'Name (ID)' strings capped at 5, and vintage is an exact year. The description also clarifies required-versus-omitted behavior beyond the schema.

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

Purpose5/5

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

Opens with a specific verb+resource statement: 'Search live purchase offers for wine, scoped to the user's marketplace region.' It further differentiates from siblings by stating it is the end of the sommelier flow and always returns retail OFFERS, never abstract products, which distinguishes it from get_user_region and search_shops.

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

Usage Guidelines5/5

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

Explicitly says to call it once preferences are collected, names the sibling flow, and gives sequencing: 'call search_shops FIRST' when shop_names are needed, and maps price tiers to 'thresholds from get_user_region.' This tells an agent when to use the tool and how it relates to the alternatives.

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

All My Wine tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: get_user_region supplies marketplace configuration, search_shops finds retailers by name, and search_offers returns actual product listings. The descriptions also explicitly define when each tool should and should not be used, leaving no ambiguity.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern: get_user_region, search_offers, search_shops. The verbs are simple and accurately reflect the action, making the set predictable and easy to navigate.

Tool Count5/5

Three tools is a well-scoped size for a focused wine-search assistant: one to fetch required user context, one optional helper for shop filtering, and one terminal search action. Each tool exists to support a distinct step in the flow with no redundant additions.

Completeness5/5

The tool surface fully covers the described sommelier flow: obtain region constraints, optionally resolve named shops, then search offers. There are no dead ends—search_offers terminates with purchasable results, and the supporting tools address all necessary preconditions.

Resources

Need Help?