Loading ToolBench
Server has 5 tools with reasonable naming convention (all start with 'cscart_get' or 'cscart_search'). Descriptions are present for all tools and range 34-194 characters, within acceptable bounds. Input schemas are visible and use Zod with proper JSON Schema conversion. However, several critical gaps reduce overall quality: (1) Most parameter descriptions are minimal or missing context on when to use alternate tools; (2) No output schemas documented, LLMs don't know the structure of returned data; (3) No pagination parameters on list tools (get_products, get_features) despite potentially large result sets; (4) Error handling is basic (generic 'Error: {message}' responses with no guidance on recovery); (5) No tool annotations (readOnlyHint, idempotentHint) to signal safety; (6) searchProducts has both name and code as optional, creating ambiguity when both are omitted. Average parameter count is low (1-2 per tool), but lack of pagination and filtering controls is a limitation for scalability.
Fetch all CS-Cart product features. Returns array of features with variants (if present). Feature is a product attribute.
Fetch a CS-Cart order by its ID. Returns the order object as provided by CS-Cart API.
Fetch a CS-Cart product by its ID. CS-Cart is a shop. Returns product with all features and variants. Product fields in cscart located at `product_features`, key should match with parser field.
Fetch all CS-Cart products.
Search CS-Cart products by name (product) and code (product_code). Returns array of products, without features. Use cscart_get_product to get full product data with features.
No output schemas documented. LLMs cannot know what fields to expect from tools like cscart_get_product, cscart_get_products, or cscart_get_features. Without output schema, agents cannot plan chained calls or extract required IDs for subsequent operations.
No pagination or limit parameters on list tools. cscart_get_products and cscart_get_features return entire result sets with no way to paginate or cap results. Large result sets bloat the context window and degrade LLM reasoning.
Error handling is generic and non-actionable. Catch-all error response 'Error: {message}' provides no guidance on retry eligibility, next steps, or how to self-correct. LLMs receive no recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
cscart_search_products has both 'name' and 'code' as optional parameters with no documented behavior when both are absent. This creates ambiguity: does it return all products, or require at least one filter? Undocumented parameter relationships cause silent misuse.
No tool annotations present. Tools are read-only but lack readOnlyHint or idempotentHint annotations to signal safety to agents. Agents cannot determine retry safety without this metadata.
Parameter descriptions lack guidance on formats and constraints. For example, productId and orderId lack range documentation ('must be a positive integer' is implicit from the schema but not stated in description text). JSON Schema constraints are not human-readable to LLMs.
cscart_get_products and cscart_get_features have no parameter descriptions to explain their purpose, when to call them, or expected result sizes. Minimal parameter documentation makes the tool less discoverable.