Skip to content

Assistants and agent tools

Every published venue exposes a read-only MCP server at its own /mcp path, with no login and no session — a visitor’s own AI assistant can connect straight to it. It carries six tools:

  • get_venue_info — name, whether it’s open now, hours, address, contact and Wi-Fi, and the reserve/pickup/delivery links.
  • get_menu — the full published menu for a context (dine-in, pickup or delivery), sections and items, prices, calories, badges and live offers.
  • search_items — items matching a word, with allergen exclusions, dietary requirements and price/calorie caps.
  • get_item — one item by id, with its section.
  • check_allergens — a per-item, per-allergen safety verdict (below).
  • find_items — a deterministic filtered and sorted list, by price, calories or name.

Search and find results are capped at 50 items each, and every call is read-only — an assistant can look, never write.

{slug}.qaema.ai/llms.txt is the whole published menu as plain markdown — every section and item, prices, calories, allergens, dietary tags and sold-out state — readable in a single fetch, for an assistant that doesn’t speak MCP. /.well-known/mcp is a small discovery document naming the venue’s MCP server, its URL and its transport, for an assistant that looks there first.

Every menu page also carries schema.org structured data — Restaurant, its menu sections and each item with its price, calories and any diets it suits — so a general-purpose search or shopping assistant can read it directly from the page, without calling any tool at all.

check_allergens never guesses: an item comes back unsafe when a requested allergen is declared on it or listed as a may-contain risk, safe only when you’ve attested something about that item and none of it matches, and unknown when nothing has been attested either way. Every result carries a disclaimer to confirm with staff before ordering if the allergy is severe.

The public menu MCP allows 60 requests a minute per visitor address; going over it returns a rate-limit error rather than any menu data, and the limit is checked before anything about the venue is looked up.

Each time an assistant starts a session against your menu — through the MCP server or a fetch of llms.txt — it counts toward the “Assistant fetches” figure on your analytics dashboard, broken down by which client made the call. It’s collected under the same analytics switch as every other visit, so turning analytics off for the venue stops this too.

A diner just gives their assistant your menu’s URL, {slug}.qaema.ai — from a QR code, a shared link, or a search result. An assistant that supports MCP finds the /mcp endpoint from /.well-known/mcp or the page itself; one that doesn’t can still read llms.txt or the page’s structured data directly. Nothing needs to be installed or configured on the diner’s side.