Skip to main content
Glama

Place an order

place_order
Idempotent

Place an order against the agent_session_id from start_order_session. Atomically inserts the order + items, applies server-side canonical pricing + tax (do NOT trust the unit_price you compute — we re-read it from D1), decrements inventory and optionally redeems a promo code. The guest pays at the venue (payment_status 'unpaid'). At a venue that takes payment before preparing (pay_first: true) the order is held as 'awaiting' and payment_url is returned: give it to the guest — they pay on the restaurant's own checkout, exactly like a guest ordering from the table; the kitchen gets the order once it is paid, and an unpaid order expires. This tool never charges anything itself. Options (size, doneness, extras …): get_restaurant_menu lists each dish's option_groups; send the chosen option ids per line as modifier_option_ids — each option's price_delta is added to the dish price on the server. A group with required: true needs at least max(1, min_select) of its options and no group takes more than max_select. A line that breaks this is refused and nothing is ordered: modifier_required (a required group left empty), modifier_too_many, modifier_unknown_option (an id the dish does not offer), modifier_malformed (not a list of option ids); the error data names the product_id and group_id. Ask the guest, or leave that dish out. Returns order_id, total_cents (tax-inclusive), currency, promo_discount and, when pay_first, payment_url. Idempotency-Key header REQUIRED.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent_session_id": "<agent_session_id>",
      "items": "<items>"
    },
    "name": "place_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoOptional order-level note (max 500 chars).
itemsYes
table_idNoOptional table id when ordering at a table.
guest_nameNoOptional guest name shown to staff with the order.
order_typeNoChannel: 'dine_in' (default — at a table) or 'takeaway' (pickup; requires customer_name + customer_phone, ignores table_id, only when the restaurant has takeaway enabled — else channel_not_available). Delivery is not offered to agents.
promo_codeNoOptional promo code to redeem at order time (validate first with apply_promo). The redemption slot is consumed only when this order lands.
customer_nameNoRequired for takeaway — who picks the order up.
customer_phoneNoRequired for takeaway — reachable phone (digits, +, spaces/dashes tolerated).
agent_session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / items / items / properties / modifier_option_ids
      Added value: +{
      +  "description": "Chosen option ids for this line, from the dish's option_groups in get_restaurant_menu (all groups flat). Required groups must be filled; omit when the dish has no option the guest chose.",
      +  "items": {
      +    "maxLength": 128,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 50,
      +  "type": "array"
      +}
  2. Changed3 schema fields changed
    • changedInput schema / properties / guest_name / description
      Previous value: -"Required when room_id is set."New value: +"Optional guest name shown to staff with the order."
    • changedInput schema / properties / order_type / description
      Previous value: -"Channel: 'dine_in' (default — table or room) or 'takeaway' (pickup; requires customer_name + customer_phone, ignores table_id/room_id, only when the restaurant has takeaway enabled — else channel_not_available). Delivery is not offered to agents."New value: +"Channel: 'dine_in' (default — at a table) or 'takeaway' (pickup; requires customer_name + customer_phone, ignores table_id, only when the restaurant has takeaway enabled — else channel_not_available). Delivery is not offered to agents."
    • removedInput schema / properties / room_id
      Removed value: -{
      -  "description": "Hotel room id (room service): an active room of this venue. Not with table_id; guest_name is required.",
      -  "type": "string"
      -}
  3. Changed1 schema field changed
    • changedInput schema / properties / room_id / description
      Previous value: -"Diamond tier only — hotel room id."New value: +"Hotel room id (room service): an active room of this venue. Not with table_id; guest_name is required."
  4. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses atomic insertion, server-side canonical pricing and tax recalculation, inventory decrement, promo redemption timing, and that the tool itself never charges. It also explains pay_first hold semantics, unpaid-order expiry, option validation errors, and the required Idempotency-Key header.

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?

Although long, the description is front-loaded with the core action and sequenced into pricing, payment, options, errors, returns, and idempotency. Each sentence carries operational meaning for a complex mutation tool, and no significant filler is present.

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 complex, non-readonly ordering tool with nine parameters and no output schema, the description supplies the missing return information, payment flow, error codes, and idempotency requirement. An agent has enough context to call the tool correctly without relying on undocumented assumptions.

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

Parameters5/5

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

The schema already covers 78% of parameters, but the description adds important semantics: order_type behavior for takeaway, customer_name/customer_phone requirements, promo redemption slot timing, and the fact that modifier_option_ids must select from the dish's option_groups. It also documents server-side price_delta application and validation failure modes not evident from the schema alone.

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 states a specific verb and resource: place an order against an agent_session_id from start_order_session. It clearly distinguishes itself from session-starting, menu inspection, promo validation, and cancellation siblings, so an agent can identify its role immediately.

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?

It explicitly directs the agent to obtain agent_session_id from start_order_session and option ids from get_restaurant_menu, and to validate promo codes with apply_promo first. It also explains when payment_url appears and how pay_first venues behave, giving clear when-and-how guidance rather than leaving workflow to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources