Loading ToolBench
An e-commerce platform with admin dashboard, shopping cart, product management, orders, payments, and AI chat features
Zippy is an HTTP-based e-commerce MCP server with 25 tools covering user auth, product management, shopping cart, orders, and payment. However, the implementation has significant quality gaps. While all 25 tools have basic input schemas visible, most descriptions are terse (avg ~40-50 chars, well below the 194-char baseline for A+ tools). Parameter descriptions are often single words ('User name', 'User email address') with no constraints, ranges, or usage guidance. No output schemas are documented. Error handling guidance is absent. The naming convention has issues: 'logiUser' (typo for 'loginUser'), 'check-auth' (inconsistent kebab-case), 'handleZippyChat' (vague verb). Several tools combine multiple concerns (e.g., 'deleteCart' both removes items AND clears entire cart). No evidence of idempotency guarantees, pagination support, or recovery guidance. Security concerns are present: user IDs are passed as parameters in auth-dependent operations (addToCart, getCart) without documented permission gates.
Add a new address for a user
Add a new product to the inventory
Add a product to user's shopping cart
Verify if a user is authenticated by checking JWT token
Create a Stripe payment checkout session
Create a new order
Delete an address
Remove a product from cart or clear entire cart
Tool naming inconsistencies and clarity issues: 'logiUser' contains a typo (should be 'loginUser'), 'check-auth' uses kebab-case while others use camelCase, 'handleZippyChat' uses a vague verb ('handle') instead of action-oriented naming like 'sendChatMessage'. LLMs struggle to disambiguate intent from these non-standard names.
Descriptions are uniformly terse (avg 40-50 chars, all under 60 chars). Baseline for A+ is 194 chars. No guidance on WHEN to use each tool, WHAT it returns, or prerequisites. Example: 'Authenticate a user and return JWT token' lacks context on token expiry, storage, or security implications.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Delete a product by ID
Update an existing product by ID
Fetch all products from inventory
Fetch products with optional filtering
Retrieve all addresses for a user
Retrieve all orders (admin only)
Retrieve user's shopping cart
Retrieve orders for the authenticated user
Retrieve a specific order by ID
Handle AI chat messages using Google Generative AI
Upload product image to cloud storage
Authenticate a user and return JWT token
Logout a user and invalidate their session
Register a new user with username, email, and password
Update an existing address
Update quantity of a product in cart
Update the status of an order
Parameter descriptions are minimal (single words: 'User name', 'Product ID') with NO constraints, ranges, enums, or format specifications. Example: 'category' in addProduct accepts free-form strings but should declare enum: [men, women, kids, accessories, footwear]. LLMs will hallucinate invalid category values.
No output schemas documented for any tool. Agents cannot know what fields to expect (e.g., does getCart return item IDs, prices, quantities?). This forces the LLM to guess about response structure and inhibits chaining between tools.
No pagination support documented. fetchAllProducts and getAllOrders have no limit/offset/page parameters or guidance on result count caps. Returning thousands of items blows context windows and increases hallucination risk.
Tool overloading: deleteCart combines two responsibilities, remove a single product OR clear entire cart (depending on whether productId is provided). This should be split into deleteCartItem and clearCart for clarity and composability.
No error handling guidance. Tools provide no recovery hints (e.g., 'User not found. Try registerUser() first.'). LLMs receive raw error codes with no actionable next steps.
Security concern: userId is passed as a parameter in cart and order operations (addToCart, getCart, updateCart, deleteCart, createOrder, addAddress, getAllAddress, updateAddress). No evidence of server-side permission gates or audit logging. An agent could manipulate another user's cart by changing userId.
Destructive operations (deleteProduct, deleteCart, deleteAddress) lack confirmation/dry-run support. An agent mistake could irreversibly delete user data or inventory without a safety check.
Missing idempotency guarantees: No documentation on whether repeated calls with same parameters produce the same result or duplicate side effects. Critical for operations like createOrder and create-checkout-session, agents retry on failures and could create duplicate orders/charges.