Loading ToolBench
A simple MCP server for managing shopping carts and purchasing products
SimplePurchaseServer demonstrates critical gaps across naming, descriptions, parameter documentation, and output schema definition. While tool names are adequately verb-prefixed, descriptions are minimal (10-20 chars), parameters lack type information in schemas, and output formats are entirely undocumented. The server lacks error handling guidance, validation constraints, and structured output definitions, all essential for LLM tool selection and safe execution. Per the rubric baseline, A+ tools average 194-char descriptions and 100% param documentation; this server has none of that. No input parameter descriptions are provided in the schema definitions, violating the critical rule that every parameter needs documentation. Output is free-form strings with no schema contract, forcing LLMs to parse unstructured text.
Add a product with given SKU to cart
Purchase all products in cart and empty it
Purchase a specific product by SKU
Display all products in cart
Parameter descriptions completely missing. The 'sku' parameter in add_to_cart and purchase_product has a description in the schema, but tool definitions in source code lack any parameter documentation. LLMs cannot disambiguate what 'sku' means (e.g., product identifier vs. serial number) without explicit guidance.
Tool descriptions are trivially short (10-20 characters). 'Add a product with given SKU to cart' provides no context for WHEN to use add_to_cart vs. purchase_product, no explanation of prerequisites (e.g., must checkout after adding), and no guidance on side effects. Rubric baseline: A+ tools average 194 chars. These descriptions score below p10 (34 chars).
Output schemas are completely undocumented. All four tools return plain strings with no schema declaration. LLMs cannot plan downstream calls, extract structured data, or validate responses. Return type is inferred as string but structure (e.g., what fields are in the order confirmation) is unknown.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 36 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
No error handling or recovery guidance. If add_to_cart is called with an invalid SKU, the server returns success (appends to cart) with no validation. No error messages instruct the LLM what to do next. Checkout with empty cart returns a message, but no categorical error type (retryable, user-fixable, fatal).
Stateful cart implementation violates composition best practices. The cart is a module-level list, making the server stateful and non-idempotent. If an agent retries add_to_cart after a network glitch, the item is added twice. No deduplication or idempotence guarantees. Pattern: idempotent-operation.
Naming ambiguity: add_to_cart and purchase_product perform similar operations (move a product forward) but the distinction is unclear. Does add_to_cart place a hold? Does purchase_product charge immediately? No descriptions differentiate behavior. Pattern: name-clarity suggests 'update_cart_item' vs 'confirm_purchase' or similar.
No input validation constraints. The 'sku' parameter accepts any string with no format, length, or character restrictions documented. An LLM could pass empty strings, special characters, or absurdly long values. Rubric: 'When a parameter has a regex pattern, length limit, or character restriction, state it in the description.'