Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Cocktail By Api Ninjas find cocktails with vodka and lime juice"
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.
用于访问 Cocktail By Api Ninjas API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-cocktail_by_api_ninjas）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: Bar Assistant MCP Server
这是一个 MCP 服务器，用于访问 Cocktail By Api Ninjas API。
PyPI 包名: bach-cocktail_by_api_ninjas
版本: 1.0.0
传输协议: stdio
pip install bach-cocktail_by_api_ninjaspip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-cocktail_by_api_ninjas bach_cocktail_by_api_ninjas
# 或指定版本
uvx --from bach-cocktail_by_api_ninjas@latest bach_cocktail_by_api_ninjaspython server.py# 安装
pip install bach-cocktail_by_api_ninjas
# 运行（命令名使用下划线）
bach_cocktail_by_api_ninjas此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-cocktail_by_api_ninjas": {
"command": "uvx",
"args": ["--from", "bach-cocktail_by_api_ninjas", "bach_cocktail_by_api_ninjas"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-cocktail_by_api_ninjas": {
"command": "uvx",
"args": ["--from", "bach-cocktail_by_api_ninjas", "bach_cocktail_by_api_ninjas"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
v1cocktailAPI Ninjas Cocktail API endpoint. Either name or ingredients parameter must be set.
端点: GET /v1/cocktail
参数:
name (string): name of cocktail. This parameter supports partial matches (e.g. bloody will match bloody mary and bloody margarita)
ingredients (string): comma-separated string of ingredients to search. Only cocktails containing all listed ingredients will be returned. For example, to search cocktails containing Vodka and lemon juice, use vodka,lemon juice.
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
API Ninjas Cocktail API endpoint. Either name or ingredients parameter must be set.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | name of cocktail. This parameter supports partial matches (e.g. bloody will match bloody mary and bloody margarita) | |
| ingredients | No | comma-separated string of ingredients to search. Only cocktails containing all listed ingredients will be returned. For example, to search cocktails containing Vodka and lemon juice, use vodka,lemon juice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the API endpoint but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or response format. The description adds minimal context beyond the parameters, leaving significant gaps in understanding how the tool behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address the tool's usage and parameter requirements. It's front-loaded with the API endpoint context and avoids unnecessary details. However, it could be slightly more structured by explicitly stating the action (e.g., 'search cocktails').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 2 parameters, the description is incomplete. It covers parameter constraints but lacks information on behavioral aspects, response format, and error handling. For a tool interacting with an external API, this leaves the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 thoroughly. The description adds value by clarifying that at least one parameter must be set, which isn't in the schema (since required is empty), but it doesn't provide additional meaning beyond what the schema offers. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool accesses an API endpoint for cocktails, which gives a general purpose, but it's vague about the specific action (e.g., search, retrieve, list). It mentions parameters but doesn't clearly distinguish the verb+resource combination, such as 'search cocktails by name or ingredients.' With no siblings, differentiation isn't needed, but the purpose lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by stating that either 'name' or 'ingredients' must be set, which offers some context for when to use the tool. However, it lacks explicit guidance on when to choose one parameter over the other, alternatives, or exclusions. With no sibling tools, this is adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as accessing the Cocktail API with specific parameter requirements.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against for patterns or conventions.
One tool is too few for a server named 'Cocktail By Api Ninjas', which suggests a domain with multiple potential operations (e.g., search by name, ingredient, category, random cocktail). This minimal surface will likely cause agent failures due to limited functionality.
The server is severely incomplete for its apparent cocktail domain. It only offers a single generic endpoint without clear CRUD or lifecycle coverage (e.g., no distinct tools for searching, filtering, or retrieving detailed cocktail information), leaving significant gaps in functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search 500 cocktail recipes, get full recipes, find drinks by ingredient, suggest random picks.
Cocktails MCP — TheCocktailDB API (free, no auth)
Recipes MCP — wraps TheMealDB API (free tier, no auth)
API Ninjas MCP — wraps the multi-endpoint API Ninjas data API (api-ninjas.com)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/cocktail_by_api_ninjas'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
