Loading ToolBench
An MCP server providing tools for interacting with an e-commerce API, including product listing, searching, shopping cart management, and order placement
This server has 6 tools with basic descriptions and schemas, but significant gaps in parameter documentation, error handling, and output schema clarity. Tool names follow verb_noun convention (list_products, search_products, get_product_details, add_to_cart, view_cart, place_order), which is good. However, parameter descriptions are minimal or missing entirely in several cases, and output schemas are not documented anywhere in the provided source. Error handling is present at the JSON-RPC layer but provides no recovery guidance to the LLM. The schema inspection shows that parameters have types (string, number) but lack detailed descriptions for many fields, particularly around constraints, defaults, and valid ranges. No tool has documented return structure, which violates the pattern:tool requirement that output schemas be explicit.
Add a product to the shopping cart (requires authentication)
Get detailed information about a specific product by its ID
List all available products from the store
Place a new order with the items in the shopping cart (requires authentication)
Search for products using a query string
View current shopping cart contents (requires authentication)
Output schemas are not documented. No tool has a documented return type, field structure, or example response. LLMs cannot plan downstream tool calls or extract chaining IDs (e.g., order_id after place_order) without explicit schema documentation.
Parameter descriptions are incomplete. 'limit' and 'offset' in list_products and search_products lack context (e.g., 'Maximum number of products to return (default: 20)' is present but defaults should be stated more clearly, and behavior at boundaries is not specified). 'min_price' and 'max_price' lack units, precision, or validity constraints. 'category_id' is described only as 'The category ID' without explaining how to discover valid IDs or what happens if the ID is invalid.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | 2025-06-18+ | v1 |
Error handling provides no recovery guidance. The mcp/server.go handleToolsCall catches errors and returns CallToolResult with IsError=true and a text message like 'Error: <err.Error()>', but does not guide the LLM on what to do next (retry, try a different tool, ask the user, etc.). Pattern:recovery-guide requires actionable next steps.
place_order (IRREVERSIBLE) lacks a dry-run or confirmation step. Agents make mistakes, an irreversible operation should support confirmation_request pattern so the LLM can verify intent before committing the order. Currently, place_order takes no parameters, meaning there is no opportunity to review the cart contents before execution.
Tool descriptions are generic and lack WHEN-to-use guidance. E.g., 'List all available products from the store' does not explain when to use list_products vs search_products, whether list_products is paginated, or what pagination defaults are. LLMs need context to select the right tool.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server does mark tools as READ_ONLY, WRITE, or IRREVERSIBLE in comments, but these are not exposed to the client via tool annotations. The client cannot infer which tools are safe to call in a planning phase vs require user confirmation.
view_cart and place_order take no input parameters and have no documented output. view_cart should return the current cart contents (products, quantities, subtotal, tax, total) so the agent can verify correctness before calling place_order. Without documented output, the agent cannot chain these tools reliably.
add_to_cart parameter 'product_id' is typed as number in the schema but 'get_product_details' expects product_id as string. This type mismatch forces the LLM to reason about type conversions and risks passing a string to add_to_cart where a number is expected, or vice versa. Schema naming must be consistent across tools.
No pagination guidance in tool descriptions. list_products and search_products accept 'limit' and 'offset', but descriptions do not state what happens if limit exceeds a maximum, whether there is a default sort order, or how to detect the end of results (is there a 'total_count' field?). Baseline pattern:paginated-result requires documentation of pagination mechanics.
Authentication requirement is mentioned in descriptions ('requires authentication') but not enforced at the tool definition level. The server relies on a global AuthToken (from config/config.go) but does not validate that the token is present or valid before calling add_to_cart, view_cart, or place_order. If the token is missing, the error message will be opaque (from the backend API), not actionable.