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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored. Lowest: 3.7/5.
Each tool targets a distinct operation: ask_about_restaurant for Q&A, explore_area for area statistics, find_restaurant for name search, lookup_restaurant for ID details, recommend for personalized suggestions, and search_restaurants for location search. No overlap.
All tool names follow a clear verb_noun pattern in snake_case (ask_about_restaurant, explore_area, find_restaurant, lookup_restaurant, recommend, search_restaurants). Naming style is uniform and descriptive.
With 6 tools, the set is well-scoped for a restaurant intelligence server. It covers search, lookup, recommendation, area analysis, and Q&A without unnecessary bloat or missing essentials.
The tool surface covers the core domain: finding restaurants by name/location, retrieving details, getting recommendations, exploring areas, and asking specific questions. No obvious gaps for the stated purpose.
Available Tools
6 toolsask_about_restaurantAsk About RestaurantARead-onlyInspect
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.
| 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
| Name | Required | Description |
|---|---|---|
| answer | No | |
| status | No | |
| question | No | |
| restaurant_name | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is read-only. The description adds value by specifying that answers are 'based on analysis of real reviews and menu data', which gives insight into the behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and contains no unnecessary words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two string parameters and an output schema (which handles return values), the description is complete. It covers purpose, prerequisites, examples, and links to related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by providing example questions for the 'question' parameter and explaining how to obtain the 'restaurant_id' via sibling tools. This aids an agent in forming valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: asking a specific question about a restaurant based on real reviews and menu data. It provides concrete examples and distinguishes from sibling tools like find_restaurant and search_restaurants by requiring their output as input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite (needs restaurant_id from find_restaurant or search_restaurants) and lists common question types. It could be more explicit about when not to use this tool vs lookup_restaurant or recommend, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_areaExplore AreaARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Neighborhood, city, or region name. Supports 'Shoreditch', 'Shoreditch, London', 'Central London', 'Rome', 'Chelsea, NYC'. Use comma to disambiguate neighborhoods that exist in multiple cities. |
Output Schema
| Name | Required | Description |
|---|---|---|
| area | No | |
| status | No | |
| highlights | No | |
| top_cuisines | No | |
| total_restaurants | No | |
| grade_distribution | No | |
| analyzed_restaurants | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context about the aggregate nature of results and what is included (e.g., top neighborhoods, highlighted restaurants). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the core purpose and include critical usage guidance, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently explains the tool's purpose and behavior without needing to detail return values. It is complete for a read-only aggregate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'area'. The description adds value by providing example values and guidance on using commas to disambiguate neighborhoods in multiple cities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb+resource: 'Get aggregate dining statistics for a neighborhood, city, or region.' It lists concrete output types (cuisine breakdown, grade distribution, etc.) and distinguishes from sibling tools like recommend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (area-level context) and when not to (finding specific restaurant or personal recommendation), with a direct reference to the alternative tool 'recommend'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_restaurantFind RestaurantARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to narrow the search. Example: 'London', 'New York', 'Rome'. Recommended when the name is common. | |
| 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
| Name | Required | Description |
|---|---|---|
| status | No | |
| results | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds that it returns Seemor IDs (not full details) and suggests next steps. Could be more explicit about return format (e.g., list of names and IDs), but value added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose, immediate clarity on usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not cover return format. It adequately covers the tool's role in a workflow (passing IDs to lookup_restaurant) and mentions the city parameter. However, it could hint at default limit or scope of search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds that the city parameter disambiguates common names and that name supports partial matches, providing practical usage context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds restaurants by name and returns Seemor IDs for further use. It distinguishes from siblings like explore_area (location-based) and recommend (criteria-based), but does not clearly differentiate from the similarly named search_restaurants sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use the city parameter for disambiguation and mentions that results can be passed to lookup_restaurant for full details. However, it does not mention when to use explore_area or recommend, or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_restaurantLook Up RestaurantARead-onlyIdempotentInspect
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). Use search_restaurants or find_restaurant first to get restaurant IDs.
| 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 scores (noise, formality, authenticity, etc.), value assessment, strengths/weaknesses. | |
| restaurant_id | Yes | Seemor restaurant ID (UUID). Get IDs from search_restaurants results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| restaurant | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the description doesn't need to cover safety. Description adds that it returns specific fields and the fields parameter can request richer data, which adds some context beyond annotations but is not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, key information front-loaded. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal) and annotations cover safety, the description provides a sufficient overview of what the tool returns and how to use it. It is complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully describes both parameters. The description mentions using the fields parameter for richer data, which adds minimal value beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (look up), resource (specific restaurant by Seemor ID), and lists returned fields (grade, summary, cuisine, neighborhood). Distinguishes from siblings by directing to use search_restaurants or find_restaurant first to obtain IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool: after obtaining restaurant IDs from search_restaurants or find_restaurant. Does not specify when not to use it, but the prerequisite advice is clear and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommendGet RecommendationsARead-onlyInspect
Get personalized restaurant recommendations based on a natural language query. Uses cuisine, occasion, ambiance, price, and dimensional analysis to find the best matches. Returns ranked results with relevance levels and match reasons in 3-8 seconds. Include a location in your query or provide the location parameter.
| 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 near me for a celebration'. Include the location in your query OR provide latitude/longitude. | |
| latitude | No | 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. | |
| 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). If omitted and the query contains a location, that location is used. | |
| longitude | No | Longitude of search center. Must be provided with latitude. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | No | |
| recommendations | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses use of cuisine, occasion, ambiance, price, dimensional analysis, ranked results with relevance levels, and response time (3-8 seconds). Complements annotations (readOnlyHint true) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. Every sentence adds value: purpose, method, output, and guidance. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers core functionality, input guidance, and performance. No gaps given complexity—handles all parameter nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains location vs query interplay, example queries, and priority rules. Schema coverage is 100%, so description enhances understanding of how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get personalized restaurant recommendations based on a natural language query', with specific verb 'get' and resource 'personalized restaurant recommendations'. It distinguishes from siblings by emphasizing natural language and personalization, not just search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on including location in query or using location parameter. Implicitly suggests use for vague queries needing personalization, but lacks explicit comparison to siblings like 'search_restaurants'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_restaurantsSearch RestaurantsARead-onlyIdempotentInspect
Search for restaurants near a location. Returns graded, ranked results with cuisine, price level, and Seemor analysis summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 | Yes | Latitude of the search center (-90 to 90). | |
| longitude | Yes | Longitude of the search center (-180 to 180). | |
| 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
| Name | Required | Description |
|---|---|---|
| total | No | |
| status | No | |
| results | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that results are 'graded, ranked' and include summaries, but does not disclose additional behaviors like pagination, rate limits, or what happens with no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, moderately sized sentence that efficiently conveys purpose and output. No unnecessary words, but could be slightly more structured (e.g., listing key aspects).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (8 parameters, full description coverage) and annotations, the description is adequate. It explains the tool's purpose and what it returns. However, it does not mention the filtering parameters (cuisine, price, grade) or the search radius, which are available in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description does not add any additional meaning to the parameters beyond what is already in the schema. It mentions 'cuisine, price level' in the output, but not in a way that clarifies parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search', the resource 'restaurants', and the context 'near a location'. It specifies that results are 'graded, ranked' and include 'cuisine, price level, and Seemor analysis summaries', which distinguishes it from sibling tools like 'find_restaurant' (likely for a single restaurant) and 'explore_area' (more general).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It leaves the usage context implied: for searching multiple restaurants near a location. No 'when-not' or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!