Search the Pour Picks bourbon & whiskey database: 4,700+ bottles with tasting profiles and prices.
Scored across 8 tools
Tools have distinct purposes with clear input parameters; minor overlap between get_recommendations and pour_tonight_suggestion (both take occasion) and between find_similar and find_cheaper_alternative, but descriptions differentiate them well.
All snake_case, mostly verb_noun pattern. Deviations like find_similar (no noun) and trending_bottles (no verb) are minor but prevent perfect consistency.
8 tools is well-scoped for a bourbon discovery server; each tool covers a distinct discovery or recommendation need without redundancy.
Covers search, detail, comparison, similarity, cheaper alternatives, personalized recommendations, mood-based suggestions, and trending. Minor gap: no user cellar or rating management, but not core to the discovery purpose.
Side-by-side comparison of two bottles: proof, age, price, flavor profile, shared and distinct tasting notes, and community ratings.
| Name | Required | Description | Default |
|---|---|---|---|
| bottle_a | Yes | First bottle — UUID or name | |
| bottle_b | Yes | Second bottle — UUID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value by enumerating what the comparison returns (proof, age, price, flavor profile, shared/distinct notes, community ratings) — useful since no output schema exists. It does not cover edge behavior such as an unknown bottle name.
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?
A single sentence, front-loaded with the action and resource, followed by the compared fields. No wasted words and nothing buried.
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 no output schema, the description usefully lists the returned comparison fields, and both required parameters are documented in the schema. It lacks only minor edge-case behavior (e.g., unmatched bottle names), so it is close to complete for a simple two-argument read tool.
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 both parameters ('UUID or name') are fully documented in the schema, so the description adds nothing about inputs. Baseline 3 applies 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 ('side-by-side comparison') and resource ('two bottles'), and enumerates the dimensions compared. This clearly differentiates it from sibling read tools like get_bottle or find_similar, which return single-bottle or similarity data rather than a paired comparison.
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 side-by-side framing implies when it applies (two known bottles the user wants compared), but there is no explicit guidance on when to prefer it over find_similar or get_bottle, and no stated preconditions. Usage is inferred from the name and description rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bottles in the same style with a similar flavor profile at a lower price than the given bottle. Use for 'what tastes like X but costs less' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5) | |
| bottle_id | Yes | Bottle UUID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds that results are price-constrained relative to the input, but says nothing about empty-result behavior, result count default, or whether the input bottle itself can appear. Adds some value over annotations, 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?
Two tight sentences, zero waste. The result definition is front-loaded and the usage trigger follows immediately.
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 read-only lookup with no output schema and full parameter documentation, this covers what the tool returns and when to call it. Only minor gaps remain (no-result handling, whether the source bottle is excluded).
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 bottle_id (UUID or name) and limit (1-10, default 5) are fully documented in the schema. The description adds no parameter-level syntax or constraints beyond what the schema already states; baseline 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?
States a specific verb and resource ('bottles ... at a lower price than the given bottle') and adds a qualifying constraint (same style, similar flavor) that implicitly separates it from find_similar. It never names a sibling, so the differentiation is inferred rather than explicit.
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 a concrete when-to-use trigger: "'what tastes like X but costs less' questions." There is no when-not guidance or explicit routing to compare_bottles/find_similar, but the trigger is clear enough to select the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bottles with a similar flavor profile to a given bottle, ranked by shared flavor notes and body/sweetness/char proximity. Deterministic scoring over the Pour Picks structured tasting data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5) | |
| bottle_id | Yes | Bottle UUID or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety and idempotency profile is covered. The description adds meaningful behavioral context beyond that: the scoring is explicitly deterministic and grounded in 'Pour Picks structured tasting data', telling the agent results are reproducible and data-derived rather than generative.
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 tight sentences with the core purpose and ranking method front-loaded; there is no filler or redundancy.
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 no output schema, the description does convey the nature of the results (bottles ranked by similarity criteria), and both parameters are fully documented in the schema. It could say slightly more about ordering ties or return fields, but it is adequate for a two-parameter read tool.
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 schema documents both limit (max 10, default 5) and bottle_id (UUID or name). The description adds no parameter-level detail beyond the schema, so the baseline of 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 names a specific verb+resource (find bottles similar to a given bottle) and specifies the ranking criteria (shared flavor notes, body/sweetness/char proximity). This clearly distinguishes it from siblings like compare_bottles and find_cheaper_alternative.
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?
Usage is implied by the purpose, but there is no explicit guidance on when to choose this over compare_bottles, get_recommendations, or find_cheaper_alternative, and no stated exclusions or prerequisites. The agent must infer routing from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detailed record for one bottle: tasting profile, flavor notes, pairings, price, community ratings. Accepts a Pour Picks bottle ID (UUID) or a bottle name.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Bottle UUID or a name like 'Eagle Rare 10' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and repeatability are covered. The description adds the useful detail that the record's payload includes tasting profile, pairings, price, and community ratings, but says nothing about behavior on a missing/ambiguous bottle or lookup ambiguity between name and UUID.
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 tight sentences with zero filler, and the payload summary is front-loaded before the input note. Every clause carries 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?
With one required parameter and no output schema, the description usefully enumerates what comes back, which is exactly the gap structured data leaves. It stops short of covering failure modes or how an ambiguous name resolves, but it is otherwise adequate for a simple lookup tool.
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 single parameter is already documented as 'Bottle UUID or a name like Eagle Rare 10'. The description restates the dual ID-or-name acceptance without adding format rules, disambiguation behavior, or normalization details beyond 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 ('Detailed record for one bottle') and enumerates the record's contents (tasting profile, flavor notes, pairings, price, ratings). It implicitly contrasts with the list-oriented siblings like search_bottles and trending_bottles by scoping to a single bottle, but never names an alternative 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?
The phrase 'Accepts a Pour Picks bottle ID (UUID) or a bottle name' implies you call this when you already have an identifier, which distinguishes it from search_bottles by inference only. There is no explicit when-to-use, when-not-to-use, or named alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Personalized bottle picks from taste preferences (flavor keywords like 'caramel', 'smoke', 'cherry'), a budget in USD, and an occasion (e.g. 'gift', 'everyday sipper', 'celebration', 'introducing a friend to bourbon').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 5) | |
| budget | No | Max price in USD | |
| category | No | Restrict to one spirit category | |
| occasion | No | What the bottle is for | |
| taste_preferences | Yes | Flavor keywords the drinker enjoys, e.g. ['caramel','vanilla','oak'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds no behavioral detail beyond that - nothing about how picks are ranked, how many come back by default, or result variability - leaving only modest added value.
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?
A single front-loaded sentence that leads with the outcome ('Personalized bottle picks') before listing drivers. The parenthetical example lists are slightly long but each illustration adds selection signal, so little is wasted.
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 five parameters and no output schema, the description should carry more burden in describing what a 'recommendation' returns (fields, count, ranking basis), which it omits. It covers inputs adequately but leaves the result shape undefined for an agent.
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%, so the baseline is 3, but the description enriches semantics by supplying concrete flavor keywords ('caramel', 'smoke', 'cherry') and richer occasion examples beyond the schema's generic 'What the bottle is for'. Budget is explicitly tied to USD, clarifying units.
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 names a specific output ('personalized bottle picks') and the inputs that drive it (taste preferences, budget, occasion), so the verb+resource is unambiguous. It stops short of distinguishing itself from siblings like search_bottles or trending_bottles, which an agent would need to disambiguate a recommendation request.
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 is implied through the enumerated inputs and occasion examples ('gift', 'celebration', 'introducing a friend to bourbon'), which convey the personalized-pick scenario. There is no explicit when-to-use versus alternatives or any exclusions, so guidance remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A pour suggestion for right now, based on mood (e.g. 'unwinding', 'celebratory', 'contemplative'), occasion (e.g. 'nightcap', 'with friends', 'after dinner'), and season.
| Name | Required | Description | Default |
|---|---|---|---|
| mood | No | How you're feeling | |
| season | No | Season to weight the pick toward — heavier, warming pours in winter; lighter in summer | |
| occasion | No | The setting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only that the pick is situational/personalized; it does not say whether all inputs are optional with defaults, what is returned, or how the weighting behaves when inputs are omitted.
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?
A single front-loaded sentence with no filler. The parenthetical examples are the only elaboration and they directly earn their place by illustrating the open-ended inputs.
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 zero required parameters and a fully documented schema, the description is nearly sufficient, and 'a pour suggestion' hints at the return. It stops short of explaining behavior when no inputs are supplied (which matters since all three are optional) or what form the suggestion takes, with no output schema to fall back on.
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%, so baseline is 3, but the description goes beyond it by supplying concrete example values for the two open-ended string parameters ('unwinding', 'celebratory', 'contemplative'; 'nightcap', 'with friends', 'after dinner'), which the schema does not. Season semantics are already fully covered by the schema, so no extra credit there.
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: produces a single pour suggestion for the current moment, keyed on mood, occasion, and season. This is clearly distinguishable from list/aggregate siblings like search_bottles or trending_bottles, though it never explicitly names how it differs from get_recommendations.
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?
"For right now" implies the usage context (an immediate, personal pick), and the three named inputs imply when it applies. However, there is no explicit when-to-use statement, no exclusions, and no routing to sibling tools like get_recommendations or find_similar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across 4,700+ bourbons, ryes, scotches, and other spirits in the Pour Picks database. Filter by category, price (USD), and proof. Returns structured tasting profiles with source attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 10) | |
| query | No | Free-text search: distillery, bottle name, or expression | |
| category | No | Spirit category filter | |
| price_max | No | Maximum price in USD | |
| price_min | No | Minimum price in USD | |
| proof_max | No | Maximum proof | |
| proof_min | No | Minimum proof |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety behavior is covered structurally. The description adds useful context (corpus size, return shape 'structured tasting profiles with source attribution') but says nothing about result ranking, empty-result behavior, or why the cap is 10. Solid 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?
Two tight sentences with zero filler. The core capability and scope lead, filters and return shape follow, and no sentence duplicates structured fields verbatim.
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 no output schema, the description usefully discloses the return shape ('structured tasting profiles with source attribution'), which is what an agent most needs here. It is nearly complete for a read-only search tool; only ranking/ordering and behavior on zero matches are left unstated.
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 every parameter (query, category enum, price_min/max, proof_min/max, limit) is already documented with types, bounds, and defaults. The description only restates that category, price, and proof are filterable, adding no format or interaction semantics (e.g. how query interacts with category). Baseline 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?
States a specific verb (full-text search) and resource (spirits catalog), plus scope details ('4,700+ bourbons, ryes, scotches'). An agent can distinguish this from get_bottle (single lookup) or compare_bottles by the word 'search', but the description never names a sibling to sharpen the boundary.
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 phrase 'Full-text search' implies the usage context of exploratory/query-based retrieval, and the filter list hints at narrowing use cases. However, there is no explicit when-to-use versus find_similar, get_recommendations, or find_cheaper_alternative, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bottles Pour Picks users are adding to their cellars most over the last 30 days (falls back to catalog popularity when live activity data is unavailable). The method used is labeled in the response.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, non-open-world behavior, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the 30-day activity window, the fallback to catalog popularity when live data is missing, and the fact that the method is labeled in the response.
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, front-loaded with the primary definition, with the fallback caveat parenthetically attached rather than given its own sentence. No 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?
For a single-parameter ranked-list tool with no output schema, the description covers the ranking basis, the fallback behavior, and where the method is disclosed. It stops short of describing result count/ordering guarantees, but nothing critical to correct invocation 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?
There is one parameter (limit) with 100% schema coverage, including default and max, so the schema already fully documents it. The description contributes nothing about the parameter, which is acceptable but adds no value - the baseline 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?
Names a specific resource (bottles) and a precise ranking criterion (what Pour Picks users are adding to cellars over the last 30 days), which naturally separates it from get_recommendations and pour_tonight_suggestion. It lacks an explicit verb like 'list' or 'return', so the output shape is only implied.
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 'trending' framing implies when it is relevant, but there is no explicit when-to-use, when-not-to-use, or named alternative among the seven siblings. The agent must infer that this is the popularity/activity view rather than a personalized or comparison tool.
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.
find_similar1 field changedInput schema / properties / limit / maximumPrevious value: -15New value: +10search_bottles2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 10)"New value: +"Max results (default 10, max 10)"Input schema / properties / limit / maximumPrevious value: -25New value: +10trending_bottles2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 10)"New value: +"Max results (default 10, max 10)"Input schema / properties / limit / maximumPrevious value: -20New value: +10compare_bottles2 fields changedInput schema / properties / bottle_a / maxLengthAdded value: +200Input schema / properties / bottle_b / maxLengthAdded value: +200find_cheaper_alternative1 field changedInput schema / properties / bottle_id / maxLengthAdded value: +120find_similar1 field changedInput schema / properties / bottle_id / maxLengthAdded value: +120get_bottle1 field changedInput schema / properties / slug_or_id / maxLengthAdded value: +120get_recommendations3 fields changedInput schema / properties / occasion / maxLengthAdded value: +120Input schema / properties / taste_preferences / items / maxLengthAdded value: +60Input schema / properties / taste_preferences / maxItemsAdded value: +20pour_tonight_suggestion2 fields changedInput schema / properties / mood / maxLengthAdded value: +120Input schema / properties / occasion / maxLengthAdded value: +120search_bottles1 field changedInput schema / properties / query / maxLengthAdded value: +120compare_bottlesfind_cheaper_alternativefind_similarget_bottleget_recommendationspour_tonight_suggestionsearch_bottlestrending_bottlesSearch the Perfume Picks fragrance database: 10,000+ scents with notes, dupes, and wear data.
Whisky auction market data: past and live lots, prices, distillery stats and retail listings.
Search 20,000+ wineries worldwide by region, amenities, hours, tasting fees and bookings.
Search the Percolate specialty coffee database: 1,100+ coffees with brew recipes and pairings.
Add one secure layer between your agents and this server.
