Loading ToolBench
AI ordering agent for DoorDash. Lets Claude order food on DoorDash — search, compare real fee-included totals, build carts, and place orders behind a human approval dialog.
Peckish demonstrates solid tool definition quality with 19 well-structured tools covering a complete DoorDash ordering workflow. All tools have descriptions (average ~140 chars), named with clear action verbs (list_, get_, search_, add_, remove_, set_, delete_, apply_, submit_), and comprehensive input schemas with typed parameters. Strengths: consistent naming conventions, complete parameter descriptions, logical grouping by concern (addresses, search, menu, cart, ordering, preferences). Weaknesses: output schemas are not explicitly documented in the source (only input schemas visible), no per-tool error handling guidance visible in the code provided, and descriptions could be more action-oriented (some are feature-focused rather than intent-focused). Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, IRREVERSIBLE) are well-applied and improve clarity. The server shows good composition discipline, tools chain naturally (search → get_menu → add_to_cart → preview → submit) and accept human-friendly identifiers (e.g., printable_address for confirmation, not just IDs).
Add items to a cart or create a new cart. Supports modifiers, special instructions, fulfillment modes, and spend limits.
Save a dietary, budget, or ordering preference that persists across sessions. Preferences are sent to Claude on each turn to guide ordering.
Apply a promotional code to a cart.
Delete an entire cart.
Retrieve the full menu for a restaurant. Supports filtering by name, description, or category. Returns up to 160 items per call.
List available promotions and discounts for a store or cart. Shows code, description, value, and applicability.
Output schemas not documented in visible source code. While input schemas are comprehensive, the return types for each tool are not explicitly declared in JSON Schema format. This forces LLMs to infer output structure from descriptions alone, increasing error likelihood when chaining tools.
Descriptions for READ-ONLY tools (show_cart, list_carts, get_promos, list_preferences) are notably brief (60-80 chars) compared to action-oriented tools. These discovery tools should explain when to call them and what structure they reveal to guide LLM planning.
Error handling strategy not visible in tool definitions. Code shows confirmOrderPlacement() gate for submit_order, but no documented error responses (e.g., 'Item unavailable', 'Store closed', 'Invalid promo code'). LLMs cannot self-correct without explicit recovery guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
Get detailed information about a specific menu item including modifiers, availability, pricing variations, and nutritional info.
Load the user's ordering context: default delivery address, saved dietary/budget preferences, and current local time.
Get detailed information about a store including hours, location, policies, and capabilities.
List delivery addresses on the user's DoorDash account.
List all open carts, optionally filtered by store.
List all saved dietary and ordering preferences.
Generate a detailed order preview/quote with itemized costs, fees, delivery times, and suggested tips. Does NOT submit the order.
Remove a single item from a cart.
Delete a saved preference.
Search for restaurants on DoorDash by query and location. Returns store listings with distance, delivery time, and rating.
Set the user's account-wide default delivery address. Requires explicit user confirmation.
Retrieve the full contents and status of a cart.
Submit an order for placement. Requires explicit user confirmation via terminal/UI dialog before execution. Returns order confirmation with order ID, ETA, and receipt.
Parameter constraint documentation could be stricter. For example, 'limit' in search_restaurants defaults to 8 but no min/max bounds are stated. 'scheduled_time' accepts ISO8601 but should clarify valid range (future only, timezone handling, etc.). MENU_ITEM_CAP constant (160) is not surfaced in tool descriptions.
Interdependency between tools not fully documented. For example, add_items_to_cart requires store_id + menu_id + item_id, but the tool descriptions don't state 'call search_restaurants first, then get_menu to discover valid IDs.' This forces LLMs to infer the workflow.