What can you do with this server?

The Bar Assistant MCP Server allows you to manage your home bar inventory and discover cocktails through integration with the Bar Assistant platform. Inventory Management: View all ingredients on your bar shelf with detailed information, add or remove ingredients by their IDs, and access shelf contents as resources. Cocktail Discovery & Creation: See which cocktails you can make with your current ingredients, create new cocktail recipes with ingredients, instructions, garnishes, and metadata, and update existing recipes. Ingredient Management: Search for ingredients by name to find their IDs, and create custom ingredients with details like strength, origin, color, and description. Bar Management: Discover and switch between multiple bars you have access to, with context-aware operations supporting a default bar ID or specific bar selection. Navigation: Browse through large lists of ingredients and cocktails with pagination support.

How do I use Bar Assistant MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bar Assistant MCP Server what cocktails can I make with my current ingredients?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Bar Assistant MCP Server

by the-real-py

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Bar Assistant MCP Server

An MCP (Model Context Protocol) server for Bar Assistant - manage your home bar shelf and discover cocktails you can make.

Features

📋 View ingredients on your bar shelf
🍸 See cocktails you can make with what you have
➕ Add ingredients to your shelf
➖ Remove ingredients from your shelf
🔍 Search for ingredients by name
🏪 Discover your available bars
🧪 Create new ingredients
🍹 Create new cocktail recipes
✏️ Update existing cocktail recipes

Related MCP server: Cocktail

Installation

Using uvx (Recommended)

Run directly with uvx:

uvx --from git+https://github.com/the-real-py/bar-assistant-mcp bar-assistant-mcp \
  https://bar.johnprovost.com/bar/api \
  your_token_here \
  1

Or set environment variables in .env and run:

uvx --from git+https://github.com/the-real-py/bar-assistant-mcp bar-assistant-mcp

Using pip

pip install git+https://github.com/the-real-py/bar-assistant-mcp
bar-assistant-mcp

Configuration

Create a .env file in your project directory:

BAR_ASSISTANT_API_URL=https://bar.johnprovost.com/bar/api
BAR_ASSISTANT_TOKEN=your_bearer_token_here
BAR_ASSISTANT_BAR_ID=1

Or pass them as command-line arguments:

bar-assistant-mcp <api_url> <token> <bar_id>

Getting Your Credentials

API URL: Your Bar Assistant instance URL + the API path
- Standard setup: http://localhost:8000/api
- Custom setup: Check your reverse proxy configuration (e.g., https://bar.example.com/bar/api)
Token: Generate a personal access token from your Bar Assistant profile settings
Bar ID: Use the list_bars tool to find your bar ID, or it's usually 1 for your first bar

Important: The BAR_ASSISTANT_BAR_ID is optional. If you don't set it, you can provide the bar_id parameter when calling tools, or use the list_bars tool first to discover your available bars.

Usage with Claude Desktop

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "bar-assistant": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/the-real-py/bar-assistant-mcp",
        "bar-assistant-mcp",
        "https://bar.johnprovost.com/bar/api",
        "your_token_here",
        "1"
      ]
    }
  }
}

Or using environment variables:

{
  "mcpServers": {
    "bar-assistant": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/the-real-py/bar-assistant-mcp",
        "bar-assistant-mcp"
      ],
      "env": {
        "BAR_ASSISTANT_API_URL": "https://bar.johnprovost.com/bar/api",
        "BAR_ASSISTANT_TOKEN": "your_token_here",
        "BAR_ASSISTANT_BAR_ID": "1"
      }
    }
  }
}

Available Tools

`list_bars`

Discover all bars you have access to and get their IDs.

`get_shelf_ingredients`

List all ingredients on your bar shelf.

Parameters:

bar_id (optional): Bar ID to query
page (optional): Page number for pagination

`get_shelf_cocktails`

See all cocktails you can make with your current ingredients.

Parameters:

bar_id (optional): Bar ID to query
page (optional): Page number for pagination

`add_ingredients_to_shelf`

