Seemor Restaurant Intelligence

Server Details

Structured restaurant intelligence for AI platforms. 760K+ restaurants catalogued across 26 countries, 62K+ with deep 37-dimension analysis including letter grades, occasion-aware recommendations, menu insights, and neighborhood exploration. Six tools: find restaurants by name, search by location, explore area dining scenes, look up detailed profiles (3 detail tiers), ask natural language questions, and get personalized recommendations.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 63 days
Last Tested: 2026-10-19 11:48
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.4/5.0

Scored 2026-10-19 10:40 across 6 tools

Disambiguation4/5

find_restaurant, search_restaurants, lookup_restaurant, and recommend are all discovery-ish tools, but the descriptions draw sharp lines: name-based lookup vs. location-based browsing vs. single-place detail vs. final ranked answer. explore_area and ask_about_restaurant are clearly separate. A careless agent could still conflate find_restaurant and search_restaurants, keeping it just under 5.

Naming Consistency4/5

Five of six names follow a clean verb_noun pattern (find_restaurant, lookup_restaurant, search_restaurants, ask_about_restaurant, explore_area). Only 'recommend' is a bare verb, a minor deviation that is still perfectly readable.

Tool Count5/5

Six tools is well-scoped for a restaurant intelligence service, with each tool earning its place across discovery, detail, aggregation, Q&A, and recommendation. No redundancy or padding.

Completeness5/5

The read-only surface is complete: find by name, search by area, look up a specific ID, ask a targeted question, get area aggregates, and receive a final ranked recommendation. As an intelligence/recommendation service there are no obvious missing operations.

Available Tools

6 tools

ask_about_restaurantAsk About RestaurantA

Read-only

Inspect

Ask a specific question about a restaurant based on analysis of real reviews and menu data. Common questions: what to order, group suitability, dietary options, vibe/atmosphere, value assessment. Requires a restaurant_id from find_restaurant or search_restaurants. Ask one question per call. Accounts connected through an assistant have a small free number of answers per day; if the result carries limit_reached, relay its message to the user as written and do not retry.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	Question about the restaurant. Examples: 'What should I order?', 'Is it good for groups?', 'What are the dietary accommodations?', 'Is it worth the price?'
`restaurant_id`	Yes	Seemor restaurant ID (UUID). Get IDs from find_restaurant or search_restaurants.

Output Schema

ParametersJSON Schema

Name	Required	Description
`answer`	No
`source`	No
`status`	No
`message`	No
`category`	No
`question`	No
`seemor_url`	No
`restaurant_id`	No
`restaurant_name`	No

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover safety (readOnlyHint=true, destructiveHint=false) but say nothing about throttling; the description adds a free-answer-per-day quota and a specific error-handling protocol (relay limit_reached, do not retry). That is real behavioral context the structured fields do not carry.

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

Conciseness5/5

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

Front-loaded with purpose, then categories, then prerequisites, then limits. Every sentence carries actionable information – no filler or restatement of the name.

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 an output schema present and annotations covering safety, the description need not explain return values. Given the rate-limit disclosure and prerequisite routing, it is complete for what an agent needs to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters and their examples. The description reinforces the restaurant_id provenance but adds no syntax or format detail beyond the schema; baseline 3 applies.

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 (ask) and resource (question about a restaurant), plus the basis of the answer (real reviews and menu data). The scope 'one question per call' and the concrete question categories make it unmistakable against siblings like recommend or lookup_restaurant.

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?

Explicitly states the prerequisite ('Requires a restaurant_id from find_restaurant or search_restaurants'), the usage cadence ('Ask one question per call'), and how to handle the limit_reached outcome. It routes the agent to the right upstream sibling and gives the when-not via the rate-limit rule.

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

explore_areaExplore AreaA

Read-onlyIdempotent

Inspect

Get aggregate dining statistics for a neighborhood, city, or region: cuisine breakdown, grade distribution, price range, top neighborhoods, and highlighted restaurants. Use this for area-level context ("what is the dining scene like in Shoreditch?"), NOT for finding a specific restaurant or getting a personal recommendation. For "find me a quiet Italian near Shoreditch", use the recommend tool instead. Coverage is reported honestly: coverage_level 'full' (fully analyzed rows present), 'basic' (only quick-read rows: review-analysis bands, no letter grades yet), or 'none'; analyzed_count and preliminary_count split total_restaurants, and highlights marked coverage_level 'basic' carry a preliminary_band instead of a grade. not_found means neither analyzed nor preliminary rows exist.

