How do I use Barkeeper?

1. Click on "Install 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., "@Barkeeper What cocktails can I make with what's on my shelf?" 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.

Barkeeper

by NickM-27

Overview Schema Related Servers Score Discussions

Python

Hybrid

Barkeeper

An MCP server that tracks a home bar: what's on the shelf, and the cocktail recipes you want to keep.

It is deliberately small — 7 tools, roughly 900 tokens of tool schema and instructions combined — so it stays cheap to run against local models.

Design

Inventory is presence-only. An item is either on the shelf or it isn't — there are no quantities or units to keep up to date. Each item carries a category so the listing can be grouped.

Recipes are a name, ingredient lines, and a method. Ingredients are plain text ("2 oz bourbon"), so there is no per-ingredient schema for a model to get wrong.

The model does the cross-referencing. There is no what_can_i_make tool. To answer that, the model calls list_inventory and list_recipes and compares the two — it already knows that a recipe calling for bourbon is satisfied by a bottle named "Buffalo Trace". The server's instructions tell it to match generously.

Related MCP server: Mealie MCP Server

Tools

Tool	Arguments	Purpose
`list_inventory`	—	Everything on the shelf
`add_item`	`name`, `category`	Put one item on the shelf
`remove_item`	`name`	Take one item off
`list_recipes`	—	Every recipe with ingredients, without methods
`get_recipe`	`name`	One recipe in full
`save_recipe`	`name`, `ingredients`, `instructions?`	Save or replace a recipe
`delete_recipe`	`name`	Delete a recipe

list_recipes omits the method so the common "what can I make?" question stays cheap; get_recipe fills in the detail for the one drink you settle on.

Run it

The server speaks two transports. HTTP is the default in Docker: one port, plugged in by URL. stdio is the default for a local install, since that's how a client spawns it as a subprocess.

Docker (HTTP)

docker run -d --name barkeeper -p 8000:8000 -v barkeeper-data:/data \
  ghcr.io/nickmowen/mcp-barkeeper

Then point any MCP client at http://localhost:8000/mcp:

{
  "mcpServers": {
    "barkeeper": {
      "type": "http",
      "url": "http://localhost:8000/mcp"
    }
  }
}

Or with Claude Code:

claude mcp add --transport http barkeeper http://localhost:8000/mcp

Compose is included — docker compose up -d gives the same thing with the volume and port already wired.

The image runs as a non-root user (uid 1000), exposes 8000, and keeps its database in the /data volume. Prefer a named volume, as above: a bind mount to a host directory has to be writable by uid 1000 or the server can't create its database. A healthcheck confirms the port is bound.

Local (stdio)

uv sync

claude mcp add barkeeper -- uv --directory /path/to/mcp-barkeeper run barkeeper

Which HTTP transport?

--transport http serves Streamable HTTP at /mcp — the current MCP transport, which POSTs requests and streams replies back over SSE. This is what you want.

--transport sse serves the older HTTP+SSE transport, a separate /sse stream plus a /messages/ endpoint. It was deprecated in MCP 2025-03-26 and is here only for clients that haven't moved yet.

Configuration

Flags beat environment variables, which beat defaults.

Variable	Flag	Default	Purpose
`BARKEEPER_TRANSPORT`	`--transport`	`stdio` (`http` in Docker)	`stdio`, `http`, or `sse`
`BARKEEPER_HOST`	`--host`	`127.0.0.1` (`0.0.0.0` in Docker)	Interface to bind
`BARKEEPER_PORT`	`--port`	`8000`	Port to bind
`BARKEEPER_DB_PATH`	—	platform data dir	SQLite file; `:memory:` for throwaway
`BARKEEPER_ALLOWED_HOSTS`	—	unset	Comma-separated; enables DNS-rebinding protection
`BARKEEPER_ALLOWED_ORIGINS`	—	unset	Comma-separated; enables DNS-rebinding protection

Binding to 0.0.0.0 puts the server on every interface the container can reach, with no authentication — keep it on a private network or bound to 127.0.0.1. Setting either allow-list switches on DNS-rebinding protection, which rejects requests whose Host or Origin header isn't named:

