Cocktails you can make from bottles you already have, full recipes, and the best next bottle to add.
Scored across 4 tools
Each tool targets a distinct input intent: find_cocktails_from_bottles takes an ingredient list, get_cocktail_recipe takes a cocktail name, get_drink_of_the_day is a daily/random pick, and suggest_next_ingredient recommends one bottle to add. The overlap between find_cocktails_from_bottles and suggest_next_ingredient is minor and well-differentiated by output (cocktails vs. a single ingredient).
All four tools use a consistent snake_case verb_noun pattern (find_, get_, get_, suggest_) with clear, descriptive object phrases. No mixed conventions or vague verbs.
Four tools is on the lean side but each serves a clear, non-redundant purpose for a cocktail discovery app. No filler or overlapping tools, though a browse/search tool could reasonably be added.
The surface covers discovery (find from bottles), recipe retrieval by name, a daily pick, and an ingredient-gap suggestion, forming a coherent lifecycle. Minor gaps exist around browsing the catalog or searching by partial/ambiguous names, but core user workflows are covered.
Use this when the user lists bottles or ingredients they have and wants catalog cocktails they can make now, or that are one or two ingredients away. Returns only MixWise catalog recipes. Set zero_proof_only when the user wants drinks without alcohol.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| ingredients | Yes | Generic ingredient names the user has, for example gin, Campari, sweet vermouth. | |
| max_missing | No | How many missing ingredients still count as almost there. 0 returns ready drinks only. | |
| zero_proof_only | No | When true, return only zero-proof catalog drinks. |
| Name | Required | Description |
|---|---|---|
| links | Yes | |
| ready | Yes | |
| counts | Yes | |
| recognized | Yes | |
| almost_there | Yes | |
| unrecognized | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds real behavior beyond that: results are restricted to catalog recipes and the result set spans ready drinks plus one/two-ingredients-away matches, which tells the agent what kind of output to expect. It stops short of noting limits or ordering/pagination, but the output schema covers returns.
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?
Three short sentences, front-loaded with the usage trigger, followed by scope and the one parameter worth calling out. No filler or restated name/title content.
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?
With an output schema present, return-value detail is not required, and the description covers the activation trigger, result scope, and the zero-proof mode. The one gap is that it doesn't clarify the relationship to suggest_next_ingredient for users who are close but not one-or-two away.
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 75% and the schema already documents zero_proof_only and max_missing. The description only echoes those meanings ('one or two ingredients away', zero-proof case) without adding syntax, defaults, or edge-case guidance beyond the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: find catalog cocktails from a list of bottles/ingredients the user has. It also bounds the scope to 'MixWise catalog recipes' and the one-or-two-ingredients-away case, which cleanly separates it from get_cocktail_recipe (single recipe lookup) and suggest_next_ingredient (gap filling).
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?
Gives an explicit trigger ('when the user lists bottles or ingredients they have and wants cocktails they can make now'). It also narrows scope to catalog recipes and flags the zero_proof_only scenario, but it never names the sibling tools or states when NOT to use this one versus suggest_next_ingredient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks how to make a specific cocktail by name, or picks one from MixWise results. Returns the full catalog recipe, including measures and steps.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_name | Yes | Cocktail slug or name, for example margarita. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| slug | No | |
| found | Yes | |
| links | Yes | |
| garnish | No | |
| glassware | No | |
| image_url | No | |
| technique | No | |
| difficulty | No | |
| ingredients | No | |
| suggestions | No | |
| is_zero_proof | No | |
| responsible_note | No | |
| short_description | No | |
| instructions_steps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safe-read profile is covered. The description adds that it returns the 'full catalog recipe, including measures and steps,' but with an output schema present this is largely duplicative. No rate limits, auth, or not-found behavior are disclosed.
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?
Two tightly written sentences; the usage trigger is front-loaded and the return content follows with zero filler.
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?
With a single required param, an output schema, and annotations covering the safety profile, the description supplies the key trigger context. It could be more complete by clarifying name-vs-slug resolution or fallback behavior when no match is found.
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% and the single 'slug_or_name' parameter is fully documented in the schema, including an example. The description adds no syntax, slug-format, or matching guidance beyond that, so the baseline of 3 applies.
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 a specific verb+resource: retrieve the full recipe for one cocktail by name. It implicitly separates itself from sibling discovery tools (find_cocktails_from_bottles, suggest_next_ingredient) by scoping to a single known cocktail, but never names those alternatives explicitly.
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?
"Use this when the user asks how to make a specific cocktail by name, or picks one from MixWise results" gives a clear triggering condition. No explicit when-not or named alternative is provided, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for the drink of the day, what to drink tonight, or a surprise cocktail. Returns the same MixWise drink the website shows for the current Pacific calendar day, with a one-line description.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| why | No | |
| name | No | |
| slug | No | |
| found | Yes | |
| links | Yes | |
| display | Yes | |
| missing | No | |
| can_make | No | |
| date_key | Yes | |
| image_url | No | |
| ingredients | No | |
| short_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context the annotations cannot: the result is deterministic and matches the website for the current Pacific calendar day, and the payload includes a one-line description. Missing only trivial details like pagination/caching, which are irrelevant here.
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?
Two sentences, no waste, and the trigger conditions are front-loaded before the behavior. Every clause earns its place — the triggers route the agent, the second sentence sets expectations about determinism and output shape.
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?
An output schema exists, so the description need not enumerate return fields, yet it usefully notes the one-line description accompanying the drink. With no parameters, full annotation coverage, and a simple deterministic contract, nothing an agent needs to call this correctly is missing.
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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related the description could usefully add, and it correctly implies no input is required by framing the tool purely as a lookup.
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?
States a specific verb and resource (returns the day's MixWise drink) and pins down scope: the same drink the website shows for the current Pacific calendar day. That single-item, deterministic daily pick is clearly distinct from searching by bottles, fetching a recipe, or suggesting an 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?
Gives explicit user-phrasing triggers ("drink of the day", "what to drink tonight", "surprise cocktail"), which is strong when-to-use guidance. It stops short of naming alternatives or exclusion conditions (e.g. use get_cocktail_recipe when the user wants a specific drink), so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which single ingredient or bottle to add to unlock the most new cocktails from what they already have. Returns the one catalog bottle that unlocks the most drinks. Set zero_proof_only when the user wants drinks without alcohol. It does not sell anything or link to a store. Pass kind bottle when the user says bottle, spirit, liquor, or booze; otherwise leave kind as any. A bottle is a spirit, liqueur, vermouth, amaro, wine, or bitters, not a juice, syrup, or garnish.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Pass bottle when the user says bottle, spirit, liquor, or booze. any also allows juices, syrups, garnishes, and mixers. | any |
| limit | No | How many bottles to return. Defaults to the single best one. | |
| ingredients | Yes | ||
| zero_proof_only | No | When true, only count zero-proof catalog drinks. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| links | Yes | |
| display | Yes | |
| recognized | Yes | |
| suggestions | Yes | |
| unrecognized | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds non-obvious behavior: results are drawn from the catalog, only the single best bottle is returned, and there is no commerce/purchase path. It does not describe pagination or failure modes, so it stops short of a 5.
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?
Front-loads the trigger condition before the mechanics, which is the right ordering. Most sentences earn their place, though the kind/bottle guidance overlaps with the schema's own description and could be tightened.
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?
With an output schema present, return values need not be explained, and the description covers trigger, parameter routing, and a scope boundary. Given four parameters and enum semantics, this is nearly complete; only the limit parameter is left implicit.
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 75%, so most parameters are already documented. The description still adds meaning beyond the schema by clarifying that a 'bottle' excludes juices, syrups, and garnishes, and by explaining zero_proof_only in user-intent terms. It omits any discussion of limit, leaving that entirely to the 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?
States a specific verb and resource ('Suggest the next ingredient', 'Returns the one catalog bottle that unlocks the most drinks') and constrains scope to 'single' and 'most new cocktails from what they already have'. An agent can distinguish this from find_cocktails_from_bottles (which lists drinks rather than recommending one addition) without opening either schema.
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?
Explicitly says when to use it ('when the user asks which single ingredient or bottle to add') and gives conditional routing for parameters ('Pass kind bottle when the user says bottle, spirit, liquor, or booze; otherwise leave kind as any'). Also states a negative boundary: 'It does not sell anything or link to a store.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_drink_of_the_daysuggest_next_ingredient6 fields changedInput schema / properties / kindAdded value: +{
+ "default": "any",
+ "description": "Pass bottle when the user says bottle, spirit, liquor, or booze. any also allows juices, syrups, garnishes, and mixers.",
+ "enum": [
+ "bottle",
+ "any"
+ ],
+ "type": "string"
+}Output schema / properties / displayAdded value: +{
+ "const": "next_ingredient",
+ "type": "string"
+}Output schema / properties / kindAdded value: +{
+ "enum": [
+ "bottle",
+ "any"
+ ],
+ "type": "string"
+}Output schema / properties / suggestions / items / properties / example_cardsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "image_url": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "image_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / suggestions / items / requiredPrevious value: -[
- "name",
- "slug",
- "unlocks_now",
- "unlocks_with_one_more",
- "example_cocktails"
-]New value: +[
+ "name",
+ "slug",
+ "unlocks_now",
+ "unlocks_with_one_more",
+ "example_cocktails",
+ "example_cards"
+]Output schema / requiredPrevious value: -[
- "recognized",
- "unrecognized",
- "suggestions",
- "links"
-]New value: +[
+ "recognized",
+ "unrecognized",
+ "suggestions",
+ "links",
+ "display",
+ "kind"
+]find_cocktails_from_bottlesget_cocktail_recipesuggest_next_ingredientCocktail recipes and an exact ingredient finder: what can I mix with what I have at home?
Search 500 cocktail recipes, get full recipes, find drinks by ingredient, suggest random picks.
Real recipes you can cook from the food you already have, with exactly what is missing.
Cocktails MCP — TheCocktailDB API (free, no auth)
Add one secure layer between your agents and this server.
