Loading ToolBench
Model Context Protocol server for Shopware e-commerce platform integration, providing tools to search and manage products and orders
The server defines 5 tools with reasonable naming conventions (all start with action verbs: search, get, list). Descriptions are present but brief (10-50 chars for most). Input schemas are visible in the code with type definitions and descriptions for all parameters. However, output schemas are not documented, and descriptions lack the depth needed for optimal LLM decision-making. Parameter descriptions exist but are minimal. No evidence of error handling guidance, recovery hints, or validation rules embedded in descriptions. The tools are READ_ONLY (low security risk) but lack enrichment that would make them more composable (e.g., search-orders returns paginated data but missing downstream call IDs).
Get the current stock level for a product by its product number
List orders with pagination support
Find orders by number or list recent ones
Search for a product by its product number
Search for products by name or keyword with optional pagination
Output schemas not documented. Tools return data to LLMs but the expected response structure (fields, types, pagination tokens) is not declared. LLMs cannot plan downstream calls or extract relevant fields without guessing at the response format.
Descriptions are too brief (10-50 chars). Current descriptions lack context on WHEN to use each tool vs similar ones, WHAT the output contains, and ANY prerequisites. Examples: 'Find orders by number or list recent ones' (52 chars) does not explain pagination behavior or when to use search-orders vs list-orders.
No error handling guidance. Tools declare no error responses or recovery steps. If search-product-number finds no match, should the LLM try search-products-by-term? If get-stock-level times out, is it retryable? Without error classifications (retryable, user-fixable, fatal), agents cannot plan recovery.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Parameter constraints underspecified. limit and page parameters accept numbers but descriptions say 'minimum 1' without upper bounds or explaining pagination semantics. Are results 0-indexed? Does page=2 with limit=10 return items 10-19 or 11-20? Ambiguity invites LLM errors.
No output field naming consistency documentation. If search-orders returns 'orderId', but search-product-number returns 'productId', downstream tools must handle both naming conventions. If a tool chain requires passing an order ID to another tool, it must be clear which field in the response contains it.