Add ingredients to your shelf by their IDs.

Parameters:

ingredient_ids (required): Array of ingredient IDs
bar_id (optional): Bar ID to update

`remove_ingredients_from_shelf`

Remove ingredients from your shelf.

Parameters:

ingredient_ids (required): Array of ingredient IDs
bar_id (optional): Bar ID to update

`search_ingredients`

Search for ingredients by name to find their IDs.

Parameters:

name (required): Ingredient name to search for
bar_id (optional): Bar ID context

`create_ingredient`

Create a new ingredient in the bar database. Use this when an ingredient doesn't exist and needs to be created before adding to a cocktail.

Parameters:

name (required): Name of the ingredient
strength (optional): Alcohol strength/percentage (e.g., 40 for 40% ABV)
description (optional): Description of the ingredient
origin (optional): Origin/country of the ingredient
color (optional): Hex color code (e.g., '#ffffff')
parent_ingredient_id (optional): Parent ingredient ID for categorization
units (optional): Default units for this ingredient (e.g., 'ml', 'oz', 'dash')
bar_id (optional): Bar ID context

`create_cocktail`

Create a new cocktail recipe. First use search_ingredients to find ingredient IDs, then use create_ingredient for any missing ingredients.

Parameters:

name (required): Name of the cocktail
instructions (required): Step-by-step instructions for making the cocktail
ingredients (required): Array of ingredients with:
- ingredient_id (required): ID of the ingredient
- amount (required): Amount of the ingredient
- units (optional): Units for the amount (e.g., 'ml', 'oz', 'dash')
- optional (optional): Whether this ingredient is optional
- note (optional): Additional note for this ingredient
- sort (optional): Sort order for the ingredient
description (optional): Description of the cocktail
garnish (optional): Garnish for the cocktail
source (optional): Source/origin of the recipe
glass_id (optional): ID of the glass type to use
method_id (optional): ID of the mixing method (shaken, stirred, etc.)
tags (optional): Array of tags for the cocktail
bar_id (optional): Bar ID context

Example - Creating a Margarita:

1. search_ingredients(name="tequila") → ID: 45
2. search_ingredients(name="lime juice") → ID: 89  
3. search_ingredients(name="triple sec") → ID: 23
4. create_cocktail(
     name="Margarita",
     instructions="1. Add all ingredients to shaker with ice\n2. Shake well\n3. Strain into salt-rimmed glass",
     ingredients=[
       {"ingredient_id": 45, "amount": 60, "units": "ml"},
       {"ingredient_id": 89, "amount": 30, "units": "ml"},
       {"ingredient_id": 23, "amount": 30, "units": "ml"}
     ],
     garnish="Lime wheel, salt rim"
   )

`update_cocktail`

Update an existing cocktail recipe. Use this to modify the name, instructions, ingredients, or other details of a cocktail.

Parameters:

id (required): ID of the cocktail to update
name (required): Name of the cocktail
instructions (required): Step-by-step instructions for making the cocktail
ingredients (required): Array of ingredients with:
- ingredient_id (required): ID of the ingredient
- amount (required): Amount of the ingredient
- units (optional): Units for the amount (e.g., 'ml', 'oz', 'dash')
- optional (optional): Whether this ingredient is optional
- note (optional): Additional note for this ingredient
- sort (optional): Sort order for the ingredient
description (optional): Description of the cocktail
garnish (optional): Garnish for the cocktail
source (optional): Source/origin of the recipe
glass_id (optional): ID of the glass type to use
method_id (optional): ID of the mixing method (shaken, stirred, etc.)
tags (optional): Array of tags for the cocktail
bar_id (optional): Bar ID context

Resources

bar://shelf/ingredients - Your bar shelf ingredients
bar://shelf/cocktails - Cocktails you can make

Development

Clone and install in development mode:

git clone https://github.com/the-real-py/bar-assistant-mcp
cd bar-assistant-mcp
pip install -e .

Troubleshooting

Finding Your API URL

The Bar Assistant API URL depends on your setup:

Standard Docker setup: http://localhost:8000/api
Custom reverse proxy: Check your nginx/Traefik configuration for the API route
Cloud hosted: Usually provided by your hosting service

To verify your API URL is correct, run:

curl -H "Accept: application/json" YOUR_API_URL/server/version

You should get a JSON response with version information.

License

MIT

Available Tools

6 tools

add_ingredients_to_shelfC

Add ingredients to your bar shelf by their IDs

ParametersJSON Schema

Name	Required	Description	Default
`ingredient_ids`	Yes	Array of ingredient IDs to add to shelf
`bar_id`	No	Bar ID (optional if BAR_ASSISTANT_BAR_ID is set)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool adds ingredients but doesn't cover critical aspects like whether this is a mutating operation, permission requirements, error handling for invalid IDs, or if duplicates are allowed. This leaves significant gaps in understanding the tool's behavior.

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 description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse while conveying the core action and mechanism.

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

Completeness2/5

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

Given the tool's complexity as a mutating operation with no annotations and no output schema, the description is incomplete. It fails to address behavioral traits like side effects, response format, or error conditions, which are crucial for an agent to use this tool effectively in context with its siblings.

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 input schema fully documents both parameters. The description adds minimal value by mentioning 'by their IDs', which aligns with the schema's 'ingredient_ids' parameter, but doesn't provide additional context like format examples or usage tips beyond what's already in the structured data.

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 description clearly states the action ('Add ingredients') and the target resource ('to your bar shelf'), with specificity about the mechanism ('by their IDs'). However, it doesn't explicitly distinguish this tool from its sibling 'remove_ingredients_from_shelf' beyond the opposite action, missing an opportunity for clearer differentiation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'search_ingredients' for discovery or 'get_shelf_ingredients' for viewing. The description lacks context about prerequisites, such as needing valid ingredient IDs or bar access, leaving usage scenarios implied but not stated.

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

get_shelf_cocktailsB

Get all cocktails you can make with ingredients on your bar shelf

ParametersJSON Schema

Name	Required	Description	Default
`bar_id`	No	Bar ID (optional if BAR_ASSISTANT_BAR_ID is set)
`page`	No	Page number for pagination (optional)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves cocktails based on shelf ingredients but lacks details on permissions, rate limits, pagination behavior (implied by the 'page' parameter but not explained), or response format. For a read operation with zero annotation coverage, this is a significant gap in transparency.

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 description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly. Every part of the sentence earns its place by conveying essential information.

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?

Given the tool's moderate complexity (a read operation with 2 optional parameters) and no annotations or output schema, the description is minimally adequate. It explains what the tool does but lacks behavioral details (e.g., pagination, response structure) and usage context. It meets the bare minimum for a simple tool but doesn't fully compensate for the absence of structured data.

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?

The input schema has 100% description coverage, with clear documentation for both parameters ('bar_id' and 'page'). The description doesn't add any meaning beyond the schema, such as explaining how 'bar_id' relates to 'BAR_ASSISTANT_BAR_ID' or detailing pagination logic. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles parameter semantics adequately.

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 description clearly states the tool's purpose: 'Get all cocktails you can make with ingredients on your bar shelf.' It specifies the verb ('Get'), resource ('cocktails'), and scope ('with ingredients on your bar shelf'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_shelf_ingredients' or 'search_ingredients,' which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_shelf_ingredients' (which lists ingredients) or 'search_ingredients' (which might find cocktails by ingredient), leaving the agent to infer usage context. There's no explicit when/when-not or alternative recommendations.

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

get_shelf_ingredientsB

Get all ingredients currently on your bar shelf with detailed information

ParametersJSON Schema

