Thmenu

Create a cart

create_cart

Build an anonymous takeaway or delivery cart for a listed restaurant and get a one-time confirmation link for the guest. PUBLIC tool, no auth. Table orders are not supported here (they stay on the QR menu). Options (size, doneness, extras …): get_restaurant_menu lists each dish's option_groups; send the chosen option ids per line as items[].modifier_option_ids — the quote adds each option's price_delta and the confirmation page orders the same choice. 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 refuses the cart and nothing is created: modifier_required (a required group left empty), modifier_too_many, modifier_unknown_option (an id the dish does not offer), or invalid_input with detail.reason modifier_malformed (not a list of option ids); the error detail names the product_id and group_id. The same dish with different options goes on separate lines. Send the guest to confirm_url. Prices are re-read there from the live menu; name, phone, delivery address and payment are entered by the guest on that page — never through this tool. Nothing is ordered until the guest confirms. The link expires 30 minutes after creation and can be used once.

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": {
      "restaurant": "<restaurant>",
      "order_type": "<order_type>",
      "items": "<items>"
    },
    "name": "create_cart"
  }
}

Input Schema

Name	Required	Description
`note`	No	Order-level note for the kitchen. Do not put the guest's name, phone or address here.
`items`	Yes
`order_type`	Yes
`restaurant`	Yes	Restaurant slug (from search_restaurants / list_public_menus) or id.
`scheduled_for`	No	ISO date-time for a scheduled pickup/delivery (optional; the venue may refuse on the confirmation page).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

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 guest chose no option.",
+  "items": {
+    "maxLength": 128,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

First observedOct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations, it discloses the public/no-auth posture, that the link expires after 30 minutes and is single-use (reinforcing why idempotentHint is false), that prices are re-read live at confirmation, and critically that a modifier validation failure creates nothing at all, with the exact error codes returned. It also draws a hard data boundary: name, phone, address and payment must be entered on the confirmation page, never through this tool.

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?

Purpose and the confirm-link flow are front-loaded, and most sentences carry operational weight. It is nonetheless a dense, semicolon-chained block, and the enumerated error-code list (modifier_required, modifier_too_many, modifier_unknown_option, modifier_malformed) is bulky relative to the rest.

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 non-idempotent mutation with no output schema, it covers everything an agent needs: auth model, atomicity of failures, the confirm_url handoff, link lifetime and single use, price source, and which sensitive fields must never be passed. No return-format explanation is needed since the confirmation page is the consumer.

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?

At 60% schema coverage, the description compensates substantially: it explains how items[].modifier_option_ids must be assembled (flat ids from the dish's option_groups), that each option's price_delta is applied to the quote, and that the same dish with different options must go on separate lines. It also adds option-group validation rules (max(1, min_select) for required groups, max_select cap) that the schema only gestures at with 'Required groups must be filled'.

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 verb and resource: 'Build an anonymous takeaway or delivery cart for a listed restaurant' and states the output, a 'one-time confirmation link'. It immediately excludes a scope ('Table orders are not supported here') and distinguishes itself from the ordering step ('Nothing is ordered until the guest confirms'), which separates it from place_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?

It gives an explicit prerequisite flow (call get_restaurant_menu for option_groups, send the guest to confirm_url) and an exclusion (table orders stay on the QR menu). What it does not do is name the sibling that converts a cart into an order (place_order) or the one that retrieves it (get_cart), leaving the agent to infer the next step in the chain.

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

All Thmenu 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?