ParametersJSON Schema

Name	Required	Description	Default
`area`	Yes	Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Whenever the conversation shows which place is meant, add its city, state or country after a comma, so a shared name needs no guess; other_places lists the others when a name is shared.

Output Schema

ParametersJSON Schema

Name	Required	Description
`area`	No
`status`	No
`message`	No
`highlights`	No
`place_note`	No
`description`	No
`other_places`	No
`top_cuisines`	No
`neighborhoods`	No
`analyzed_count`	No
`coverage_level`	No
`price_breakdown`	No
`preliminary_count`	No
`total_restaurants`	No
`grade_distribution`	No
`analyzed_restaurants`	No

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its budget on data-quality behavior: coverage_level states ('full'/'basic'/'none'), the analyzed_count vs preliminary_count split, preliminary_band for basic highlights, and not_found semantics. This is genuine interpretive context; it overlaps somewhat with the output schema's field definitions but adds the honesty caveat an agent needs to avoid over-claiming.

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 purpose, then usage and routing, then the coverage-semantics detail. The final coverage sentence is dense but every clause carries decision-relevant meaning (distinguishing full/basic/none and not_found).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema already exists, the description needn't restate return values, yet it adds the coverage-interpretation layer plus clear routing to siblings. Complete for an agent to select and call it correctly, with only minor redundancy against the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with a single well-documented 'area' parameter (formats, disambiguation guidance, shared-name behavior). The description adds no syntax beyond the schema, so the baseline of 3 applies.

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?

Opens with a specific verb+resource ('Get aggregate dining statistics for a neighborhood, city, or region') and enumerates the returned aggregates (cuisine breakdown, grade distribution, price range, top neighborhoods, highlights). It also implicitly distinguishes itself from the restaurant-level siblings, so an agent can tell it is an area-aggregate tool.

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?

Explicitly states the intended use ('what is the dining scene like in Shoreditch?'), the exclusion ('NOT for finding a specific restaurant or getting a personal recommendation'), and names the alternative with a concrete routing example ('find me a quiet Italian near Shoreditch' → recommend). Nothing is left to inference.

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

find_restaurantFind RestaurantA

Read-onlyIdempotent

Inspect

Find restaurants by name. Returns matching restaurants with their Seemor IDs, which can be passed to lookup_restaurant for full details. Use the city parameter to disambiguate common names. Each result reports coverage_level: 'full' (letter grade), 'basic' (preliminary read: grade null, preliminary_band, tldr, caveat) or 'none' (no analysis yet).

ParametersJSON Schema

Name	Required	Description
`city`	No	City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Whenever the conversation shows which place is meant, include its state or country ('Vienna, Virginia'), so a shared name needs no guess. Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places).
`name`	Yes	Restaurant name to search for (partial matches work). Example: 'Barrafina', 'Pizza Pilgrims', 'Noma'.
`limit`	No	Maximum results to return (1-20, default 5).

Output Schema

ParametersJSON Schema

Name	Required	Description
`place`	No
`status`	No
`message`	No
`results`	No
`place_note`	No
`other_places`	No
`total_matches`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, non-destructive). The description adds a genuinely useful behavioral detail not in any structured field: the coverage_level values and what 'basic' vs 'none' means for what the caller receives. That is exactly the kind of context annotations don't carry.

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?

Three sentences, front-loaded with purpose and result format. Each sentence adds something (purpose, ID handoff, disambiguation, coverage levels), though the coverage_level taxonomy is dense and could be slightly tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required. Between the description and the annotation set, an agent has enough to call the tool and interpret coverage_level. The missing piece is explicit routing against the other discovery siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents city, name, and limit thoroughly. The description's only added hint is 'use the city parameter to disambiguate common names', which is largely redundant with the schema's own city guidance. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Find restaurants by name') and clarifies it returns IDs rather than full details, which is the key distinction from lookup_restaurant. However, it does not differentiate itself from search_restaurants or explore_area, two siblings that plausibly also find restaurants.

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?