Name	Required	Description	Default
`bar_id`	No	Bar ID (optional if BAR_ASSISTANT_BAR_ID is set)
`page`	No	Page number for pagination (optional)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying it's a read operation, but doesn't mention pagination behavior, rate limits, authentication needs, or error handling. This leaves significant gaps for a tool with parameters.

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 description is a single, efficient sentence with no wasted words, clearly front-loading the purpose. Every part earns its place by specifying action, resource, scope, and detail level.

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?

Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks behavioral details and usage guidance, making it incomplete for optimal agent use without additional context.

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 both parameters. The description adds no additional meaning beyond implying retrieval of 'all' ingredients, which doesn't clarify parameter usage like pagination or bar_id context. Baseline 3 is appropriate as the schema handles parameter documentation.

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 description clearly states the action ('Get') and resource ('ingredients currently on your bar shelf'), specifying scope ('all') and detail level ('detailed information'). It doesn't explicitly differentiate from sibling tools like 'search_ingredients' or 'get_shelf_cocktails', which would require a 5.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'search_ingredients' or 'get_shelf_cocktails', nor are prerequisites or exclusions mentioned. The description implies usage for retrieving shelf ingredients but lacks explicit context.

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

list_barsB

List all bars you have access to and get their IDs

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states the tool lists bars and retrieves IDs, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns paginated results, or includes metadata like bar names or statuses. This leaves gaps in understanding the tool's operational traits.

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 a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. However, it could be slightly more structured by explicitly stating it's a read operation or adding brief context, but it's still highly concise.

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?

Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. For a simple list tool, this might suffice, but without annotations or output schema, more guidance on what 'IDs' entail or how results are structured would improve completeness.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate here since none are required. This aligns with the schema, so it earns a baseline score of 4 for not introducing confusion or omissions.

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 description clearly states the action ('List all bars') and the resource ('bars'), specifying that it retrieves bars the user has access to along with their IDs. However, it doesn't differentiate this tool from potential siblings like 'search_ingredients' or 'get_shelf_ingredients', which might also list resources but with different scopes or filters.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, such as authentication or context needed, nor does it specify if this is for initial setup, inventory checks, or other scenarios. Without such context, the agent might misuse it or overlook better-suited tools.

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

remove_ingredients_from_shelfC

Remove ingredients from your bar shelf by their IDs

ParametersJSON Schema

Name	Required	Description	Default
`ingredient_ids`	Yes	Array of ingredient IDs to remove from shelf
`bar_id`	No	Bar ID (optional if BAR_ASSISTANT_BAR_ID is set)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action is 'Remove,' implying a destructive mutation, but does not specify permissions required, whether removal is permanent or reversible, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage.

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 description is a single, efficient sentence with zero waste. It is front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy or unnecessary elaboration.

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

Completeness2/5

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

Given the tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error conditions, and usage context. For a tool that modifies data, this minimal description does not provide enough information for safe and effective use.

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 both parameters ('ingredient_ids' and 'bar_id') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 description clearly states the action ('Remove') and resource ('ingredients from your bar shelf'), specifying removal by IDs. It distinguishes from siblings like 'add_ingredients_to_shelf' by indicating removal rather than addition, though it doesn't explicitly contrast with other tools. The purpose is specific and actionable.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or contextual cues (e.g., use after 'get_shelf_ingredients' to identify IDs). It lacks explicit when/when-not instructions or named alternatives, leaving usage unclear beyond the basic action.

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

search_ingredientsC

Search for ingredients by name to find their IDs

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Ingredient name to search for
`bar_id`	No	Bar ID (optional if BAR_ASSISTANT_BAR_ID is set)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches for ingredients by name to find IDs, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or response format. This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.

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 description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list of IDs, structured data), potential limitations (e.g., partial matches, case sensitivity), or how the optional 'bar_id' parameter affects results. This leaves the agent with insufficient context for effective use.

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?

