Loading ToolBench
A brewing knowledge MCP server — beer styles, ingredients, off-flavour diagnosis, water chemistry, and recipe guidance for AI brewing assistants
Brewers Almanack demonstrates solid domain-specific tool coverage with clear naming and reasonable descriptions for a specialized knowledge domain. All 11 tools are explicitly registered with names, descriptions, and input schemas. However, the server has notable gaps in parameter constraint documentation, output schema specification, and error handling guidance. Tool descriptions average ~120 characters (below the 194-char baseline for A+ tools) and lack actionable context for LLM selection. Parameters are typed but many lack enum constraints or validation boundaries. No evidence of output schema documentation, pagination support, or error recovery guidance. The domain is well-understood (brewing knowledge is cohesive), but tool design could better follow composition patterns and parameter clarity standards.
Calculate International Bittering Units (IBU) for a recipe using Tinseth, Rager, or other methods
Calculate mineral additions (salt, gypsum, chalk, etc.) needed to achieve target water chemistry
Check current stock status and pricing of ingredients from GetErBrewed custom kit builder inventory
Diagnose beer off-flavours by character, taste description, or suspected causes and get prevention/remediation advice
Find water profiles that match a target beer style or get water chemistry guidance for specific brewing goals
Get food pairing suggestions for a beer style or retrieve pairing guidelines
Analyse and review a beer recipe for balance, style conformance, and feasibility with suggestions for improvement
Output schemas are not documented in tool definitions. LLMs cannot predict what fields to expect or plan downstream chaining. Tools like 'suggest_recipe' and 'review_recipe' return complex objects but schema is invisible to the agent.
Parameter constraints are missing or incomplete. 'ingredientType' in search_ingredients accepts free-form strings rather than an enum (malt|hop|yeast|adjunct). 'method' in calculate_ibu should enumerate valid methods (Tinseth, Rager, Bigness). This invites hallucinated invalid values.
Numeric parameters lack boundaries. 'wortVolume', 'originalGravity', 'volume' in calculate_ibu and calculate_water_additions have no min/max constraints. LLMs can pass absurd values (1000000 litres) that break calculations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Search and retrieve brewing ingredients (malts, hops, yeast, adjuncts) by name or characteristics
Search and retrieve BJCP beer style guidelines by name, characteristics, or keywords
Generate beer recipe suggestions based on style, ingredients, and brewing constraints
Suggest ingredient substitutions for a hop, malt, or yeast with brewing impact analysis
Object parameters lack internal schema definition. 'constraints' in suggest_recipe, 'recipe' in review_recipe, 'currentProfile'/'targetProfile' in match_water_profile and calculate_water_additions are typed as 'object' with only description text. LLMs cannot determine valid fields or structure.
No error handling guidance. Tools return descriptions with READ_ONLY risk marking but no indication of what errors to expect, how to recover, or when to retry. E.g., 'diagnose_off_flavour' provides no guidance if an off-flavour is unrecognized.
Tool descriptions are domain-specific but lack LLM disambiguation. 'suggest_recipe' vs 'review_recipe' differ subtly, descriptions do not explicitly state when to use each. 'suggest_recipe' should clarify: 'Generates recipe from scratch based on style and constraints. Use this to create new recipes.' 'review_recipe' should say: 'Validates and analyzes an existing recipe for balance and conformance.'
No pagination support documented. Tools like 'search_styles', 'search_ingredients' likely return variable-length lists but no limit, offset/cursor, or result count is visible in schemas. Large result sets will blow context windows.
Dependencies between parameters are undocumented. In calculate_ibu, 'bitingHops' is an array but structure is unspecified, are they objects with 'name', 'weight', 'time' fields? In match_water_profile, 'targetProfile' structure is unclear and may differ from 'currentProfile' in calculate_water_additions. Undocumented parameter relationships cause silent misuse.
check_geb_stock couples knowledge domain with external inventory service. This creates a maintenance burden if GetErBrewed API changes and mixes read-only domain knowledge with live commerce data. Consider separating into domain-only tools.