Provides clear context: use city to disambiguate common names, and pass IDs to lookup_restaurant for full details. This sequences the tool relative to a sibling. But it offers no guidance on when to prefer search_restaurants or explore_area over this tool, so the routing picture is incomplete.

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

lookup_restaurantLook Up RestaurantA

Read-onlyIdempotent

Inspect

Look up a specific restaurant by its Seemor ID. Returns grade, summary, cuisine, neighborhood, and other details. Use the fields parameter to request richer data (standard or premium; fully analyzed restaurants only, except the quick-read dimension_assessments below). coverage_level 'full' rows carry a letter grade; 'basic' rows are Seemor quick reads: review-analysis bands (grade null, preliminary_band such as 'B-range') with a one-line tldr, graded from review analysis rather than star ratings; With fields 'premium' a quick-read row also carries dimension_assessments for the dimensions the quick read measured (food quality, consistency, noise, service attentiveness, large parties, local vs tourist, value), labelled on the same scale as full analysis but read from fewer reviews, so present them as preliminary. 'none' rows have no analysis yet. Use search_restaurants or find_restaurant first to get restaurant IDs. Use this for a single place the user asks about, not for every result of recommend.

ParametersJSON Schema

Name	Required	Description	Default
`fields`	No	Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional assessments (noise, formality, authenticity, etc.), value assessment, standout strengths/weaknesses, unique selling points.
`restaurant_id`	Yes	Seemor restaurant ID (UUID). Get IDs from search_restaurants results.

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	No
`message`	No
`restaurant`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive and openWorld=false, so the safety profile is free; the description goes well beyond by decoding coverage_level semantics ('full' carries a letter grade, 'basic' is a quick read with grade null and a preliminary_band, 'none' has no analysis). It also warns that premium dimension_assessments on quick-read rows are 'labelled on the same scale... but read from fewer reviews, so present them as preliminary' — a genuinely non-obvious caveat. It loses a point for not noting pagination, latency, or error behavior, but the data-semantics disclosure is substantial.

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 prerequisite are front-loaded, which is good, but the middle is a dense run-on that packs coverage_level, quick-read grading, field-level routing and the preliminary caveat into one serpentine sentence. Shorter sentences or a small structure would preserve the meaning with less parsing overhead, though the content itself earns its place.

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?

An output schema exists, so return values needn't be documented, yet the description still supplies the interpretation an agent needs (grade null vs. preliminary_band, preliminary vs. full analysis). Combined with annotations covering safety and a fully-described 2-param schema, nothing material for correct invocation is 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 description coverage is 100%, so the baseline is 3 and the schema already documents both params including the full fields enum. The description still adds value by tying fields to data availability ('fully analyzed restaurants only, except the quick-read dimension_assessments below') and by explaining what the basic/default level actually returns, which the schema does not fully capture.

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 description names a specific verb+resource ('Look up a specific restaurant by its Seemor ID') and enumerates the returned fields, then explicitly separates itself from siblings: single lookup vs. 'every result of recommend' and vs. search_restaurants/find_restaurant. An agent can pick it apart from all five siblings without opening a 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?

It states the prerequisite ('Use search_restaurants or find_restaurant first to get restaurant IDs') and the exclusion ('not for every result of recommend'), so both the when and the when-not are explicit. The fields-level routing (basic/standard/premium) further tells the agent how to scope the call.

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

recommendGet RecommendationsA

Read-only

Inspect

Returns a complete, ranked restaurant recommendation for a dining occasion: the final answer, not a search. Each result already carries a grade (or preliminary_band), 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. Accounts connected through an assistant have a small free number of recommend runs per day (only runs that return results count); if the result carries limit_reached, relay its message to the user as written and do not retry. 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.

ParametersJSON Schema

