Loading ToolBench
Your dependable grocery shopping pal with MCP integration. Live interface to Raley's / Bel Air / Nob Hill grocery store API with price history tracking, coupon management, and Type 1 diabetes nutrition guidance.
18 tools with generally good naming (verb-noun structure), present descriptions, and JSON Schema input parameters. However, critical gaps remain: (1) output schemas are NOT documented anywhere in the codebase, LLMs cannot predict return structures; (2) descriptions are inconsistent in depth, some are ~40 chars, others ~180 chars, but none guide recovery from errors; (3) several parameter descriptions are minimal or generic ('Product SKU to remove' lacks format/validation guidance); (4) no per-tool error handling guidance (pattern:recovery-guide missing); (5) no tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY risk classifications in the provided metadata. The MCP_INSTRUCTIONS string in mcp_server.py provides high-level workflow guidance but does NOT substitute for structured error recovery at tool level. The server supports STDIO only, capping protocol readiness at 50 regardless of definition quality.
Add single item to cart. Returns cart state after mutation
Bulk add items: pass 'sku:cents,sku:cents:qty,...' from plan results
Check if session cookies are valid
View current cart with fulfillment store, delivery address, fees. Includes `items_count` and `total_units`
Compare expected SKUs against actual cart. Shows missing, extra, qty mismatches
Best-value items this week: clipped coupons + sale prices + price history
Output schemas completely undocumented. The codebase provides NO schema definitions for tool return values. LLMs cannot predict what fields (e.g., cart_total, price_suspect, gi_cat, reason) will be returned, forcing them to reason blindly about downstream field availability. This violates pattern:tool and pattern:response-shaper fundamentally.
No error recovery guidance in tool descriptions. Tools like remove, add, store (set), offers (clip_all), and memory (set) are destructive or mutating, yet descriptions do NOT tell LLMs what to do if they fail. E.g., remove returns 'reason on failure + cart state' but the description doesn't explain which reasons are retryable vs permanent, or what the LLM should do next. Violates pattern:recovery-guide.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Purchase history: `products` (recent), `brands` (by product count), `sync` (refresh)
Search T1D books. Use `book`+`heading` to fetch full section after searching
Read/write shopping memory. Use `section=t1d/shopping/notes` to filter
Coupon management: `list` unclipped, `clip_all`, or `sync` to local DB
Past order history with totals
Parse a freeform grocery list, find matches + totals. Does not add to cart
Price history for a SKU, search local DB, or `clear=true` to reset cache
Read a previously saved file (from `save_to_file=true`)
Remove item from cart by SKU. Returns reason on failure + cart state
Find products. Returns best match with SKU, price, sale status, unit price
Search multiple products at once (up to 15). Returns best match per query
View/change fulfillment store: `info`, `set` (by address_id or address), `lookup` (by number), `addresses`
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are missing. The metadata provided lists risk classifications (READ_ONLY, WRITE) but tools are NOT decorated with MCP's current toolAnnotations. This blocks LLMs from understanding idempotency and destructiveness without parsing descriptions.
Parameter descriptions are too generic or shallow. Examples: 'Product SKU to remove' (remove tool) lacks format/validation guidance; 'Address ID for set action' (store tool) doesn't explain how to obtain a valid address_id; 'Colon-delimited plan string' (add_plan) provides format hint but no example or error recovery hint. Violates pattern:tool-description.
Enum constraints underdescribed. Tools like store, offers, favorites, memory, knowledge use enum actions but descriptions don't guide LLMs on which action to pick for common intents. E.g., store has actions [info, set, lookup, addresses], when should the LLM pick each? Only inline MCP_INSTRUCTIONS provide this, not tool-level hints.
Pagination / result limits NOT enforced or documented. Tools like search, search_batch, orders, favorites, deals return lists but descriptions don't state max results or pagination mechanism. MCP_INSTRUCTIONS mention '...up to 15' for search_batch but this constraint is absent from the tool schema itself. Violates pattern:paginated-result.
Natural identifier acceptance NOT documented. The cart, store, and search tools hint at accepting human-friendly names ('address', 'store number', 'grocery list text') but do NOT document fallback behavior if a lookup fails. Violates mxe:natural-identifiers (users say 'Safeway on Main St', not 'store_7291').
Response field names NOT guaranteed to match chaining needs. E.g., cart tool returns 'items_count' and 'total_units' (documented in MCP_INSTRUCTIONS) but the tool schema itself does NOT declare these fields, so LLMs cannot chain results reliably. Violates pattern:tool-chain and mxe:response-field-naming.
Incomplete composition for multi-step operations. E.g., adding items to cart requires: (1) search/plan to find SKUs, (2) add/add_plan to add to cart, (3) cart to verify. The tools exist but descriptions do NOT explicitly guide LLMs through the 3-step flow, forcing inference. Violates pattern:tool-chain guidance.