list_distilleriesList whisky distilleries tracked by whiskyhunter.net (300+ distilleries with auction data). Returns each distillery name, slug, and country. Use the slug with distillery_prices to get its auction price history. Keyless.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max distilleries to return (default 25, max 60). | |
| search | No | Optional case-insensitive substring filter on distillery name, e.g. "macallan", "glen". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and open-world. The description adds that it is 'Keyless,' meaning no authentication required, and notes the data scope (300+ distilleries with auction data), which supplements the annotations without contradiction.
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 extremely concise: two sentences that cover purpose, output, and a usage tip. No unnecessary words, and every sentence adds value.
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 2-param input, no output schema, and rich annotations, the description covers purpose, output, cross-tool usage, and authentication. It could mention pagination or that the list is not exhaustive, but for its simplicity, it is largely complete.
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 both parameters (limit, search) fully described in the schema (defaults, max, case-insensitive). The description does not add new parameter information beyond the schema, so a baseline score 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 clearly states the tool lists whisky distilleries from whiskyhunter.net, specifies the count (300+), and mentions returned fields (name, slug, country). It also distinguishes from the sibling tool distillery_prices by advising to use the slug with it. The verb 'List' and resource 'distilleries' are precise.
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 tells the agent to use the slug with distillery_prices for price history, providing a clear usage path. It does not explicitly state when not to use the tool, but the cross-reference offers sufficient guidance for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have overlapping purposes (ask_pipeworx, ask_pipeworx_grounded, deep_research all perform research; polymarket_arbitrage, polymarket_edges, polymarket_edge_tracker are similar). Agents may struggle to pick the correct tool.
Naming is inconsistent: some use snake_case (list_distilleries), others are descriptive (ask_pipeworx, deep_research), and some are branded (pipeworx_feedback). No clear pattern.
33 tools is high but not unreasonable given the broad scope. However, the server name implies a whisky focus, making the count feel excessive for that domain.
For the whisky domain suggested by the name, only 3 tools are relevant. The rest are generic or unrelated (Polymarket, npm scanning), leaving significant gaps for whisky-specific tasks.