Loading ToolBench
Model Context Protocol server for Domino's Pizza API integration
The server defines 10 tools with explicit Zod schemas and basic descriptions. All tools are clearly registered in src/actions/index.js with schema validation. However, descriptions are universally terse (8-29 characters), parameter descriptions lack actionable detail, and several tools expose sensitive payment data as parameters. The schema validation is present but parameter-level descriptions are minimal or missing context. Output schemas are not documented. Error handling and recovery guidance are absent from the tool definitions.
Add an item to an existing order
Create a new pizza order
Find Domino's Pizza stores near an address
Get the menu for a specific Domino's store
Get the current state of an order from the session
Place an order with payment information
Price an order to get total cost
Descriptions are all under 30 characters, well below the 194-character baseline for production tools. LLMs cannot determine when/why to use each tool. Rule hard-cap: descriptions under 20 chars score ≤40. Examples: 'Get the menu for a specific Domino's store' (45 chars) is marginally acceptable; 'Get the current state of an order from the session' (50 chars) lacks WHEN to use it.
placeOrder exposes cardNumber, expiration, and securityCode as optional input parameters. Secrets must never appear as tool parameters, they leak into agent logs and traces. Implement server-side payment token injection instead of exposing raw card data.
No output schemas documented. The code returns JSON stringified results wrapped in {content:[{type:'text',text:...}]}, but LLMs cannot see the inner JSON structure. Document return types for each tool (e.g., 'Returns object with fields: storeId, distance, address, phone') so agents can extract fields for downstream tool calls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Remove an item from an existing order
Track the status of an order
Validate an order before placing it
No error handling or recovery guidance in tool definitions. When a tool fails (invalid address, store not found, payment declined), agents receive no actionable error message. Add descriptions like 'If order validation fails, check that items exist via getMenu() or re-check customer address format.'
placeOrder and createOrder accept optional parameters (cardNumber, expiration, securityCode, address fields) without clear logic on when each is required. The description states 'Required for delivery orders' for address, but the schema makes address fields optional in Zod (.optional()). LLMs will pass incomplete data leading to runtime failures.
addItemToOrder's 'options' parameter accepts {code: {portion: quantity}} format as free-form z.record(z.any()). This complex custom format is documented in the param description but not enforced by schema. LLMs will hallucinate invalid structures like {P: 'extra'} or {P: {1/2: 'double'}}. Use an enum or structured schema to constrain valid portion/quantity values.
Parameter descriptions lack actionable guidance. Examples: 'ID of the store to order from' (no format), 'Phone number used for the order' (format?), 'ID of the order to place' (where does this come from?). Descriptions should explain prerequisite tools and dependencies.
No idempotency or confirmation step for irreversible operations. placeOrder permanently charges a card and creates an order, no dry-run, no confirmation, no undo tool. Agents could invoke this unintentionally. Add a dry_run parameter or confirmation_token pattern.
createOrder combines multiple concerns: order initialization, customer data collection, and address validation. When customer address is invalid, agents cannot separately correct the address and retry, the entire createOrder fails. Consider splitting into createOrder + validateCustomerAddress or provide a separate updateOrderAddress tool.