Name	Required	Description
`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

ParametersJSON Schema

Name	Required	Description
`status`	No
`message`	No
`results`	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

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover only the safety profile (readOnly, non-destructive, non-idempotent, closed-world), so the description carries the real behavioral burden and does so richly: per-day run limits, limit_reached and location_required handling, repeat_ask semantics, caveat/place_note/honored_constraints conventions, and group ordering rules. It adds substantial context far beyond the annotations, and does not contradict them (the non-idempotent hint is consistent with the repeat_ask note).

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 is front-loaded, and most clauses carry genuine operational guidance, so it is not padding. However, it is one sprawling paragraph of roughly 450 words with heavy clause nesting, making it hard to scan and retrieve the rule you need at call time.

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?

An output schema exists, so return values needn't be explained, yet the description still gives enough about grades, groups, caveats, and constraint-confirmation states for an agent to both call and present results correctly. Nothing an agent needs is 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, but the description adds meaning the schema does not: pass the diner's request in their own words without adding emphasis or priorities, and the location/query/lat-lng fallback precedence for the required location. That is real added guidance on how to fill query and location, lifting it above baseline.

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 states a specific verb (Returns), resource (ranked restaurant recommendation for a dining occasion), and explicitly frames it against the search siblings: 'the final answer, not a search.' An agent can immediately tell this apart from search_restaurants, find_restaurant, or lookup_restaurant.

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 gives explicit when-to-use ('Call it ONCE per diner ask, with the full ask'), when-not ('do not re-call with reworded variations'), and named alternatives ('For follow-ups about one place, use lookup_restaurant or ask_about_restaurant'). It even forbids the tempting misuse of calling lookup_restaurant on each result. Nothing about routing is left to inference.

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

search_restaurantsSearch RestaurantsA

Read-onlyIdempotent

Inspect

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.

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
`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

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 14, 2026

Changedrecommend1 field changed

changedOutput schema / properties / result_groups / items / properties / label / enum

Previous value: -[
-  "exact",
-  "exact_within_wider_radius",
-  "likely_match_unconfirmed",
-  "nearby_any",
-  "relaxed_amenity",
-  "below_grade_floor"
-]New value: +[
+  "exact",
+  "exact_within_wider_radius",
+  "likely_match_unconfirmed",
+  "nearby_any",
+  "relaxed_amenity",
+  "below_grade_floor",
+  "menu_mention_only"
+]

4 tool updatesSep 29, 2026

Changedexplore_area1 field changed
- addedOutput schema / properties / highlights / items / properties / place_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
Changedfind_restaurant1 field changed
- addedOutput schema / properties / results / items / properties / place_note
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changedrecommend4 fields changed

changedInput schema / properties / latitude / description

Previous value: -"Latitude of search center. Alternative to location — use when you have coordinates. If both location and lat/lng are provided, location takes priority for disambiguation."New value: +"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."

changedInput schema / properties / location / description

Previous value: -"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."New value: +"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."

changedInput schema / properties / longitude / description

Previous value: -"Longitude of search center. Must be provided with latitude."New value: +"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."

changedInput schema / properties / query / description

Previous value: -"Natural language dining request, e.g. 'quiet Italian restaurant for a date night in Covent Garden' or 'best sushi near me for a celebration'. Include the location in your query OR provide latitude/longitude."New value: +"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."

Changedsearch_restaurants15 fields changed

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"
+}
```

1 tool updateSep 27, 2026

Changedrecommend2 fields changed

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"
+}
```

3 tool updatesSep 26, 2026

Changedexplore_area1 field changed

changedInput schema / properties / area / description

Previous value: -"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Use a comma qualifier to pick between places that share a name; other_places lists them when a name is shared."New value: +"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Whenever the conversation shows which place is meant, add its city, state or country after a comma, so a shared name needs no guess; other_places lists the others when a name is shared."

Changedfind_restaurant1 field changed

changedInput schema / properties / city / description

Previous value: -"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Add a qualifier when a name is shared ('Vienna, Virginia'). Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."New value: +"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Whenever the conversation shows which place is meant, include its state or country ('Vienna, Virginia'), so a shared name needs no guess. Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."

Changedrecommend2 fields changed

changedInput schema / properties / location / description

Previous value: -"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). If omitted and the query contains a location, that location is used."New value: +"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."

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

2 tool updatesSep 25, 2026

Changedexplore_area3 fields changed

changedInput schema / properties / area / description

