Tools for managing a Django e-commerce backend (chatram.in). Authentication: the user's JWT token is automatically read from the Authorization: Bearer <token> header sent by the frontend chatbot. Public tools (no login needed): list_products, get_product, search_products, list_categories, list_brands, ask_question. All write operations and user-specific reads (cart, orders, wishlist, addresses, reviews) require the user to be logged in.
35 tools with complete schemas and descriptions, but quality is uneven. Most tools have adequate naming (verb_noun pattern) and parameter descriptions, but many descriptions are generic or lack actionable context. Output schemas are not documented. Error handling is minimal, no recovery guidance or categorization. Parameter constraints (enums, ranges) are sparse. No tool annotations (readOnlyHint, destructiveHint). Descriptions average ~80 chars, below the 194-char baseline for A+ tools. Missing dependency hints and multi-step guidance.
Add a product to the cart (or increase quantity if already present).
Add a product to the authenticated user's wishlist.
Adjust stock for a product by `delta` units. Positive delta = restock, negative = deduct. `reason` is an optional note (e.g. 'manual correction', 'damaged goods').
Post or update the seller's answer to a customer question.
Post a customer question about a product.
Save a new delivery/billing address for the authenticated user.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., product_id from search_products for use in get_product). Responses are opaque.
Destructive tools (delete_product, delete_review, remove_from_cart, remove_from_wishlist) lack confirmation/dry-run support and have minimal descriptions. No recovery guidance if called in error.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes without reading full descriptions. Increases misuse risk.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
Create a new product category.
Place a new order.
Record a payment method for an order.
Create a new product listing.
Post a review for a product.
Delete a product by its ID.
Delete the authenticated user's review for a product.
Return all items in the authenticated user's cart.
Fetch full details of a single product.
Generate a pre-signed AWS S3 URL to upload a product image or video (Step 1/2).
Retrieve a specific customer Q&A entry (Seller view — sees only their own products' questions).
Return current stock level for a given product.
Return all products in the authenticated user's wishlist.
Return all saved addresses for the authenticated user.
Return all brands.
Return all product categories.
List all products whose stock level is at or below the given threshold.
Return all orders placed by the authenticated user.
Return all payment records.
Return all active products.
Remove a specific item from the cart entirely.
Remove a product from the authenticated user's wishlist.
Persist a product image/video URL after front-end has uploaded it to S3 (Step 2/2).
Search products using one or more optional filters.
Set the absolute stock quantity for a product (useful after a physical stock-take).
Partially update the authenticated user's address.
Update the quantity of an existing cart item. Pass quantity < 0 to remove the item entirely.
Partially update an existing product.
Update the authenticated user's existing review for a product.
Parameter constraints are sparse. No enums for status/type fields (e.g., address_type accepts 'shipping'|'billing'|'both' but is free-form string). No min/max for numeric params (quantity, threshold, delta). LLMs will hallucinate invalid values.
Error handling is absent. No recovery guidance, categorization (retryable vs fatal), or actionable error messages. If a tool fails, the LLM has no direction on what to do next.