Seemor Restaurant Intelligence

Search Restaurants

search_restaurants

Read-onlyIdempotent

Search for restaurants near a place. Name the place with location (for example "Shibuya, Tokyo"), or give its latitude and longitude; one of the two is required, and location wins when both are sent. A name several places share returns status geo_conflict with candidates to choose from, and a name Seemor does not know returns status not_found. For picking where to eat or giving recommendations, use recommend; this tool is for browsing a list by distance or filters. Returns graded, ranked results with cuisine, price level, and Seemor analysis summaries. Fully analyzed restaurants (coverage_level 'full', letter grade) come first; when fewer than limit are available, quick-read restaurants are appended after them, marked coverage_level 'basic' with grade null and a preliminary_band (e.g. 'A-range') graded from review analysis, not star ratings. total_in_area = analyzed_in_area + preliminary_in_area; a message explains when quick-read rows are included. When location names a place Seemor holds, rooms inside that place come first and any room outside it carries a place_note (present it as outside the place asked for); analyzed_in_place counts the analyzed rooms inside and returned_outside_place counts the returned rooms outside.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	Sort order: "grade" (default, best first) or "distance" (nearest first).
`limit`	No	Maximum results to return. Default 10, max 10.
`cuisine`	No	Filter by cuisine type (e.g. "Italian", "Japanese"). Case-insensitive substring match.
`latitude`	No	Latitude of the place the diner is asking about, as the coordinates of that place (-90 to 90). Do not send the diner's own device location unless the diner gave it.
`location`	No	Name of the place the diner is asking about, e.g. 'Shibuya, Tokyo', 'Soho, London', 'Rome'. Pass it with its city, state or country whenever the conversation shows which place is meant, so a name several places share needs no question. Use this instead of guessing coordinates. Either location or both latitude and longitude is required; if both are sent, location takes priority. 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, as the coordinates of that place (-180 to 180). Do not send the diner's own device location unless the diner gave it.
`min_grade`	No	Minimum letter grade to include (e.g. "B+"). Grades: A+, A, A-, B+, B, B-, C+, C, C-, D, F.
`radius_km`	No	Search radius in kilometers. Default 2, max 10.
`price_level`	No	Filter by price level: "$", "$$", "$$$", or "$$$$".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	No
`message`	No
`results`	No
`next_step`	No
`candidates`	No
`place_note`	No
`other_places`	No
`location_used`	No
`total_in_area`	No
`more_candidates`	No
`analyzed_in_area`	No
`query_understood`	No
`total_candidates`	No
`analyzed_in_place`	No
`preliminary_in_area`	No
`returned_outside_place`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedSep 29, 2026

changedInput schema / properties / latitude / description

Previous value: -"Latitude of the search center (-90 to 90)."New value: +"Latitude of the place the diner is asking about, as the coordinates of that place (-90 to 90). Do not send the diner's own device location unless the diner gave it."

addedInput schema / properties / location

Added value: +{
+  "description": "Name of the place the diner is asking about, e.g. 'Shibuya, Tokyo', 'Soho, London', 'Rome'. Pass it with its city, state or country whenever the conversation shows which place is meant, so a name several places share needs no question. Use this instead of guessing coordinates. Either location or both latitude and longitude is required; if both are sent, location takes priority. 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.",
+  "type": "string"
+}

changedInput schema / properties / longitude / description

Previous value: -"Longitude of the search center (-180 to 180)."New value: +"Longitude of the place the diner is asking about, as the coordinates of that place (-180 to 180). Do not send the diner's own device location unless the diner gave it."

changedInput schema / required

Previous value: -[
-  "latitude",
-  "longitude"
-]New value: +[]

addedOutput schema / properties / analyzed_in_place
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / candidates

Added value: +{
+  "items": {
+    "properties": {
+      "city": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "country": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "label": {
+        "type": "string"
+      },
+      "lat": {
+        "type": "number"
+      },
+      "lng": {
+        "type": "number"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / location_used
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / more_candidates
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / next_step
```
Added value: +{
+  "type": "string"
+}
```

addedOutput schema / properties / other_places

Added value: +{
+  "items": {
+    "properties": {
+      "city": {
+        "type": "string"
+      },
+      "country": {
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / place_note
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / query_understood
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / results / items / properties / place_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / returned_outside_place
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / total_candidates
```
Added value: +{
+  "type": "number"
+}
```

Changed1 schema field changedAug 22, 2026
- changedOutput schema / properties / results / items / properties / coverage_level / enum
```
Previous value: -[
-  "full",
-  "basic"
-]New value: +[
+  "full",
+  "basic",
+  "none"
+]
```
Changed12 schema fields changedAug 22, 2026
- addedOutput schema / properties / analyzed_in_area
```
Added value: +{
+  "type": "number"
+}
```
- addedOutput schema / properties / preliminary_in_area
```
Added value: +{
+  "type": "number"
+}
```
- changedOutput schema / properties / results / items / properties / address / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / results / items / properties / caveats
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
- changedOutput schema / properties / results / items / properties / city / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / results / items / properties / coverage_level / enum
```
Added value: +[
+  "full",
+  "basic"
+]
```
- addedOutput schema / properties / results / items / properties / distance_km
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```
- changedOutput schema / properties / results / items / properties / grade / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / results / items / properties / neighborhood / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- addedOutput schema / properties / results / items / properties / preliminary_band
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / results / items / properties / price_level
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / results / items / properties / tldr
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
Changed3 schema fields changedJul 30, 2026
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- removedOutput schema / properties / total
```
Removed value: -{
-  "type": "number"
-}
```
- addedOutput schema / properties / total_in_area
```
Added value: +{
+  "type": "number"
+}
```

Changed1 schema field changedJul 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "items": {
+        "properties": {
+          "address": {
+            "type": "string"
+          },
+          "city": {
+            "type": "string"
+          },
+          "coverage_level": {
+            "type": "string"
+          },
+          "cuisine_tags": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "grade": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "neighborhood": {
+            "type": "string"
+          },
+          "seemor_id": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

First observedJul 6, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description goes far beyond them: it discloses the graded-then-quick-read ordering, coverage_level 'full' vs 'basic', grade null with preliminary_band, the total_in_area = analyzed_in_area + preliminary_in_area relationship, and the in-place/outside-place room handling with place_note. This is unusually rich behavioral disclosure for a search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the alternative-tool routing are front-loaded, but the description then spends roughly half its length detailing return values (coverage levels, grade bands, count fields) that an output schema already documents. The result is dense and longer than the selection decision requires.

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?

For a 9-parameter, open-ended search tool with an output schema, the description leaves nothing an agent needs unresolved: input precedence, failure statuses, result ordering, and anomalous-result handling are all covered. The extensive return-value prose is redundant rather than missing.

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 100%, so the baseline is 3; the description adds marginal but real value by reinforcing the location-over-coordinates precedence and explaining how `limit` interacts with the appending of quick-read ('basic') results, which the schema does not convey. Most other parameter meaning is already carried by 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 names a specific verb and resource ('Search for restaurants near a place') and immediately draws the boundary against the sibling 'recommend', stating this tool is for 'browsing a list by distance or filters'. An agent can distinguish it from recommend, find_restaurant, and lookup_restaurant without opening any schema.

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?

Explicit routing guidance: use recommend for 'picking where to eat or giving recommendations', use this for browsing by distance or filters. It also states the location-vs-coordinates rule (location wins when both are sent) and describes the geo_conflict and not_found outcomes so the agent knows what to do on ambiguous or unknown places.

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

All Seemor Restaurant Intelligence 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?