Loading ToolBench
MCP server for CellarTracker wine cellar data — inventory, drinking recommendations, purchase history, and wishlist
CellarTracker MCP exhibits solid tool structure with comprehensive parameter descriptions and well-defined schemas across all 13 tools. Naming conventions are clear and action-oriented (search-, get-, refresh-, setup-, clear-). However, the server has notable gaps in error handling guidance, lacks tool annotations (readOnlyHint/destructiveHint), and provides minimal actionable recovery paths for LLMs when operations fail. Tool descriptions are generally good (100-200 chars range), but some tools could benefit from clearer WHEN-to-use context. All parameters have type definitions and descriptions, which is above baseline. The Zod schemas in server.ts are properly structured. Main limitation: no explicit guidance for LLMs on how to recover from authentication failures, rate limits, or partial data states.
Get individual bottle records from the Bottles table, including barcode, location, bin, size, and consumption history for consumed bottles. Paginated.
Get summary statistics of the cellar: total bottles, total value, unique wines, average price per wine. Optionally break down by color, region, country, or varietal.
Delete stored credentials and/or cached CSV exports. Selective: you can clear only credentials, only cache, or both. Safe to call when files don't exist — reports what was found.
Get consumption/tasting history from the Consumed table. Shows when wines were consumed, by whom, at what value, and any notes. Paginated.
Get wines sorted by drinking urgency: past-peak first, then closing windows, then in-window, then approaching, then no data.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). 12 READ_ONLY tools and 1 DESTRUCTIVE tool (clear-user-data) are declared in metadata but not via MCP tool annotations.
Minimal error handling guidance for LLMs. Authentication failures (AuthError in exporter.js) do not return actionable recovery steps. No guidance like 'If auth fails, call setup-credentials first' or 'Check CT_USERNAME/CT_PASSWORD environment variables.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2025-06-18+ | v2 |
Get the wishlist/custom lists from the Tag table. Returns wines with optional notes and max price.
Get pending/in-transit orders from the Pending table. These are orders placed but not yet delivered.
Analyze purchase history: total spent, bottle count, average price, breakdown by store, and recent 10 purchases. Optional date range filter (YYYY-MM-DD).
Get wines delivered within a date range (inclusive). Only counts wines with Delivered=true; excludes pending placeholders. Date format: YYYY-MM-DD. Sorted newest delivery first.
Force a refresh of all cached CSV exports from CellarTracker. Fetches 8 tables: List, Notes, Purchase, Consumed, Availability, Tag, Bottles, Pending. Returns row counts and refresh timestamp.
Search the cellar inventory by wine name, region, country, or varietal. Returns paginated results.
Save CellarTracker username and password to ~/.config/cellartracker-mcp/.env for persistent use across sessions. Validates credentials by testing a small fetch. File is chmod 600 (Unix) for security.
Get tasting notes from the Notes table. Includes date, wine, rating, community score, event, and notes. Paginated.
clear-user-data is destructive but lacks confirmation/dry-run pattern. LLMs could accidentally irreversibly delete credentials and cached data without explicit confirmation.
get-wishlist description ('Get the wishlist/custom lists from the Tag table...') lacks WHEN-to-use context. Does it return all tags or only wishlist tags? Are prices included? Can it be filtered?
refresh-data lacks explanation of side effects. Does it invalidate in-memory caches? Can concurrent calls interfere? Should it be retried if it fails halfway?
setup-credentials description mentions file chmod 600 but does not explain what happens if credentials are already stored (overwrite vs merge vs error?).
No rate limit or timeout documentation. Large result sets (e.g., bottle-details with 1000s of bottles) could timeout or exhaust LLM context. No guidance on safe pagination bounds.