BARKEEPER_ALLOWED_HOSTS="localhost:*,127.0.0.1:*"

Both are left unset by default because enabling protection with an empty allow-list rejects every request.

Storage

A single SQLite file. In Docker it lives at /data/barkeeper.db; locally it is created on first use at:

macOS: ~/Library/Application Support/barkeeper/barkeeper.db
Linux: ~/.local/share/barkeeper/barkeeper.db
Windows: %APPDATA%\barkeeper\barkeeper.db

Override with BARKEEPER_DB_PATH. Use :memory: for a throwaway session.

Development

uv run pytest

create_server(conn) accepts a connection, so tests run against an in-memory database with no global state.

Available Tools

7 tools

add_itemAdd itemA

Add one bottle, mixer, or garnish to the bar.

Call this when the user buys or acquires something, once per item. Adding something already on the shelf just updates its category.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The bottle or mixer, e.g. 'Buffalo Trace bourbon' or 'tonic water'. Include the type as well as the brand so recipes can be matched against it.
`category`	Yes	spirit = base liquor (gin, vodka, whiskey, rum, tequila, brandy); liqueur = sweetened or fortified (Campari, Cointreau, amaro, vermouth, sherry); wine = still or sparkling (prosecco, Champagne); bitters = cocktail bitters used in dashes (Angostura, Peychaud's); mixer = non-alcoholic liquid (tonic, soda, juice, cola); syrup = sweetener (simple, orgeat, grenadine, honey); garnish = citrus, herbs, olives, cherries; other = anything else.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

The description goes beyond the annotations by disclosing that 'Adding something already on the shelf just updates its category,' revealing an upsert/merge behavior rather than a simple create or error. This is valuable context that annotations do not provide. No contradiction with annotations.

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 three sentences long, front-loaded with the main purpose, and every sentence conveys essential information: what it does, when to call it, and its update behavior. There is no unnecessary verbosity.

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?

For a simple mutation tool with two fully documented parameters, an output schema, and annotations declaring it non-read-only and non-destructive, the description is sufficiently complete. It covers purpose, usage trigger, and the key behavioral nuance (updating existing items) without requiring additional 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 100%, with detailed descriptions for both name and category. The description's mention of 'bottle, mixer, or garnish' loosely maps to the category parameter but does not add meaningful semantics beyond the schema. Baseline 3 is appropriate.

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 opens with a specific action: 'Add one bottle, mixer, or garnish to the bar.' It further clarifies scope with 'once per item' and notes the update behavior for existing items, clearly distinguishing it from sibling remove_item and list_inventory.

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 explicitly states when to call: 'Call this when the user buys or acquires something, once per item.' This is a clear, actionable trigger. It does not explicitly name alternatives or exclusions, but the sibling tool names provide sufficient context for when not to use it.

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

delete_recipeDelete recipeB

Destructive

Delete a saved recipe.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The recipe to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

The description adds no behavioral context beyond what annotations already convey. While destructiveHint=true correctly signals the destructive nature, the description does not disclose anything further (e.g., irreversibility, cascading effects, or permission requirements).

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, clear, and front-loaded sentence. Every word contributes to the meaning, and there is no extraneous content.

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?

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description is sufficient for the agent to understand the basic operation. It could be enhanced with a note about expected outcomes (e.g., success/failure) but remains adequate for this scope.

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 coverage is 100% with a single 'name' parameter fully described as 'The recipe to delete.' The description contributes no additional parameter insight, but the schema already provides complete information, warranting the baseline score of 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?

The description 'Delete a saved recipe' clearly states the verb (delete) and resource (saved recipe), making the tool's purpose immediately obvious. However, it does not explicitly differentiate from sibling tools like remove_item, though the resource distinction is implicit in the name.

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?

There is no guidance on when to use this tool versus alternatives such as remove_item or list_recipes. The description merely states the action without providing any context about appropriate usage scenarios or exclusions.

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

get_recipeGet recipeA

Read-only

Get one recipe in full, with ingredients and the method.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Recipe name. Partial names work — 'old fash' finds 'Old Fashioned'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint=true and openWorldHint=false already present, the description adds context about the return scope ('in full, with ingredients and the method') and limits to a single recipe. It does not contradict annotations and provides useful behavioral context beyond the structured metadata.

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 sentence of 11 words that's front-loaded and free of redundancy. Every word adds meaning.

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 low complexity (one parameter, output schema available, read-only annotations), the description covers the essential behavior. It specifies the return content (ingredients and method) and the scope (one full recipe), so nothing critical is missing.

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 a 100% description coverage for the one parameter, with the schema noting partial name matching. The description itself doesn't explain parameters, but the schema already handles that burden, so this meets the baseline of 3.

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 uses a specific verb 'Get' and identifies the resource 'one recipe' with the qualifier 'in full, with ingredients and the method,' which clearly distinguishes this from sibling tools like list_recipes (listing) and save/delete (mutations). This is a clear, non-tautological statement of purpose.

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

Usage Guidelines3/5

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

The description implies usage when a user wants a single complete recipe, but it never explicitly contrasts this with list_recipes for browsing or notes that get_recipe is for full details. No exclusions or alternatives are mentioned, so guidance is implied rather than explicit.

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

list_inventoryList inventoryA

Read-only

List everything on the bar shelf, grouped by category.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

The description adds behavioral detail about output grouping ('grouped by category') and completeness ('everything') beyond what annotations provide. It does not contradict readOnlyHint or openWorldHint.

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, front-loaded sentence that clearly states the verb, resource, and grouping with no unnecessary words.

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?

For a zero-parameter, read-only list tool with an output schema present, this description fully conveys purpose and output structure. Annotations cover safety traits, and no additional context is needed.

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 tool has no parameters, so the schema fully covers inputs. The description correctly adds no parameter details, and a baseline of 4 is appropriate for a zero-parameter tool.

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 uses the specific verb 'List' and identifies the resource ('everything on the bar shelf') with a distinguishing output detail ('grouped by category'). This clearly differentiates it from sibling list_recipes.

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?

The phrase 'on the bar shelf' establishes appropriate context (inventory items versus recipes), making intended use clear. It does not explicitly mention alternatives or exclusions, but the context is unambiguous.

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

list_recipesList recipesA

Read-only

List every saved recipe with its ingredients, but without the method.

This is the cheap overview — use get_recipe for the full instructions of one drink.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true. Description adds that results include ingredients but exclude method, and that it is a 'cheap overview', providing useful behavioral context beyond annotations.

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?

Two concise sentences, front-loaded with the key information and a pointer to the alternative. No wasted words.

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?

With an output schema present, no parameters, and readOnly annotations, the description fully captures what the tool does and when to use it. The alternative get_recipe is explicitly mentioned.

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?

No parameters exist, so schema coverage is trivially 100%. Baseline 4 for zero-param tools; description doesn't need to explain parameters.

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?

Specific verb 'List' + resource 'saved recipe' + scope 'every' and detail 'with ingredients, but without the method'. Clearly distinguishes from get_recipe.

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 states this is the 'cheap overview' and directs users to 'use get_recipe for the full instructions' of a single drink, clearly differentiating from sibling tool.

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

remove_itemRemove itemA

Destructive

Remove an item from the bar, because it ran out or was thrown away.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The item to remove. Partial names work if they match only one item.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, so the removal nature is known. The description adds a real-world rationale but does not disclose additional behavioral details such as cascading effects on recipes or permanence. It provides some context beyond annotations, meeting the baseline.

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, concise sentence that states the action and context. It is front-loaded and contains no unnecessary words.

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?

The tool is simple with one parameter, an output schema, and annotations providing safety information. The description adequately explains the purpose and context, making it complete for the tool's complexity.

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 covers the single parameter 'name' with a description, achieving 100% schema description coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

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 the action ('Remove an item from the bar') and provides the reason ('because it ran out or was thrown away'). It distinguishes from sibling tools like add_item by specifying the removal context and target resource.

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?

The description gives clear context for when to use the tool ('ran out or was thrown away') but does not explicitly mention alternatives or when not to use it. The context is sufficient for a simple removal operation.

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

save_recipeSave recipeB

Save a cocktail recipe worth keeping, or update one already saved.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name of the drink. Saving an existing name replaces that recipe.
`ingredients`	Yes	One line per ingredient, amount included, e.g. ['2 oz bourbon', '2 dashes angostura bitters'].
`instructions`	No	How to make it — shake or stir, glassware, garnish.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior1/5

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

The description and schema indicate that saving an existing name replaces the recipe, which is destructive, yet annotations declare destructiveHint=false. This is a direct contradiction and the description fails to disclose the overwrite behavior beyond the annotation.

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?

One clear sentence with no redundancy, but could be more specific about behavior (though that's a transparency issue). It is front-loaded and concise.

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?

While the schema covers parameters, the tool description omits the destructive overwrite behavior and doesn't explain return values or side effects. The annotation contradiction also makes the context incomplete.

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 covers all parameters with detailed descriptions, including the behavior that saving an existing name replaces the recipe. The description adds no additional parameter meaning beyond what the schema provides, so baseline 3.

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 uses a specific verb ('save') and resource ('cocktail recipe'), and distinguishes between saving new and updating existing, which differentiates it from sibling tools like add_item or delete_recipe.

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 implies usage for saving or updating recipes, but does not explicitly state when not to use other tools or mention prerequisites. However, it clearly communicates its purpose in the recipe lifecycle.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: inventory items (add, remove, list) and recipes (list, get, save, delete). There is no overlap or confusion between tools.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case (remove_item, list_recipes, get_recipe, etc.). The verb clearly indicates the operation and the noun the target resource.

Tool Count5/5

Seven tools is well-scoped for a bar management server covering both inventory and recipe management. Each tool has a clear purpose and none are redundant.

Completeness5/5

The surface covers full CRUD for recipes (list, get, save, delete) and essential operations for inventory (add, remove, list). The add_item tool also handles updates via category refresh, so no major gaps exist.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

acme-todo
com.ritzademo
An MCP server for a simple todo list
Developer Tools App Automation
2
postman-mcp-server
com.postman
A basic MCP server to operate on the Postman API.
API Testing Developer Tools App Automation
3298
Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748

Related MCP Servers

InventarioDB
Databases Developer Tools
diegogfhjk
F
license
Not graded
quality
D
maintenance
A small MCP server that manages a product inventory using SQLite, providing CRUD operations through exposed MCP tools.
Updated a year ago (2025-06-08 17:38 UTC)
Mealie MCP Server
Health & Wellness
GraysonCAdams
A
license
Not graded
quality
D
maintenance
An MCP server for managing recipes, meal plans, shopping lists, and more through a self-hosted Mealie instance.
Updated 3 months ago (2026-06-17 08:52 UTC)
1
MIT
bar-assistant-mcp
Search Entertainment & Media
talvola
A
license
Not graded
quality
C
maintenance
MCP server for Bar Assistant that enables searching cocktails, managing ingredients, shelves, shopping lists, and collections via natural language.
Updated 22 days ago (2026-08-13 02:08 UTC)
MIT
mealplan-mcp
Health & Wellness
evcraddock
A
license
B
quality
D
maintenance
MCP server for meal planning and grocery list generation, enabling recipe storage, meal plan creation, and automated grocery lists with ignored ingredients.
Updated 7 months ago (2026-02-15 22:59 UTC)
8
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/NickM-27/mcp-barkeeper'

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

Category	What belongs there
`spirit`	Base liquor — gin, vodka, whiskey, rum, tequila, brandy
`liqueur`	Sweetened or fortified — Campari, Cointreau, amaro, vermouth, sherry
`wine`	Still or sparkling — prosecco, Champagne
`bitters`	Cocktail bitters, dashed rather than poured — Angostura, Peychaud's
`mixer`	Non-alcoholic liquids — tonic, soda, juice, cola
`syrup`	Sweeteners — simple, orgeat, grenadine, honey
`garnish`	Citrus, herbs, olives, cherries
`other`	Anything else

Barkeeper

Design

Tools

Categories

Run it

Docker (HTTP)

Local (stdio)

Which HTTP transport?

Configuration

Storage

Development

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API