Skip to main content
Glama
zhdenny

Bar Assistant MCP Server

by zhdenny

smart_search_cocktails

Search cocktails by ingredients, flavors, or similarity using batch processing to retrieve complete recipes with measurements, instructions, and specifications.

Instructions

🚀 PREFERRED TOOL: Advanced cocktail search with intelligent batch processing and complete recipes.

🎯 BATCH PROCESSING SYSTEM:

  • High Performance: Parallel processing with 5-10x speed improvement

  • Smart Caching: Automatic caching for 70%+ faster repeated searches

  • Error Resilience: Individual failures don't break entire batch operations

  • Flexible Limits: Configure result count (default: 20, max: 50)

📋 Use Cases:

  • General searches: "gin cocktails", "winter drinks", "classic cocktails"

  • Similarity queries: "cocktails like Manhattan", "similar to Negroni"

  • Ingredient-based: "cocktails with bourbon", "drinks using Campari"

  • Flavor profiles: "bitter cocktails", "sweet drinks", "herbal spirits"

  • Complex filtering: combine ingredients, ABV ranges, glass types, methods

  • Batch comparisons: Multiple ingredient searches simultaneously

🔄 Batch Processing Examples:

  • Single search: {query: "Manhattan"} → Complete recipe + similar cocktails

  • Multi-ingredient: {ingredient: "gin", must_include: ["vermouth", "bitters"]}

  • Similarity batch: {similar_to: "Negroni", limit: 10} → 10 similar cocktails

  • Complex filter: {preferred_flavors: ["bitter"], abv_min: 25, limit: 15}

📊 Response Format: Returns structured data with complete recipes including:

  • Ingredients with precise measurements in oz (auto-converted from ml)

  • Step-by-step preparation instructions

  • Cocktail specifications (ABV, glass, method, garnish)

  • Direct links to cocktail database pages

  • Performance metrics (processing time, cache hits)

  • Similar cocktail recommendations with full recipes

⚡ Performance Features:

  • Parallel API processing for multiple results

  • Intelligent caching system with TTL management

  • Batch fetching of complete recipe details

  • Error isolation and fallback handling

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo🔍 Natural language search query (e.g., "Negroni", "gin cocktails", "bitter drinks")
similar_toNo🔄 Find cocktails similar to this name (e.g., "Manhattan", "Negroni"). Triggers similarity batch processing.
similar_to_idNo🆔 Find cocktails similar to this ID. Use similar_to (by name) unless you have the specific ID.
ingredientNo🥃 Primary ingredient filter (e.g., "gin", "whiskey", "campari"). Combines with other filters for batch processing.
must_includeNo✅ Required ingredients array. Batch processes cocktails containing ALL these ingredients.
must_excludeNo❌ Excluded ingredients array. Filters out cocktails with ANY of these ingredients.
preferred_flavorsNo🎯 Flavor profile preferences: ["bitter", "sweet", "sour", "spicy", "herbal"]. Improves batch ranking.
preferred_strengthNo💪 Alcohol strength preference. Filters batch results by ABV ranges.
abv_minNo📊 Minimum ABV percentage. Lower bound for batch filtering.
abv_maxNo📊 Maximum ABV percentage. Upper bound for batch filtering.
glass_typeNo🥂 Required glassware (e.g., "coupe", "rocks", "martini"). Filters entire batch.
preparation_methodNo🔧 Required method (e.g., "shake", "stir", "build"). Filters batch by technique.
limitNo🎛️ Maximum results to return (default: 20, max: 50). Controls batch size for optimal performance.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cocktailsNoComplete cocktail recipes with full details
search_resultsNo
search_metadataNo
similar_cocktailsNoAdditional similar cocktails (when using similarity search)
performance_metricsNoBatch processing performance data
Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does an excellent job describing performance characteristics (parallel processing, 5-10x speed improvement, caching system, error resilience), operational limits (default: 20, max: 50), and response format details. However, it doesn't mention authentication requirements, rate limits, or potential costs, which would be helpful for a production tool.

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

Conciseness4/5

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

The description is well-structured with clear sections (Batch Processing System, Use Cases, Examples, Response Format, Performance Features) and uses emojis for visual organization. While comprehensive, it's somewhat lengthy; some details about caching TTL management and error isolation could be condensed. Every section adds value, but the front-loaded 'PREFERRED TOOL' designation could be more prominent.

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 the tool's complexity (13 parameters, batch processing capabilities) and the presence of an output schema (which handles return value documentation), the description provides excellent contextual completeness. It covers purpose, usage scenarios, behavioral characteristics, performance features, and response format details, making it fully adequate for an agent to understand when and how to use this tool effectively.

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 100%, so the schema already documents all 13 parameters thoroughly. The description adds some context about batch processing implications (e.g., 'Triggers similarity batch processing' for similar_to, 'Combines with other filters for batch processing' for ingredient) but doesn't provide significant additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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?

The description clearly states this is an 'Advanced cocktail search with intelligent batch processing and complete recipes,' specifying the verb (search), resource (cocktails), and key capabilities (batch processing, complete recipes). It distinguishes from sibling tools get_ingredient_info and get_recipe by emphasizing search functionality with batch processing rather than single-item retrieval.

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?

The description provides explicit usage guidance with a dedicated 'Use Cases' section listing six specific scenarios (general searches, similarity queries, ingredient-based, flavor profiles, complex filtering, batch comparisons). It also includes batch processing examples showing how to structure different types of queries, giving clear when-to-use examples.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhdenny/bar-assistant-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server