Thmenu

Search restaurants

search_restaurants

Read-onlyIdempotent

Search the public directory (opt-in venues only) by location, opening status, cuisine, dietary options, declared attributes, ordering channel, declared price level and menu language — and, right now, a free table or an open waitlist (the restaurant graph's channel states). Neutral ranking (AI-K6): distance in 0.5 km bands when near is given → availability (open now first; unknown hours before closed; a venue in holiday mode counts as closed) → profile freshness (owner-verified within 90 days first) → name. Payment to Thmenu never affects order. Cuisine, dietary, price level and other attributes are owner declarations, not verified facts; venues without a declaration are excluded only when an attribute or price filter is used, and venues without coordinates only when near is used. Returns slug, name, city, country, distance_km, is_open_now (serve-time, in the venue's own timezone; null when hours are unknown; false while the venue is in holiday mode), channels (order · reservation · pickup · delivery), declared attributes, freshness and the menu URL. Paginated.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Free text over name and description (min 2 chars).
`city`	No
`near`	No	Search centre. Venues without coordinates are excluded when set.
`page`	No
`limit`	No
`channel`	No	order = digital ordering at the table; reservation; pickup = takeaway; delivery = venue's own delivery.
`country`	No	ISO 3166-1 alpha-2
`cuisine`	No	All listed cuisines must be declared by the venue.
`dietary`	No	Owner declaration, not a certification.
`open_now`	No	Only venues open right now in their own timezone; venues with unknown hours are excluded when true.
`waitlist`	No	Only venues whose waitlist is open now (WAITLIST_AVAILABLE): the reservations switch, which also opens the waitlist, and the venue open now — not in holiday mode.
`price_max`	No	Owner-declared price level 1–4 (schema.org priceRange "$" … "$$$$"): venues at or below it. Venues that declared no level are excluded when set.
`radius_km`	No
`attributes`	No	Any declared attribute token (meals, family, outdoor, accessibility, cuisine, dietary).
`menu_language`	No	The menu can be read in this language: it is the menu's source language, or at least 90 % of the guest menu's dish names are translated into it (the restaurant graph's rule).
`table_available`	No	Only venues open now with a table that staff marked ready on the live table board (TABLE_AVAILABLE). Venues not using the board are excluded: unknown is not "available".

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / cuisine / items / enum

Previous value: -[
-  "turkish",
-  "kebab",
-  "ottoman",
-  "anatolian",
-  "aegean",
-  "black_sea",
-  "mediterranean",
-  "middle_eastern",
-  "lebanese",
-  "persian",
-  "georgian",
-  "greek",
-  "balkan",
-  "romanian",
-  "polish",
-  "eastern_european",
-  "russian",
-  "italian",
-  "pizza",
-  "pasta",
-  "french",
-  "spanish",
-  "tapas",
-  "portuguese",
-  "german",
-  "austrian",
-  "british",
-  "irish",
-  "scandinavian",
-  "dutch",
-  "american",
-  "burger",
-  "steakhouse",
-  "bbq",
-  "tex_mex",
-  "mexican",
-  "latin_american",
-  "brazilian",
-  "peruvian",
-  "caribbean",
-  "japanese",
-  "sushi",
-  "ramen",
-  "chinese",
-  "korean",
-  "thai",
-  "vietnamese",
-  "indian",
-  "pakistani",
-  "indonesian",
-  "malaysian",
-  "filipino",
-  "african",
-  "ethiopian",
-  "moroccan",
-  "seafood",
-  "grill",
-  "vegetarian",
-  "vegan",
-  "healthy",
-  "cafe",
-  "coffee",
-  "tea_house",
-  "bakery",
-  "patisserie",
-  "dessert",
-  "ice_cream",
-  "breakfast_brunch",
-  "fast_food",
-  "street_food",
-  "fusion",
-  "international",
-  "fine_dining",
-  "bistro",
-  "pub",
-  "bar",
-  "wine_bar",
-  "cocktail_bar",
-  "juice_bar",
-  "hotel_restaurant",
-  "food_court"
-]New value: +[
+  "turkish",
+  "kebab",
+  "ottoman",
+  "anatolian",
+  "aegean",
+  "black_sea",
+  "mediterranean",
+  "middle_eastern",
+  "lebanese",
+  "persian",
+  "georgian",
+  "greek",
+  "balkan",
+  "romanian",
+  "polish",
+  "eastern_european",
+  "russian",
+  "italian",
+  "pizza",
+  "pasta",
+  "french",
+  "spanish",
+  "tapas",
+  "portuguese",
+  "german",
+  "austrian",
+  "british",
+  "irish",
+  "scandinavian",
+  "dutch",
+  "american",
+  "burger",
+  "steakhouse",
+  "bbq",
+  "tex_mex",
+  "mexican",
+  "latin_american",
+  "brazilian",
+  "peruvian",
+  "caribbean",
+  "japanese",
+  "sushi",
+  "ramen",
+  "chinese",
+  "korean",
+  "thai",
+  "vietnamese",
+  "indian",
+  "pakistani",
+  "indonesian",
+  "malaysian",
+  "filipino",
+  "african",
+  "ethiopian",
+  "moroccan",
+  "seafood",
+  "grill",
+  "vegetarian",
+  "vegan",
+  "healthy",
+  "cafe",
+  "coffee",
+  "tea_house",
+  "bakery",
+  "patisserie",
+  "dessert",
+  "ice_cream",
+  "breakfast_brunch",
+  "fast_food",
+  "street_food",
+  "fusion",
+  "international",
+  "fine_dining",
+  "bistro",
+  "pub",
+  "bar",
+  "wine_bar",
+  "cocktail_bar",
+  "juice_bar",
+  "food_court"
+]

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / table_available

Added value: +{
+  "default": false,
+  "description": "Only venues open now with a table that staff marked ready on the live table board (TABLE_AVAILABLE). Venues not using the board are excluded: unknown is not \"available\".",
+  "type": "boolean"
+}

addedInput schema / properties / waitlist

Added value: +{
+  "default": false,
+  "description": "Only venues whose waitlist is open now (WAITLIST_AVAILABLE): the reservations switch, which also opens the waitlist, and the venue open now — not in holiday mode.",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 7, 2026

addedInput schema / properties / menu_language

Added value: +{
+  "description": "The menu can be read in this language: it is the menu's source language, or at least 90 % of the guest menu's dish names are translated into it (the restaurant graph's rule).",
+  "enum": [
+    "tr",
+    "en",
+    "de",
+    "fr",
+    "es",
+    "it",
+    "nl",
+    "pt",
+    "ru",
+    "ar",
+    "zh",
+    "ja",
+    "ko",
+    "pl",
+    "sv",
+    "da",
+    "fi",
+    "no",
+    "cs",
+    "hu",
+    "ro",
+    "bg",
+    "el",
+    "hr",
+    "sk",
+    "sl",
+    "lt",
+    "lv",
+    "he",
+    "fa",
+    "sw"
+  ],
+  "type": "string"
+}

addedInput schema / properties / price_max

Added value: +{
+  "description": "Owner-declared price level 1–4 (schema.org priceRange \"$\" … \"$$$$\"): venues at or below it. Venues that declared no level are excluded when set.",
+  "maximum": 4,
+  "minimum": 1,
+  "type": "integer"
+}

First observedOct 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent/no-destroy, and the description adds substantial behavior beyond them: the deterministic neutral ranking (distance bands → availability → freshness → name), holiday-mode-counts-as-closed, unknown-hours ordering, serve-time is_open_now in the venue's timezone (null when unknown), and pagination. It also discloses that ranking and payment never influence results.

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?

Front-loaded with the searchable dimensions, then ranking, then caveats, then the returned fields — a logical order. It is dense and em-dash heavy with small redundancy (eligibility rules restated for waitlist and table_available), but nearly every clause carries operative information.

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 16 parameters, a nested object, and no output schema, the description compensates fully: it enumerates return fields (slug, name, city, country, distance_km, is_open_now, channels, attributes, freshness, menu URL), states pagination, and defines the ranking and exclusion rules an agent needs to interpret results correctly.

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 75%, so per-parameter types and most descriptions are already in the schema. The description still adds meaning beyond it by grouping the filters and, crucially, stating the exclusion semantics (missing declaration excluded only under attribute/price filters; missing coordinates excluded only with `near`) and the declaration-vs-fact caveat for cuisine/dietary/price.

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?

States a specific verb (search) and resource (the public restaurant directory), and adds scope ('opt-in venues only') plus the full set of filter dimensions. It is clearly distinguishable from siblings like get_restaurant (single lookup) and list_public_menus without opening either schema.

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?

Explicitly lays out when filters bite: 'venues without a declaration are excluded only when an attribute or price filter is used, and venues without coordinates only when `near` is used', plus what open_now/waitlist/table_available mean. It does not name a sibling alternative for a single-venue lookup, so routing is clear but not fully comparative.

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?