Previous value: -"Neighborhood, city, or region name. Supports 'Shoreditch', 'Shoreditch, London', 'Central London', 'Rome', 'Chelsea, NYC'. Use comma to disambiguate neighborhoods that exist in multiple cities."New value: +"Neighborhood, city, or region name, in English or the local language. Supports 'Shoreditch', 'Shoreditch, London', 'Rome' or 'Roma', 'Wien', 'Praha', 'Montréal', 'Chelsea, NYC'. Use a comma qualifier to pick between places that share a name; other_places lists them when a name is shared."

addedOutput schema / properties / other_places

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / place_note
```
Added value: +{
+  "type": "string"
+}
```

Changedfind_restaurant4 fields changed

changedInput schema / properties / city / description

Previous value: -"City to narrow the search. Example: 'London', 'New York', 'Rome'. Recommended when the name is common."New value: +"City to narrow the search, in English or the local language ('Vienna' or 'Wien', 'Prague' or 'Praha', 'Montréal'). A neighborhood or region also works. Add a qualifier when a name is shared ('Vienna, Virginia'). Recommended when the name is common. The result says which place was used (place) and lists other places with the same name (other_places)."

addedOutput schema / properties / other_places

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / place
```
Added value: +{
+  "type": "object"
+}
```
addedOutput schema / properties / place_note
```
Added value: +{
+  "type": "string"
+}
```

1 tool updateSep 21, 2026
- Changedrecommend1 field changed
  - addedOutput schema / properties / results / items / properties / place_note
```
Added value: +{
+  "type": "string"
+}
```

1 tool updateSep 9, 2026

Changedrecommend8 fields changed

addedOutput schema / properties / candidates

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

addedOutput schema / properties / repeat_ask

Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}

addedOutput schema / properties / result_groups

