Loading ToolBench
This MCP server has significant definition quality gaps across most tools. While tool naming follows verb_noun conventions (get_, add_, remove_, clear_, search_, perform_), parameter schemas are inconsistent and most tool descriptions lack essential detail. Of 8 tools, 2 have empty input schemas (no parameters), 3 have single ASIN parameters with proper validation, 2 have empty schemas, and 1 has a single searchTerm parameter. Descriptions vary from adequate to problematic: some include implementation guidance for the LLM ('You should always ask for confirmation'), which is redundant and not production-standard. Error handling is present but generic. Output schemas are not documented anywhere. Critical issue: tool descriptions lack context about when to use each tool vs alternatives, e.g., why choose remove-from-cart over clear-cart? No guidance provided.
Add a product to the Amazon cart using ASIN - You should always ask for confirmation to the user before running this tool
Clear all items from the Amazon cart
Get the current cart content for a user - Always provide the product link when you mention a product in the response
Get orders history for a user
Get detailed information about a product using its ASIN - Always provide the product link when you mention a product in the response
Checkout with the current cart and complete the purchase - Before purchasing, you should verify in the cart content that your are not buying another product that was already there. If there are other products, clear the cart then add the items that the user want to buy again to the cart. Eventually you can purchase. You should always ask for confirmation to the user before running this tool
Tool descriptions contain implementation guidance ('You should always ask for confirmation to the user before running this tool') instead of declarative WHAT/WHEN/WHY. This is instruction-jacking and violates the separation of concerns between tool definition and agent behavior control.
No output schema documentation. Tools return JSON via text/content blocks, but the structure of that JSON is not declared. LLMs cannot plan downstream calls without knowing what fields to expect. For example, get-orders-history and search-products return lists but pagination behavior is undocumented.
clear-cart has minimal description ('Clear all items from the Amazon cart') with no warning about destructive nature, no recovery path, and no mention of confirmation. This is an irreversible operation that should mandate explicit user consent or dry-run capability.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
Remove a single item from the Amazon cart by its ASIN, leaving all other items untouched - Use this instead of clear-cart when you only want to drop or swap specific products. You should always ask for confirmation to the user before running this tool
Search for products on Amazon using a search term - Returns a list of products matching the search term - Always provide the product link when you mention a product in the response
perform-purchase description is confusing and instruction-like ('Before purchasing, you should verify in the cart content...'). It reads as pseudo-code rather than a clear declaration of what the tool does. No explanation of payment flow, no idempotency guarantee, no rollback path.
No distinction between similar tools. remove-from-cart and clear-cart both mutate cart state, but LLMs are not given guidance on when to use each. The description says 'Use this instead of clear-cart when you only want to drop or swap specific products' but that's instruction language, not declarative definition.
Error messages are generic ('An error occurred while...'). Per pattern:recovery-guide, errors must tell the LLM what to do next. Example: if add-to-cart fails due to invalid ASIN, the error should say 'Invalid ASIN format' and suggest calling search-products to find the correct ASIN.
No pagination support. search-products and get-orders-history likely return variable-length lists, but there are no limit, offset, or cursor parameters. Large result sets will exceed context windows.