Loading ToolBench
MCP server for HEB grocery store integration
Server has 25 tools with generally reasonable naming and descriptions, but quality is inconsistent. Strengths: consistent verb-noun naming, most tools have descriptions and input schemas. Weaknesses: many parameter descriptions are minimal, output schemas are not documented, error handling guidance is sparse, and parameter constraints are often missing. The server handles authentication and sensitive operations but does not explicitly document permission gates or audit trails. Average tool quality is fair (C range), pulled down by incomplete schemas and lack of structured error recovery patterns.
Add a product to shopping cart
Add multiple products to shopping cart in a single request
Add product to cart with automatic retry on failure
Check if user is authenticated for cart operations
Get current shopping cart contents
Remove a product from shopping cart
Get available coupon categories
Output schemas not documented. 15 tools lack visible return type documentation (coupon_categories, coupon_clipped, cart_check_auth, cart_get, session_status, session_clear, session_clear_credentials, health_live, health_ready, and others). LLMs cannot infer response structure and must guess at field names for downstream tool chains.
Parameter descriptions are generic or minimal. Many parameters documented only as 'optional' without explaining what values are valid, constraints, or downstream effects. Examples: 'Page number (optional)' in coupon_list lacks min/max bounds; 'Filter by category ID (optional)' lacks enum values or where to find valid category IDs.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Clip a digital coupon to account
Get list of clipped coupons for the authenticated user
List available digital coupons
Search for coupons by keyword
Liveness probe - checks if the server is running
Readiness probe - checks if the server is ready to accept requests
Get detailed product information including ingredients, nutrition, and warnings
Search for products
Search for multiple products in a single batch request
Clear session cookies and authentication state
Remove stored HEB credentials
Refresh HEB session using embedded Playwright or fallback commands
Save HEB credentials securely for automatic login
Save custom instructions for session management
Check authentication status and session lifecycle information
Change store on HEB.com when authenticated, or set local default
Get the default store or the one set locally
Find stores by address
No error handling guidance in tool descriptions. Destructive operations (coupon_clip, cart_add, cart_remove, session_clear_credentials) do not document what errors are possible, when to retry, or recovery paths. An LLM cannot self-correct or plan fallback actions.
Overlapping tool responsibilities. cart_add_with_retry duplicates cart_add logic (same SKU and quantity params, same destructive operation) but adds retry logic. This forces the LLM to decide between two nearly identical tools. Either integrate retry into cart_add or rename cart_add_with_retry to clarify its purpose (e.g., 'cart_add_resilient').
No pagination limit or result cap documented. cart_get, product_search, coupon_list, and batch operations do not state maximum result counts or offset/limit behavior. If a product search returns 10,000 items, LLMs will attempt to process all, wasting tokens and context.
Permission gates not explicitly documented. session_save_credentials and session_clear_credentials handle sensitive authentication data, but no description states who can call these tools or what permissions are required. No audit trail declaration for compliance logging.
Dependency hints missing from descriptions. coupon_clip and cart_add require authentication (per MCP_INSTRUCTIONS), but tool descriptions do not state this. An LLM might attempt these without first checking session_status, leading to failed calls and wasted turns.
cart_add_with_retry has an ambiguous purpose. Description says 'automatic retry on failure' but does not explain: How many retries? What backoff? What counts as a failure (network, auth, out-of-stock)? This makes it unclear when to use it vs cart_add.