Loading ToolBench
MCP server for Fake Store API - A beginner-friendly e-commerce data integration
The server defines 18 tools with consistent naming, clear descriptions, and proper input schemas. Naming follows the verb_noun pattern (get_, add_, update_, delete_) which is aligned with production baselines. All tools have descriptions in the 30-100 character range. Input schemas are present with proper JSON Schema structure including types, required fields, and parameter descriptions. However, there are significant gaps: (1) Output schemas are NOT documented, no schema definitions for what these tools return, making it impossible for LLMs to reason about result structure; (2) No pagination support despite tools like fakestore_get_products and fakestore_get_carts returning potentially large lists; (3) Error handling is minimal, the catch block returns generic error messages without recovery guidance; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications (READ_ONLY, WRITE, DESTRUCTIVE); (5) Parameter descriptions lack constraints (ranges, formats, examples for validation); (6) The add_user tool requires 12 parameters, many with insufficient context (what format for 'lat'/'long'? are they strings or numbers?). These gaps place the server in the 'fair' range, with room for structural improvements.
Add a new cart (simulation - does not persist)
Add a new product to the store (simulation - does not persist)
Add a new user (simulation - does not persist)
Delete a cart (simulation - does not persist)
Delete a product (simulation - does not persist)
Delete a user (simulation - does not persist)
Get a single cart by its ID
Output schemas are completely undocumented. No schema definitions provided for tool return types, making it impossible for LLMs to reason about result structure, parse nested fields, or plan downstream tool calls. Baselines show 100% of A+ tools have documented return types.
No tool annotations despite clear risk classifications. Tools marked DESTRUCTIVE (delete_*), WRITE (add_*, update_*), and READ_ONLY should use MCP tool annotations (destructiveHint, idempotentHint, readOnlyHint) to signal operation safety to agents. This prevents accidental data loss and helps agents understand retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Get all carts from the store. Optionally limit results and sort.
Get all available product categories
Get a single product by its ID
Get all products from the store. Optionally limit results and sort by price.
Get all products in a specific category
Get a single user by their ID
Get all carts belonging to a specific user
Get all users from the store. Optionally limit results and sort.
Update an existing cart (simulation - does not persist)
Update an existing product (simulation - does not persist)
Update an existing user (simulation - does not persist)
No pagination support for list tools. fakestore_get_products, fakestore_get_carts, and fakestore_get_users accept limit parameters but do not return total counts, next_cursor, or offset for continuation. Large result sets will exceed context windows. Best practice: return {items: [...], total: N, next_cursor?: string}.
Error handling lacks recovery guidance. The generic catch block returns 'Error: <message>' without indicating whether the error is retryable, user-fixable, or fatal. No suggestions for corrective actions (e.g., 'Try search_users() if ID is unknown'). This violates the recovery-guide pattern.
fakestore_add_user requires 12 parameters with insufficient format/constraint documentation. Parameters 'lat' and 'long' are typed as strings but are unclear (decimal degrees? Format?). 'zipcode' and 'phone' lack regex patterns or length constraints. LLMs will guess and send invalid values.
Parameter descriptions lack actionable constraints. For example, 'limit' in fakestore_get_products and fakestore_get_carts should specify: 'Limit the number of results (1-100, default 20).' Current descriptions are generic and invite out-of-range values. Numeric parameters need min/max bounds.
No idempotency guidance. Tools like fakestore_add_product, fakestore_add_cart, and fakestore_add_user lack idempotency keys or documentation about idempotent behavior. Agents retrying failed calls risk creating duplicate records. Consider accepting an optional 'idempotency_key' parameter.
Descriptions for all tools note 'does not persist' for WRITE/DESTRUCTIVE operations (add_*, update_*, delete_*), which is helpful for testing context but does not address that agents need to understand these are side-effecting. Descriptions should explicitly state 'This modifies the store' or 'This deletes data' to clarify operation semantics.