WaitApp

Draft a scheduled pre-order

draft_preorder

Drafts a pre-order for a time slot, for PICKUP (default) or courier DELIVERY (method: delivery, with deliveryAddress or savedLocationId; the slot must offer delivery and the venue must deliver, and the delivery fee is paid to the rider on delivery). Nothing is placed or reserved: it checks the slot against the items (lead time, capacity, items sold that day), prices the order with choices, and returns the summary: slot and ready time, items, total, what is due now and what on collection. The slot comes from list_preorder_slots (slotInstanceId). Returns a draftId for place_preorder. Requires the connected WaitApp account. payment: on_collection (default; the guest pays the venue when collecting) or online (the amount due now is paid by the guest on WaitApp's payment page after the order is placed; the assistant sends and approves no payment); some venues require online. guestPhone is required: the guest and venue use it to find the order. One slot per order.

Input Schema

Name	Required	Description	Default
`items`	Yes
`method`	No		pickup
`payment`	No
`guestName`	Yes	Who collects, or receives, the order
`guestPhone`	Yes
`restaurantId`	Yes
`slotInstanceId`	Yes	From list_preorder_slots
`deliveryAddress`	No	For delivery: the full address. Not needed when savedLocationId is given
`savedLocationId`	No	For delivery: one of the person's saved locations (see list_saved_locations)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

removedInput schema / properties / mobileMoneyNumber

Removed value: -{
-  "description": "Required for mobile_money: the guest's own mobile money number",
-  "type": "string"
-}

changedInput schema / properties / payment / enum

Previous value: -[
-  "on_collection",
-  "mobile_money"
-]New value: +[
+  "on_collection",
+  "online",
+  "mobile_money"
+]

AddedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite terse annotations, the description discloses substantial behavior: nothing is placed or reserved, the slot is validated against lead time/capacity/items-sold-today, the order is priced, delivery fees are paid to the rider, a connected WaitApp account is required, and the assistant sends/approves no payment. That is rich context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and keeps every clause informative, but it is a single dense paragraph with layered parentheses that is harder to scan than a short bulleted structure would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-output-schema tool, it covers inputs, prerequisites, validation behavior, pricing, payment flow, and the return payload (slot/ready time, items, total, due-now vs on-collection, draftId) – nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 44%, the description compensates well: it explains method defaults and delivery requirements (deliveryAddress or savedLocationId), payment defaults and mechanics, why guestPhone is required, and where slotInstanceId comes from. It omits the mobile_money payment option that the schema enum exposes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise verb+resource ('Drafts a pre-order for a time slot') and immediately scopes it against the placing step ('Nothing is placed or reserved', 'Returns a draftId for place_preorder'), which separates it cleanly from place_preorder and draft_delivery_order.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: the slot must come from list_preorder_slots (slotInstanceId) and the result feeds place_preorder, plus when delivery applies and when online payment is required. It does not explicitly state when to prefer this over draft_delivery_order, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All WaitApp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?