Get Recommendations
recommendThe one call for "where should we eat": a ranked, final answer for one meal or occasion, each result graded with the reasons it fits and anything it misses. Call it once per meal slot with the diner's ask in the diner's own words: the place or anchor, the time of day, who is eating (party size, kids, a date, a group) and any stated constraints or dislikes. Prefer it over generating your own candidates and checking them by name; it already ranks what Seemor holds for the ask. A dish ask ("good beef bourguignon near the Marais") is a recommend ask. Results are ranked and final: do not re-call with reworded variations or look up each result. Each result already carries a grade (or preliminary_band, the floor of the range: 'B-range' means at least B minus), match_reasons, caveats (a caveat beginning "Misses" names something the room does not deliver, never a good thing about it; a strong_match row never carries one), honored_constraints (plain-language labels for the stated filters this specific row confirms, e.g. "Indian", "Takeaway", "In Magnolia"), and requirements (per stated requirement, one of confirmed / contradicted / unknown, with the plain-words evidence that produced it) weighed against the request. A result may also carry place_note ("Near Williamsburg", "In Hoboken"): where that room is, present ONLY when the room is outside the place asked for — a room in the place the diner asked for carries no place_note, so never read a missing place_note as "somewhere else", and when one IS present say so rather than implying the room is in the place asked for. When result_groups is present, results is already partitioned into ORDERED, LABELED groups (exact / exact_within_wider_radius / likely_match_unconfirmed / nearby_any / relaxed_amenity) — present them to the user top to bottom, in that order, using each group's own message verbatim; never re-order the groups or the rows within a group (present rows in the order given), and never offer them as a choice. Never claim a nearby_any or relaxed_amenity row satisfies a constraint it does not carry in honored_constraints, and never call a likely_match_unconfirmed row (or any row carrying a requirement with status "unknown") a confirmed or exact match — say plainly that it likely matches but could not be confirmed from Seemor's data, and name what could not be confirmed (unknown_requirements lists it at the response level). repeat_ask: true means this is the same answer already given for the identical ask; say so rather than presenting it as new. Call it ONCE per diner ask, with the full ask (cuisine, occasion, vibe, constraints) in query and the place in location. Pass the diner's request in the diner's own words: do not add emphasis, priorities or qualities the diner did not state (for example "prioritize a quiet atmosphere" when the diner only said "quiet"), because added emphasis turns a light preference into a hard requirement and changes the answer. Results are ranked and final: do not re-call with reworded variations or call lookup_restaurant on each result to double-check it; that adds latency, not a better answer. For follow-ups about one place, use lookup_restaurant or ask_about_restaurant. If a result carries caveats, coverage_level 'basic', or a message noting a thin pool, relay it to the user instead of searching again. Requires a location: include one in your query (e.g. "in Soho"), or provide location, or latitude/longitude, or the tool refuses with location_required instead of guessing a city. Rows carry google_maps_url and website when Seemor holds them (null otherwise), plus seemor_url. Seemor holds no booking, availability or opening-hours data: use a booking app for those and join on restaurant name and address.
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": {
"query": "<query>"
},
"name": "recommend"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recommendations to return (1-10, default 5). | |
| query | Yes | Natural language dining request, e.g. 'quiet Italian restaurant for a date night in Covent Garden' or 'best sushi in Shibuya for a celebration'. Include the location in your query OR provide latitude/longitude. | |
| latitude | No | Latitude of the place the diner is asking about (the search center). Alternative to location: use when you have the coordinates of that place. Do not send the diner's own device location unless the diner gave it. If both location and lat/lng are provided, location takes priority for disambiguation. | |
| location | No | City or area to bias the search toward, e.g. 'London', 'San Francisco', 'Rome'. Use this when the query doesn't include a location, or to disambiguate (e.g. 'Victoria' could be London or British Columbia — pass 'London' to clarify). Whenever the conversation shows which place the diner means, pass it with its city, state or country, so a name several places share needs no question. If omitted and the query contains a location, that location is used. This is the place the diner is asking about, named in words; do not fill it from the diner's own device location unless the diner gave it. | |
| longitude | No | Longitude of the place the diner is asking about (the search center). Must be provided with latitude. Do not send the diner's own device location unless the diner gave it. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| message | No | ||
| results | No | ||
| next_asks | No | ||
| next_step | No | ||
| candidates | No | ||
| place_note | No | ||
| repeat_ask | No | ||
| other_places | No | ||
| location_used | No | ||
| result_groups | No | ||
| pool_disclosure | No | ||
| query_understood | No | ||
| total_candidates | No | ||
| unknown_requirements | No | ||
| unverifiable_attributes | No |