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 : "
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.
An MCP server that uses TheCocktailDB API. By connecting it to Claude Desktop, you can search for cocktail recipes and retrieve ingredient information using natural language.
npm install
npm run buildRelated MCP server: Bar Assistant MCP Server
Add the following to claude_desktop_config.json:
{
"mcpServers": {
"cocktail": {
"command": "node",
"args": ["/path/to/cocktail-mcp-server/dist/index.js"]
}
}
}Tool Name | Description | Arguments | |
| Search for recipes by cocktail name |
| |
| Reverse lookup cocktails by ingredient |
| |
| Recommend a random cocktail | None | |
| Get detailed information about an ingredient |
| |
| Filter by category or alcohol content | `filter_type: "category" | "alcoholic" |
ユーザー: モヒートの作り方教えて
Claude: モヒートのレシピですね！
【材料】ライトラム 2-3 oz、ライムジュース 1 oz、砂糖 2 tsp、ミント...
ユーザー: ウォッカで作れるカクテル何がある？
Claude: ウォッカを使ったカクテルはこちらです！
1. Moscow Mule 2. Vodka Martini 3. Cosmopolitan...
ユーザー: 今日のおすすめカクテル出して
Claude: こんなのはいかがですか？ Old Fashioned...npm test # テスト実行
npm run test:watch # ウォッチモードTypeScript / Node.js
@modelcontextprotocol/sdk (MCP SDK)
Zod (Validation)
Vitest (Testing)
TheCocktailDB API (Test API key "1")
Filter cocktails by category (e.g., 'Ordinary Drink', 'Cocktail') or by alcoholic/non-alcoholic.
| Name | Required | Description | Default |
|---|---|---|---|
| filter_type | Yes | Filter type: 'category' or 'alcoholic' | |
| value | Yes | Filter value (e.g., 'Cocktail', 'Alcoholic', 'Non_Alcoholic') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that filtering is by category or alcoholic type, but doesn't mention behavior on invalid values, empty results, or rate limits. Adequate but not rich.
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?
One sentence, no wasted words. Front-loaded with verb 'filter' and resource 'cocktails'. Clear and efficient.
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?
Simple tool with only 2 params and no output schema. Description is complete enough for this simplicity, but lacks details on return format or edge cases. Adequate for a straightforward filter.
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 has 100% coverage with descriptions for both parameters. The description adds context with examples like 'Ordinary Drink' and 'Alcoholic', which aligns with schema enums, but doesn't add new meaning beyond schema.
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?
Description clearly states the tool filters cocktails by category or alcoholic status, with specific examples. It distinguishes from sibling tools that search or get random info.
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?
No explicit when-to-use or alternatives guidance. However, the description implies using it for category or alcoholic filtering, which is clear but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a cocktail ingredient, including description, type, and whether it contains alcohol.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient | Yes | Ingredient name to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It discloses what information is returned (description, type, alcohol content) but does not mention side effects, prerequisites, or any state changes. As a read-only lookup, it's adequate.
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?
Single sentence, no wasted words. Front-loaded with main action 'Get detailed information'.
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 simple input schema, no output schema, and no annotations, the description is complete enough for a basic lookup. Could mention the return format or that it may return null if not found, but not essential.
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 coverage is 100% with a single parameter 'ingredient' described as 'Ingredient name to look up'. Description does not add much beyond schema, but parameter is straightforward. Baseline 3.
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?
Description clearly states the tool retrieves detailed information about a cocktail ingredient, specifying attributes: description, type, and alcohol content. It distinguishes from siblings like 'search_by_ingredient' which likely searches for cocktails by ingredient, not info about the ingredient itself.
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?
No explicit when-to-use or when-not-to-use guidance. The purpose is clear but does not mention alternatives or exclusions. Implicitly, this tool is for ingredient details rather than cocktail lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a random cocktail suggestion with full recipe details. Great for discovering new drinks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states it returns full recipe details, but does not disclose other traits like whether it calls external APIs, or any limitations on randomness.
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 (two sentences) and front-loaded with the main purpose. No unnecessary words, but could be slightly more structured.
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?
For a tool with no parameters, no output schema, and no annotations, the description is adequate but could mention return format or usage tips. It is complete enough for basic use.
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?
The input schema has 0 parameters, so the description need not add parameter meaning. It already provides context on what the tool does, which is sufficient.
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 clearly states the tool returns a random cocktail suggestion with full recipe details, which is specific and distinct from sibling tools like filter_cocktails or search_by_ingredient.
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 says 'Great for discovering new drinks,' implying a usage context, but does not explicitly state when to use this vs alternatives or 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.
Find cocktails that can be made with a specific ingredient. Returns a list of cocktail names and thumbnails.
| Name | Required | Description | Default |
|---|---|---|---|
| ingredient | Yes | Ingredient name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the tool returns cocktail names and thumbnails but does not mention whether it supports partial matches, case sensitivity, or any rate limits. The lack of behavioral context leaves the agent guessing.
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 very concise with two sentences. It is front-loaded with the purpose. No wasted words, but could benefit from a bit more detail without becoming verbose.
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 simple schema (single parameter) and no output schema, the description is minimal. It does not explain the return format beyond 'names and thumbnails' or mention pagination or limits. For a search tool, this is insufficient for an agent to invoke it correctly in all contexts.
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 baseline is 3. The description adds no additional meaning beyond the schema; it only restates that the parameter is an ingredient name. No constraints or examples are given.
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 clearly states the tool finds cocktails by ingredient and returns names and thumbnails. It distinguishes itself from siblings like 'filter_cocktails' and 'search_cocktail' by focusing on a single ingredient, but could be more specific about the exact scope.
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?
No guidance on when to use this tool versus siblings like 'filter_cocktails' (which may allow multiple filters) or 'search_cocktail' (which may search by name). No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for cocktail recipes by name. Returns ingredients, measurements, instructions, and image URL.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Cocktail name to search for |
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 correctly identifies it as a search/read operation and lists return fields, but does not disclose pagination, limits, or error behavior.
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 a single concise sentence with no fluff. It front-loads the action and specifies output fields efficiently.
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?
For a simple search tool with one parameter and no output schema, the description adequately covers purpose and basic behavior. However, it lacks details on response structure (e.g., whether results are paginated or limited) and error handling.
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?
The schema has 100% description coverage for the single parameter 'name', which is well-described. The description adds no further parameter details, so baseline 3 is appropriate.
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 clearly states it searches for cocktail recipes by name, specifying the returned fields (ingredients, measurements, instructions, image URL). This distinguishes it from siblings like search_by_ingredient and filter_cocktails.
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 implies using this tool when you have a cocktail name, but does not explicitly state when not to use it or mention alternatives. Sibling tools exist for other search methods, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: searching by name, filtering by category, searching by ingredient, getting ingredient info, and random discovery. No overlaps in purpose.
All tools follow a consistent verb_noun pattern (e.g., filter_cocktails, search_by_ingredient, get_random_cocktail), making it easy to predict functionality.
Five tools is an ideal scope for a cocktail recipe server, covering search, filter, ingredient lookup, and random discovery without unnecessary bloat.
The set covers search, filtering, ingredient details, and random discovery. Missing features like rating or user-added recipes are not essential for a reference server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Search, save, organize, cook, and share recipes with any AI assistant.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yusuke-Shibata23/cocktail-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
