Skip to main content
Glama

Restaurant menu

get_restaurant_menu
Read-onlyIdempotent

Fetch the full public menu for a restaurant — categories, products, prices, option groups, allergens, nutrition. Use this to build the cart you pass to place_order. PUBLIC tool, no auth required. Each product carries option_groups (id, name, required, min_select, max_select, options[{id, name, price_delta}]); pass the chosen option ids as items[].modifier_option_ids to place_order or to create_cart (the anonymous cart the guest confirms) — a required group must be filled or the order or cart is refused. allergen_codes are EU 1169/2011 Annex II keys (gluten, crustaceans, eggs, fish, peanuts, soy, milk, nuts, celery, mustard, sesame, sulphites, lupin, molluscs) given ONLY when the venue's allergen name matches the regulation list exactly; a venue-specific allergen appears in allergens without a code. Allergen lists come from the venue (or were AI-suggested and then saved by the venue where allergen_disclosure.source says so). allergen_disclosure.as_of is when the venue last edited the item record, not a verification date. Follow the top-level disclosure.agent_instructions; show disclosure.text to the guest in their language whenever an allergen or dietary question comes up; dietary_flags only ever warn (true) — null is unknown, never "free of".

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_id": "<restaurant_id>"
    },
    "name": "get_restaurant_menu"
  }
}

Input Schema

NameRequiredDescriptionDefault
localeNoen
restaurant_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses that required option groups must be filled or the order/cart is refused, explains allergen code semantics and disclosure sourcing, and warns that dietary_flags are only warnings and null means unknown. It also states the tool is public with no auth required. This is substantial behavioral context that annotations alone do not provide.

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?

The description is front-loaded with purpose and usage before moving into detailed output and allergen semantics. It is dense and long, but the detail is relevant for a menu/allergen tool and most sentences earn their place.

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?

With no output schema, the description still explains the returned structure: categories, products, option_groups, allergen_codes, allergen_disclosure, disclosure, and dietary_flags. It also covers the key behavioral constraints needed to use the menu data correctly with place_order and create_cart.

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

Parameters2/5

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

Schema description coverage is 0% for the two parameters, so the description must compensate. It never explains restaurant_id or locale; "for a restaurant" only weakly implies restaurant_id, and locale is entirely unaddressed.

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

Purpose4/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: "Fetch the full public menu for a restaurant," and scopes it to categories, products, prices, option groups, allergens, and nutrition. It does not explicitly distinguish this from sibling tools such as list_public_menus or search_products, so it falls short of a 5.

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 clear usage context: use this to build the cart passed to place_order, and it explains how option ids feed create_cart or place_order. It also states the tool is public and needs no auth. It does not name when to use alternatives like list_public_menus or search_products instead.

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