WaitApp

Search menus across venues

search_menu

Read-onlyIdempotent

Finds which venues sell a dish or cuisine, such as pizza or biryani, by searching the menus of live venues in a city or country (never event organisers). Items filed under a category with the searched name (a Platters section for platter) come first, then dish names and descriptions; close equivalents are searched too (platter also finds basket and sharing plate) and listed in alsoSearched. Returns, for each venue with a match, the venue (whether it delivers, whether it is open now, and its distance when a position is known) and up to perVenue matching items with price and whether they have required choices; matchingItems and moreMatches say how many more exist. When a position is given, or the connected person has a default saved location, venues come back nearest first. Use list_menu_items with the venue id for the full menu and each item's options. Matches marked soldAheadOnly are sold only for a scheduled date (a pre-order with a time slot). Uses a search index, so it covers every live venue quickly. A city or countryCode narrows it and is recommended, because dish names are the same everywhere.

Input Schema

Name	Required	Description
`city`	No	City, case-insensitive exact match
`query`	Yes	A dish or cuisine, e.g. pizza, biryani, burger. Every word must appear in the item's name, category or description
`nearLat`	No	With nearLng: venues come back nearest-first from this point
`nearLng`	No
`openNow`	No	true: only venues open right now
`perVenue`	No	Matching items shown per venue; each venue says how many more matched
`maxVenues`	No
`countryCode`	No	ISO 3166-1 alpha-2, e.g. ZM
`takesDelivery`	No	true: only venues that deliver
`savedLocationId`	No	A saved location of the connected person (list_saved_locations): venues come back nearest-first from it

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 21, 2026

addedInput schema / properties / nearLat

Added value: +{
+  "description": "With nearLng: venues come back nearest-first from this point",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / nearLng

Added value: +{
+  "maximum": 180,
+  "minimum": -180,
+  "type": "number"
+}

changedInput schema / properties / perVenue / default
```
Previous value: -3New value: +8
```

addedInput schema / properties / perVenue / description

Added value: +"Matching items shown per venue; each venue says how many more matched"

changedInput schema / properties / perVenue / maximum
```
Previous value: -5New value: +15
```

addedInput schema / properties / savedLocationId

Added value: +{
+  "description": "A saved location of the connected person (list_saved_locations): venues come back nearest-first from it",
+  "type": "string"
+}

AddedOct 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds rich behavior beyond annotations: category-name matches ranked first, close equivalents reported in alsoSearched, per-venue item counts, soldAheadOnly meaning, and nearest-first ordering from a position or saved location. Annotations already confirm read-only and idempotent safety, but the description supplies the operational and return-shape context an agent needs.

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-loads purpose and packs useful details into a single dense paragraph with little repetition. It is longer than typical because the tool is complex, but every sentence carries signal; structure could be improved with bullets, keeping it from a 5.

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 carries the return-value burden and does so thoroughly: venue properties, matching items, price, required choices, matchingItems and moreMatches, and soldAheadOnly. Together with annotations and 80% schema coverage, an agent has enough to call and interpret results.

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 80%, so most parameters are already documented. The description adds meaning for perVenue (items per venue plus moreMatches), near/saved location ordering, city/countryCode narrowing, and query equivalence. It leaves maxVenues undocumented, but otherwise supplements the schema effectively.

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 and resource: finds venues selling a dish or cuisine by searching menus of live venues, and explicitly excludes event organisers. It also distinguishes itself from list_menu_items, which is named for full menus, so an agent can select it for dish discovery.

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 recommends city or countryCode narrowing and names list_menu_items as the alternative for full menus and item options. It also scopes results to live venues and never event organisers. However, it does not explicitly contrast with search_venues, leaving one sibling comparison to inference.

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

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