Loading ToolBench
A storefront you can shop entirely by voice. Read the `speech` field aloud as written; it is already shaped for listening. Render `cards` only when the device has a screen.
VoiceCart demonstrates solid tool design with clear, conversational descriptions optimized for voice interaction. All 12 tools have descriptions (avg 156 chars) and input schemas with typed parameters. Naming follows verb_noun convention (list_, browse_, search_, describe_, add_, remove_, read_, review_, place_, order_status, reorder_). However, several tools lack complete parameter descriptions, and output schemas are not formally documented. Error handling is present but could be more prescriptive. The voice-first design is thoughtful, descriptions read naturally aloud, but some parameter constraints (e.g., valid category names, SKU format) are undocumented.
Put an item in the basket. Quantity is clamped to what is in stock. `item` is whatever they said: a SKU, a position in the list you just read out ("the second one"), or a name ("the honey"). When a phrase could mean more than one product, nothing is added and the reply asks which.
Read out the products in one department, three at a time. Pass the offset returned by the previous call to hear the next three.
Everything about one product, for when the shopper asks to hear more. `item` is whatever they said: a SKU, a position in the list you just read out ("the second one"), or a name ("the honey").
List the departments in the shop.
Where is the order?
Put the order through. Asks the shopper to confirm unless they already have.
Output schemas not formally documented. Tools return VoiceReply objects with fields like 'speech', 'cards', 'ok', but the structure is not declared in tool definitions. LLMs cannot plan downstream calls or extract structured data without knowing the response shape.
Parameter constraints undocumented. 'category' param in browse_category lacks enum of valid categories. 'item' param accepts SKU, position, or name but no format guidance. 'offset' and 'quantity' lack min/max bounds. LLMs will pass invalid values without explicit constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
What is in the basket right now.
Take an item back out of the basket. `item` is whatever they said. "Take out the second one" resolves against the basket as it was just read, not against the shop.
Order the usual again.
Take back what the shopper says was wrong. Pass their correction word for word: "no, not that one", "take the last one back", "start again", "no, take the rice out". Speech corrects itself constantly, and a listener who cannot see the basket has no way to check what went in, so this is the one tool that walks the shop backwards. "Not that one" does two things: it undoes the change, and it stops the shop offering that product again for the same words.
Read back what will be ordered, so the shopper can hear it before they commit.
Find products by what the shopper called them, three at a time.
'repair' tool name is vague. Does it repair a product, a cart, or an order? The description clarifies it undoes mistakes, but the name alone does not convey 'undo_last_action' or 'correct_mistake'. Ambiguous naming increases LLM selection errors.
Error handling lacks recovery guidance. Tools return 'ok=False' with a speech message, but do not tell the LLM what to do next. E.g., 'There is no X section' should suggest 'Call list_categories() to see available departments.'
Irreversible operations (place_order) lack explicit confirmation pattern. The tool asks for confirmation via elicitation, but if elicitation fails, it falls back to asking the assistant to confirm in its own words. A dry-run or explicit confirmation step would prevent accidental orders.