An MCP server that integrates with CellarTracker to provide access to your wine inventory and related data.
Server provides 4 tools with reasonable verb-starting names and largely complete schemas. All tools have descriptions and input parameters are well-documented with types. However, output schemas are not explicitly documented, error handling guidance is absent, and some parameter descriptions could be more actionable. Tool descriptions are adequate but fall short of LLM-optimized length (target 50-200 chars; most here are 150-250+ chars). The server uses Zod for schema validation which is good, but the output structure (wrapping in {content: [{type: 'text', text: JSON.stringify(...)}]}) returns unstructured JSON strings rather than typed response schemas, reducing machine-parseability.
Get aggregate statistics about your cellar, including bottles, locations, drinking windows, types, varietals, producers, countries, regions, sub-regions, and appellations.
Fetch the latest wine cellar inventory data from CellarTracker and store it in the database. Run this after making changes in CellarTracker or when first setting up.
Search individual bottles in your cellar with optional filters. Returns up to 200 bottles with location/bin details.
Search wines in your cellar/collection with optional filters. Returns up to 100 matching wines. Use get_cellar_stats to get example values for varietal, producer, region, and other attributes. Use search_bottles tool to see individual bottles of a wine with the bottles' location, purchase, and consumption data.
Output schemas not documented for any tool. Callers cannot determine what fields are returned or plan downstream tool calls.
No error handling guidance. Tools return raw API responses or JSON strings without recovery instructions. If a call fails, the agent has no actionable next step.
Pagination not implemented for list/search tools despite 'returns up to 100/200 results'. Large result sets exceed context window. search_wines and search_bottles should accept limit/offset parameters and return total_count.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Unstructured response format: tools return {content: [{type: 'text', text: JSON.stringify(...)}]}, converting structured data to JSON strings. LLM must parse strings to extract fields, wasting tokens and inviting parsing errors.
Parameter descriptions use examples ('e.g. Red, White, Sparkling') instead of enum constraints for known-finite sets.
refresh_data is a destructive operation (overwrites local database) with no confirmation or dry-run option. Per E.2, irreversible operations should support a confirm_before_execute pattern.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in the tool registration. These would help agents understand safety properties.