The schema description coverage is 100%, with clear descriptions for both parameters ('name' and 'bar_id'). The description adds minimal value beyond the schema, as it only mentions searching by name without elaborating on parameter interactions or usage nuances. This meets the baseline for high schema coverage.

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 description clearly states the tool's purpose with a specific verb ('search') and resource ('ingredients'), explaining it finds ingredient IDs by name. However, it doesn't explicitly differentiate from sibling tools like 'get_shelf_ingredients' or 'list_bars', which might also involve ingredient-related operations.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_shelf_ingredients' for retrieving ingredients from a shelf or 'list_bars' for bar-related data, leaving the agent to infer usage context without explicit direction.

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.

6 tool updatesv1.0.0Dec 28, 2025
- First observedadd_ingredients_to_shelf
- First observedget_shelf_cocktails
- First observedget_shelf_ingredients
- First observedlist_bars
- First observedremove_ingredients_from_shelf
- First observedsearch_ingredients

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-04-18 07:40 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: managing shelf ingredients (add/remove/get), searching for ingredients, listing bars, and getting cocktails from the shelf. The actions and targets are well-defined, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., add_ingredients_to_shelf, get_shelf_cocktails). The naming is predictable and readable throughout the set, with no deviations in style.

Tool Count5/5

With 6 tools, this server is well-scoped for a bar assistant domain. Each tool earns its place by covering core operations like ingredient management, cocktail discovery, and bar listing, without being too sparse or bloated.

Completeness4/5

The tool set covers key workflows: CRUD for shelf ingredients (add, remove, get), ingredient search, bar listing, and cocktail generation. A minor gap is the lack of tools for directly managing cocktails or bars (e.g., create/delete bars), but agents can work around this with the provided operations.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

prep-itOAuth
com.recipe-clipper
Search, save, organize, cook, and share recipes with any AI assistant.
Note Taking Search
2
Pantry PersonaOAuth
com.pantrypersona
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Home Automation & IoT Health & Wellness E-commerce & Retail
2
Cocktail Glass A
glass.cocktail
Search 500 cocktail recipes, get full recipes, find drinks by ingredient, suggest random picks.
Search
72
Scraps KitchenOAuth
io.github.mitchmolstad
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Home Automation & IoT Health & Wellness App Automation
2

Related MCP Servers

Bar Assistant MCP Server
Search
zhdenny
A
license
A
quality
D
maintenance
Enables intelligent cocktail discovery and recipe retrieval from Bar Assistant instances with natural language search, similarity matching, batch processing, and ingredient analysis capabilities.
Updated 3 months ago (2026-06-20 15:59 UTC)
3
2
MIT
Cocktail
Search Open Data
Yusuke-Shibata23
F
license
A
quality
D
maintenance
Enables natural language search for cocktail recipes and ingredient information through TheCocktailDB API. Supports searching by cocktail name, ingredient, category, or alcohol content to discover recipes and recommendations.
Updated 5 months ago (2026-04-08 09:00 UTC)
5
-
Cocktails MCP
Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching for cocktail recipes by name, ingredient, or randomly, and retrieving full cocktail details including ingredients, measurements, and instructions via TheCocktailDB API.
Updated 3 days ago (2026-09-17 23:57 UTC)
2 npm
MIT
bar-assistant-mcp
Search Entertainment & Media
talvola
A
license
B
quality
D
maintenance
MCP server for Bar Assistant that enables searching cocktails, managing ingredients, shelves, shopping lists, and collections via natural language.
Updated a month ago (2026-08-13 02:08 UTC)
41
MIT

Bar Assistant MCP Server

Features

Installation

Using uvx (Recommended)

Using pip

Configuration

Getting Your Credentials

Usage with Claude Desktop

Available Tools

list_bars

get_shelf_ingredients

get_shelf_cocktails

add_ingredients_to_shelf

remove_ingredients_from_shelf

search_ingredients

create_ingredient

create_cocktail

update_cocktail

Resources

Development

Troubleshooting

Finding Your API URL

License

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`list_bars`

`get_shelf_ingredients`

`get_shelf_cocktails`

`add_ingredients_to_shelf`

`remove_ingredients_from_shelf`

`search_ingredients`

`create_ingredient`

`create_cocktail`

`update_cocktail`