Loading ToolBench
Claude Desktop MCP server for weekly meal planning with Colorado grocery delivery integration (King Soopers, Safeway, Walmart)
Claude Grocery demonstrates solid tool definition quality with comprehensive schemas, clear descriptions, and good naming conventions across 16 tools. All tools are explicitly registered with descriptions and input schemas. However, there are notable gaps in error handling guidance, output schema documentation, and parameter-level granularity that prevent a higher score. The server follows verb-first naming (generate, modify, search, manage, create, delete, estimate, save) effectively. Descriptions are generally detailed (ranging 150-300 chars) and explain WHAT the tool does and WHEN to use it. Input schemas use Zod with proper type definitions, but output schemas are not formally documented, responses are JSON stringified without declared field structures. Error handling exists but lacks recovery guidance; most error paths return generic JSON error objects without actionable next steps or classification (retryable vs. fatal). Several tools accept optional IDs with fallback to 'most recent,' which is idiomatic but underdocumented for LLMs (requires reading implementation to understand behavior).
Add items to an authenticated Kroger customer's cart. Requires customer OAuth authentication (Authorization Code flow). If no customer token is provided, returns the authorization URL for the customer to log in.
Create an Instacart shopping list from a grocery list. Generates a shareable Instacart URL that the user can open to review and order. Requires Instacart integration to be configured.
Create a new weekly meal plan. Provide a Monday start date (YYYY-MM-DD format). The plan spans 7 days (Monday-Sunday). After creating, use set_meal_slot to assign recipes to specific days and meal types.
Delete a meal plan and all its meal slots by ID.
Estimate the total cost of a grocery list and compare it against the household weekly budget. Returns a breakdown by department with estimated costs, and flags if the list is over budget. Uses estimated item prices from the grocery list.
Output schemas not formally documented. All 16 tools return JSON strings without declared field types, constraints, or structures. LLMs must infer output shape from examples in code; this violates pattern:response-shaper and causes error-prone parsing.
Error handling lacks recovery guidance. Most tools return generic { error: String(error) } JSON without classifying errors as retryable, user-fixable, or fatal, nor suggesting next actions. E.g., 'Meal plan not found: xyz' should suggest 'Use get_meal_plan() to list available plans or create_meal_plan() to generate a new one.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Find grocery stores near a zip code. Uses the Kroger API to search for King Soopers, Safeway, and other Kroger-family stores. If no zip code is provided, uses the household profile zip code. Returns store details including address, phone, and departments.
Generate a consolidated grocery list from a meal plan. Aggregates all ingredients across recipes, deduplicates and converts units, excludes pantry staples, and organizes items by store department. This is the primary way to create a shopping list.
Generate Walmart.com search links for each item on a grocery list. Returns URLs that the user can click to find and add items on Walmart's website. Works without API keys.
Retrieve a meal plan by ID, or get the most recent plan if no ID is provided. Returns the full 7-day plan with all assigned meal slots.
Get or update the household profile. Use action "get" to retrieve the current profile, or "update" to modify it. The household stores member info (names, ages, dietary needs), preferred store, weekly budget, and zip code.
Manage pantry staples (items the user always has on hand and should NOT appear on grocery lists). Actions: "list" shows current staples, "add" adds new items, "remove" removes items by name, "reset" restores the default staple list. Common staples include salt, pepper, olive oil, butter, etc.
Modify an existing grocery list. Actions: "add_items" to add new items, "remove_items" to remove items by ID, "update_item" to change quantity/unit/checked status, "get" to retrieve the current list.
Save a new recipe to the database. Provide the full recipe including title, servings, ingredients with quantities/units, and step-by-step instructions. Ingredients are automatically normalized and categorized by store department.
Search for products on Kroger/King Soopers by keyword. Returns product details including price, size, aisle location, and availability. Requires a Kroger location ID (use find_nearby_stores first) and Kroger API credentials to be configured.
Search saved recipes by keyword, tags, dietary flags, cuisine type, or prep time. Returns matching recipes sorted by most recently updated. All parameters are optional filters that are combined with AND logic.
Assign a recipe to a specific day and meal type in a meal plan. Use dayIndex 0-6 (Monday=0, Sunday=6). You can reference a saved recipe by ID, or provide a recipeName for a quick placeholder. Mark meals as leftovers with isLeftover=true.
Conditional parameter requirements not schema-enforced. Tools like modify_grocery_list, manage_household, and manage_pantry require different parameters depending on action/enum value (e.g., addItems required if action='add_items'), but JSON Schema does not express this. LLMs may pass invalid combinations, leading to silent failures or vague errors.
Generic tool names reduce clarity. 'manage_household' and 'manage_pantry' are vague per pattern:tool-naming. Splitting into get_household + update_household and list_pantry + add_pantry_staples + remove_pantry_staples would make intent explicit and reduce LLM confusion.
Missing constraints on numeric parameters. limit, radiusInMiles, maxPrepTimeMinutes, servings lack documented min/max ranges. E.g., search_recipes limit has no stated default or max; LLMs may pass 999999, wasting tokens or timing out.
Destructive operation (delete_meal_plan) lacks confirmation or dry-run pattern. Per pattern:confirmation-request, irreversible deletes should offer a confirm-before-execute step to prevent agent mistakes. Currently no safeguard.
Optional resource fallbacks (e.g., 'omit to use most recent list') are underdocumented for LLM reasoning. Tools like estimate_budget, modify_grocery_list, and get_meal_plan accept optional IDs with undocumented 'most recent' fallback. This idiomatic pattern requires reading implementation; LLMs may not understand when fallback applies or may mistakenly assume IDs are required.