Loading ToolBench
A Next.js-based AI shopping assistant for Kapruka (Sri Lankan e-commerce platform) that integrates with MCP tools for product search, delivery checking, order management, and customer account operations.
Kapruka Agent demonstrates solid tool design with clear naming conventions (verb_noun pattern), comprehensive parameter schemas using Zod, and well-structured descriptions. All 10 tools have explicit descriptions and input schemas with typed parameters. However, output schemas are not documented in the source code, and error handling guidance is absent. Descriptions are generally strong (100-200 chars) but lack explicit recovery hints for failure cases. Parameter descriptions are present and specific, with good use of enums for constrained inputs (currency, sort order, location_type). The create_order tool shows sophisticated composition with nested objects. Missing: documented return types, error classification, and actionable error messages.
Check if Kapruka can deliver to a city on a given date, and get the delivery fee in LKR. Call PROACTIVELY — if the user mentions a city alongside a product, check delivery without being asked. Can be called in PARALLEL with search_products.
Create a guest checkout order on Kapruka and return a payment URL. Call ONLY after collecting all required fields: recipient name, phone, delivery address, city, and date.
Get the signed-in customer's full saved address book — beyond what's already summarized in your account context. Use when you need more than the 5 addresses already shown to you, or to double-check an exact saved address before checkout. Always looks up the current signed-in customer, nobody else.
Refresh or double-check the signed-in customer's own profile details (name, phone, email) — beyond what's already summarized in your account context. Use for questions like 'what's my phone number on file' or if the account context looks stale. No parameters take an email — this always looks up the current signed-in customer, nobody else.
Get the signed-in customer's past orders — beyond what's already summarized in your account context. Use for questions like 'what did I order last month' or when you need more than the 5 most recent orders already shown to you. No parameters take an email — this always looks up the current signed-in customer, nobody else.
Output schemas not documented. Tools return data but LLM cannot plan downstream calls without knowing response structure (e.g., search_products returns product IDs, prices, stock, but this is inferred, not explicit).
No error handling guidance. Tools lack recovery hints (e.g., 'If product not found, try search_products()' or 'If delivery unavailable, suggest alternative cities'). LLM cannot self-correct on failures.
create_order lacks confirmation/dry-run pattern. This is a destructive, irreversible operation (payment + order creation) but has no pre-execution validation step. Agents can accidentally create duplicate orders.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Get full details for a specific Kapruka product by its ID: description, variants, images, stock level, and shipping info.
List all Kapruka product categories. Use when the user wants to browse by category rather than search by keyword.
Search Kapruka delivery cities by partial name. Use to confirm a city is deliverable and get its canonical name before checking delivery rates.
Search the Kapruka catalogue for any product — gifts, groceries, electronics, fashion, home essentials, and more. Call in PARALLEL for multiple categories (e.g. search 'flowers' AND 'chocolate' simultaneously when user is undecided). Translate Sinhala/Tanglish queries to English before searching. Use short 1-2 word queries only.
Track the delivery status of a Kapruka order by its order number (from the confirmation email, e.g. VIMP34456CB2). Do not use the order reference from checkout.
Pagination not fully specified. search_products accepts 'cursor' but no documentation of cursor format, whether it's opaque, or how to detect end-of-results. Agents cannot reliably paginate large result sets.
get_customer_addresses and get_customer_details accept no parameters but descriptions claim they 'look up the current signed-in customer'. No documentation of how authentication/session context is passed to the server.