Servd Agentic Ordering

Place confirmed restaurant order

place_order

DestructiveIdempotent

Create a REAL restaurant order only after showing the latest validate_cart result and receiving explicit diner confirmation. A venue explicitly marked agentOrdering.sandbox instead returns a no-charge, no-kitchen simulation with sandbox=true and createsProductionOrder=false. Pass that result’s confirmation.token so the server can prove the cart and live quote did not change. The server recalculates all prices. Use a unique idempotency key, show orderNumber and the labeled customerLinks, and poll check_order for payment and fulfillment status. Unpaid online orders expire after 30 minutes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	The venue slug returned by find_venues.
`items`	No
`combos`	No
`customer`	Yes	The diner’s minimum contact details required by the venue.
`delivery`	No	For delivery, street is required and coordinates may be needed for fees/radius.
`confirmed`	Yes	Set true only after the diner explicitly confirms the latest validate_cart result.
`tip_amount`	No	Major currency units.
`fulfillment`	Yes
`payment_method`	No		online
`idempotency_key`	Yes	Use validate_cart.confirmation.idempotencyKey exactly; reuse it for retries of this confirmed order.
`confirmation_token`	Yes	The short-lived confirmation.token from the exact validate_cart result shown to the diner.

Output Schema

TableJSON Schema

Name	Required	Description
`message`	Yes
`orderId`	Yes	Machine-facing private id for check_order.
`sandbox`	Yes
`trackUrl`	Yes
`expiresAt`	Yes
`statusUrl`	Yes
`friendlyId`	Yes
`paymentUrl`	Yes
`checkoutUrl`	Yes
`orderNumber`	Yes	Customer-facing order number.
`paymentMode`	Yes
`trackingUrl`	Yes
`paymentError`	Yes
`customerLinks`	Yes
`paymentProvider`	Yes
`paymentRequired`	Yes
`createsProductionOrder`	Yes	False for reviewer sandbox receipts. True only when a production order was created.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark this as non-read-only, idempotent, and potentially destructive, and the description adds meaningful context: server-side price recalculation, no-charge sandbox behavior, 30-minute expiration for unpaid online orders, and the need to surface orderNumber and customerLinks. There is no contradiction with the annotations.

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

Conciseness5/5

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

Every sentence carries essential operational information, and the most important instruction is front-loaded: only place the order after showing latest validation and receiving confirmation. Though dense, it is not wasteful and earns its length given the tool's side effects.

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 high-stakes order-placement tool with 11 parameters, nested objects, idempotency requirements, and real-world consequences, the description covers preconditions, sandbox behavior, token validity, price recalculation, result display, polling, and expiration. An agent has enough context to invoke it correctly and safely.

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?

Schema coverage is moderate at 64%, so the description must add value for the critical parameters. It explains why confirmation_token and idempotency_key matter, clarifies that prices are server-recalculated, and describes sandbox implications. Some parameters like fulfillment and payment_method are left to the schema, but the key workflow-critical semantics are covered.

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?

The description opens with a specific, unambiguous action — 'Create a REAL restaurant order' — and clearly differentiates this from validation/checking by naming validate_cart and check_order. The term 'REAL' signals that this is the side-effecting placement step, distinct from cart validation.

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

Usage Guidelines5/5

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

The description gives explicit preconditions: show the latest validate_cart result, obtain explicit diner confirmation, and pass the confirmation token. It also describes the sandbox simulation alternative and explicitly instructs polling check_order afterward, giving the agent a complete workflow.

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

All Servd Agentic Ordering tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct step in the ordering workflow: venue discovery, venue details, menu retrieval, cart validation, order placement, and order status checking. Even find_venues and get_venue are clearly separated by list/search versus single-venue detail.

Naming Consistency5/5

All tool names follow a consistent lowercase verb_noun pattern: find_venues, get_venue, get_menu, validate_cart, place_order, check_order. The verbs are distinct yet predictable, and there is no mixing of casing or naming styles.

Tool Count5/5

Six tools is well-scoped for an agentic ordering server. Each tool supports a necessary phase of the ordering flow without redundancy or unnecessary bulk.

Completeness4/5

The core ordering lifecycle is covered: discover venues, inspect venue details, fetch menus, validate carts, place orders, and poll order status. The main gap is the lack of a cancel_order or update_order tool, so order management after placement is limited.

Resources

Need Help?