Added value: +{
+  "items": {
+    "properties": {
+      "count": {
+        "type": "number"
+      },
+      "entries": {
+        "items": {
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "label": {
+        "enum": [
+          "exact",
+          "exact_within_wider_radius",
+          "likely_match_unconfirmed",
+          "nearby_any",
+          "relaxed_amenity",
+          "below_grade_floor"
+        ],
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "relaxation_steps": {
+        "items": {
+          "properties": {
+            "applied": {
+              "type": "string"
+            },
+            "field": {
+              "type": "string"
+            },
+            "label": {
+              "type": "string"
+            },
+            "original": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / results / items / properties / grade_caveat
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / results / items / properties / honored_constraints
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

addedOutput schema / properties / results / items / properties / requirements

Added value: +{
+  "items": {
+    "properties": {
+      "evidence": {
+        "type": "string"
+      },
+      "firmness": {
+        "enum": [
+          "identity",
+          "timing",
+          "amenity",
+          "preference"
+        ],
+        "type": "string"
+      },
+      "phrase": {
+        "type": "string"
+      },
+      "requirement": {
+        "type": "string"
+      },
+      "source": {
+        "enum": [
+          "stated",
+          "inferred"
+        ],
+        "type": "string"
+      },
+      "status": {
+        "enum": [
+          "confirmed",
+          "contradicted",
+          "unknown"
+        ],
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "error",
-  "no_coverage",
-  "location_required",
-  "timeout",
-  "cannot_verify"
-]New value: +[
+  "ok",
+  "error",
+  "no_coverage",
+  "location_required",
+  "timeout",
+  "cannot_verify",
+  "geo_conflict"
+]

addedOutput schema / properties / unknown_requirements

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

1 tool updateAug 30, 2026

Changedrecommend3 fields changed

addedOutput schema / properties / pool_disclosure

Added value: +{
+  "properties": {
+    "count": {
+      "type": "number"
+    },
+    "message": {
+      "type": "string"
+    },
+    "reason": {
+      "enum": [
+        "thin_pool",
+        "cuisine_relaxed"
+      ],
+      "type": "string"
+    }
+  },
+  "type": [
+    "object",
+    "null"
+  ]
+}

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "error",
-  "no_coverage",
-  "location_required",
-  "timeout"
-]New value: +[
+  "ok",
+  "error",
+  "no_coverage",
+  "location_required",
+  "timeout",
+  "cannot_verify"
+]

addedOutput schema / properties / unverifiable_attributes

Added value: +{
+  "items": {
+    "properties": {
+      "key": {
+        "type": "string"
+      },
+      "label": {
+        "type": "string"
+      },
+      "source_phrase": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

5 tool updatesAug 22, 2026
- Changedexplore_area1 field changed
  - changedOutput schema / properties / highlights / items / properties / coverage_level / enum
```
Previous value: -[
-  "full",
-  "basic"
-]New value: +[
+  "full",
+  "basic",
+  "none"
+]
```
- Changedfind_restaurant1 field changed
  - changedOutput schema / properties / results / items / properties / coverage_level / enum
```
Previous value: -[
-  "full",
-  "basic"
-]New value: +[
+  "full",
+  "basic",
+  "none"
+]
```
- Changedlookup_restaurant8 fields changed
  - addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
  - addedOutput schema / properties / restaurant / properties / address
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
  - addedOutput schema / properties / restaurant / properties / analysis_date
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
  - addedOutput schema / properties / restaurant / properties / caveats
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
  - addedOutput schema / properties / restaurant / properties / city
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
  - addedOutput schema / properties / restaurant / properties / coverage_level
```
Added value: +{
+  "enum": [
+    "full",
+    "basic",
+    "none"
+  ],
+  "type": "string"
+}
```
  - addedOutput schema / properties / restaurant / properties / preliminary_band
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
  - addedOutput schema / properties / restaurant / properties / seemor_url
```
Added value: +{
+  "type": "string"
+}
```
- Changedrecommend1 field changed
  - changedOutput schema / properties / results / items / properties / coverage_level / enum
```
Previous value: -[
-  "full",
-  "basic"
-]New value: +[
+  "full",
+  "basic",
+  "none"
+]
```
- Changedsearch_restaurants1 field changed
  - changedOutput schema / properties / results / items / properties / coverage_level / enum
```
Previous value: -[
-  "full",
-  "basic"
-]New value: +[
+  "full",
+  "basic",
+  "none"
+]
```

5 tool updatesAug 22, 2026

Changedexplore_area6 fields changed

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

addedOutput schema / properties / coverage_level

Added value: +{
+  "enum": [
+    "full",
+    "basic",
+    "none"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / description / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

addedOutput schema / properties / highlights / items / properties

Added value: +{
+  "address": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "caveats": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "city": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "coverage_level": {
+    "enum": [
+      "full",
+      "basic"
+    ],
+    "type": "string"
+  },
+  "cuisine_tags": {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  "distance_km": {
+    "type": [
+      "number",
+      "null"
+    ]
+  },
+  "grade": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "name": {
+    "type": "string"
+  },
+  "neighborhood": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "preliminary_band": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "price_level": {
+    "type": [
+      "string",
+      "null"
+    ]
+  },
+  "seemor_id": {
+    "type": "string"
+  },
+  "tldr": {
+    "type": [
+      "string",
+      "null"
+    ]
+  }
+}

addedOutput schema / properties / preliminary_count

Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / status / enum

Added value: +[
+  "ok",
+  "error",
+  "not_found"
+]

Changedfind_restaurant10 fields changed
- 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"
+  ]
+}
```
Changedlookup_restaurant5 fields changed
- changedOutput schema / properties / restaurant / properties / grade / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / restaurant / properties / grade_label / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / restaurant / properties / neighborhood / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / restaurant / properties / price_level / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / restaurant / properties / tldr / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

Changedrecommend4 fields changed

addedOutput schema / properties / results / items / properties / coverage_level

Added value: +{
+  "enum": [
+    "full",
+    "basic"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / results / items / properties / grade / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
addedOutput schema / properties / results / items / properties / preliminary_band
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / status / enum

Previous value: -[
-  "ok",
-  "error",
-  "no_coverage",
-  "location_required"
-]New value: +[
+  "ok",
+  "error",
+  "no_coverage",
+  "location_required",
+  "timeout"
+]

Changedsearch_restaurants12 fields changed
- 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"
+  ]
+}
```

1 tool updateAug 21, 2026
- Changedrecommend1 field changed
  - addedOutput schema / properties / results / items / properties / caveats
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```

5 tool updatesJul 30, 2026

Changedask_about_restaurant5 fields changed
- addedOutput schema / properties / category
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / restaurant_id
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / seemor_url
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / source
```
Added value: +{
+  "type": "string"
+}
```
Changedexplore_area4 fields changed
- addedOutput schema / properties / description
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / neighborhoods
```
Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
```
- addedOutput schema / properties / price_breakdown
```
Added value: +{
+  "type": "object"
+}
```
Changedfind_restaurant2 fields changed
- addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / total_matches
```
Added value: +{
+  "type": "number"
+}
```

Changedrecommend7 fields changed

addedOutput schema / properties / location_used
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / message
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / query_understood
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / recommendations

Removed value: -{
-  "items": {
-    "properties": {
-      "grade": {
-        "type": "string"
-      },
-      "match_reasons": {
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "name": {
-        "type": "string"
-      },
-      "relevance": {
-        "type": "string"
-      },
-      "seemor_id": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "type": "array"
-}

addedOutput schema / properties / results

Added value: +{
+  "items": {
+    "properties": {
+      "distance_km": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "grade": {
+        "type": "string"
+      },
+      "match_reasons": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "name": {
+        "type": "string"
+      },
+      "relevance": {
+        "type": "string"
+      },
+      "seemor_id": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / status / enum

Added value: +[
+  "ok",
+  "error",
+  "no_coverage",
+  "location_required"
+]

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

Changedsearch_restaurants3 fields changed
- 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"
+}
```

1 tool updateJul 13, 2026

Changedlookup_restaurant1 field changed

changedInput schema / properties / fields / description

Previous value: -"Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional scores (noise, formality, authenticity, etc.), value assessment, strengths/weaknesses."New value: +"Response detail level. 'basic' (default): grade, TL;DR, cuisine, price. 'standard': adds narrative summary, occasion fit, menu highlights, cost estimates, dietary info. 'premium': adds dimensional assessments (noise, formality, authenticity, etc.), value assessment, standout strengths/weaknesses, unique selling points."

6 tool updatesJul 6, 2026

Changedask_about_restaurant1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "answer": {
+      "type": "string"
+    },
+    "question": {
+      "type": "string"
+    },
+    "restaurant_name": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedexplore_area1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "analyzed_restaurants": {
+      "type": "number"
+    },
+    "area": {
+      "type": "string"
+    },
+    "grade_distribution": {
+      "type": "object"
+    },
+    "highlights": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "type": "string"
+    },
+    "top_cuisines": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total_restaurants": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

Changedfind_restaurant1 field changed

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"
+    }
+  },
+  "type": "object"
+}

Changedlookup_restaurant1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "restaurant": {
+      "properties": {
+        "cuisine_tags": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "grade": {
+          "type": "string"
+        },
+        "grade_label": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        },
+        "neighborhood": {
+          "type": "string"
+        },
+        "price_level": {
+          "type": "string"
+        },
+        "seemor_id": {
+          "type": "string"
+        },
+        "tldr": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedrecommend1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "recommendations": {
+      "items": {
+        "properties": {
+          "grade": {
+            "type": "string"
+          },
+          "match_reasons": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "name": {
+            "type": "string"
+          },
+          "relevance": {
+            "type": "string"
+          },
+          "seemor_id": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedsearch_restaurants1 field changed

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"
+}

Related MCP Servers

Adologyofficial
Marketing Social Media
adologyai
A
license
Not graded
quality
B
maintenance
Perplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
Updated a month ago (2026-09-11 19:20 UTC)
2
Apache 2.0
Competitor Monitor AI MCP
Marketing Research & Data AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Competitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 12 days ago (2026-10-08 01:01 UTC)
11
9 npm
MIT
Citesurf MCP
Marketing Search Monitoring
citesurf
A
license
A
quality
C
maintenance
Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
Updated 6 months ago (2026-04-23 11:46 UTC)
16
11 npm
1
MIT
industrylens-mcpofficial
Research & Data
IndustryLensOp
A
license
Not graded
quality
B
maintenance
Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
Updated 2 months ago (2026-08-17 15:55 UTC)
MIT