WaitApp

Search venues

search_venues

Read-onlyIdempotent

Search WaitApp venues (restaurants, hotels, lodges) by name, city and/or country, and filter them: takesDelivery, venueType (restaurant, hotel, event_organizer, ...) and openNow. Empty query lists venues. Name matching is forgiving (case, '&' vs 'and', small typos); if nothing matches closely, the closest names come back as didYouMean. Each venue says what it supports (delivery, table reservations, stays), whether it is open now and on what basis (openNowBasis: the venue's own switch, its opening hours, or no hours set so assumed open), when it next opens if closed (opensAt), and its hours in words (hoursSummary) and per day (openingHours). With a saved location (savedLocationId) or coordinates (nearLat and nearLng), each venue carries its straight-line distance and venues come back nearest first; with neither, the connected person's default saved location is used when they have one (sortedBy says so). For the delivery fee to an address use quote_delivery. Each venue includes its city and countryCode: venue names repeat across countries. To find who sells a dish, use search_menu.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_venues"
  }
}

Input Schema

Name	Required	Description
`city`	No	City to filter by, case-insensitive exact match
`limit`	No
`query`	No	Name to search for. Forgiving: ignores case and punctuation, treats '&' as 'and', tolerates small typos
`nearLat`	No	With nearLng: adds distance from this point
`nearLng`	No
`openNow`	No	true: only venues open right now
`venueType`	No	e.g. restaurant, hotel, event_organizer
`countryCode`	No	ISO 3166-1 alpha-2, e.g. ZM for Zambia — filter to a single country
`takesDelivery`	No	true: only venues that deliver
`savedLocationId`	No	A saved location of the connected person (list_saved_locations): adds distance from it

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 18, 2026

addedInput schema / properties / nearLat

Added value: +{
+  "description": "With nearLng: adds distance from this point",
+  "maximum": 90,
+  "minimum": -90,
+  "type": "number"
+}

addedInput schema / properties / nearLng

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

addedInput schema / properties / openNow

Added value: +{
+  "description": "true: only venues open right now",
+  "type": "boolean"
+}

addedInput schema / properties / savedLocationId

Added value: +{
+  "description": "A saved location of the connected person (list_saved_locations): adds distance from it",
+  "type": "string"
+}

addedInput schema / properties / takesDelivery

Added value: +{
+  "description": "true: only venues that deliver",
+  "type": "boolean"
+}

addedInput schema / properties / venueType

Added value: +{
+  "description": "e.g. restaurant, hotel, event_organizer",
+  "type": "string"
+}

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/safe, so the description uses its space well: it discloses forgiving name matching, the didYouMean fallback when nothing matches closely, distance-based sort order, the sortedBy indicator, openNowBasis provenance (venue switch vs hours vs no hours assumed open), and opensAt for closed venues. These are behavioral traits not derivable from annotations or schema.

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 matching behavior are front-loaded, then filters, then output semantics — a sensible order with almost no filler. The middle sentences are dense run-ons (openNowBasis/opensAt/hoursSummary packed into one clause chain), so it is slightly harder to scan than it needs to be.

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?

No output schema exists, and the description compensates fully by describing the per-venue return: supported services, open-now status and basis, next opening time, hours in words and per day, distance, city and countryCode, plus didYouMean and sortedBy. An agent has everything needed 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?

With 80% schema coverage the baseline is 3, and the description adds real meaning on top: nearLat/nearLng must be paired and trigger distance sorting, savedLocationId refers to list_saved_locations for the connected person, and openNow interacts with openNowBasis. Limit and the exact city matching rule are left entirely to the schema.

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 opening sentence gives a concrete verb (search) and resource (WaitApp venues), names the entity types (restaurants, hotels, lodges), and enumerates the filters and matching modes. It is unmistakably distinct from siblings like search_menu and quote_delivery, which it also names as separate tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states 'Empty query lists venues' (a non-obvious invocation mode) and routes two adjacent needs elsewhere: 'For the delivery fee to an address use quote_delivery' and 'To find who sells a dish, use search_menu.' The default-location fallback condition ('with neither, the connected person's default saved location is used') also clarifies behavior an agent would otherwise have to guess.

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?