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.1/5 across 6 of 6 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose: ask_about_restaurant for specific questions, explore_area for area statistics, find_restaurant for name-based search, lookup_restaurant for details by ID, recommend for personalized recommendations, and search_restaurants for location-based search. No significant overlap.
All tool names use consistent snake_case and follow a verb_noun pattern (ask_about, explore, find, lookup, recommend, search). There is no mixing of conventions.
With 6 tools, the set is well-scoped for a restaurant intelligence server. Each tool serves a specific function without being overwhelming or too sparse.
The tool surface covers the key use cases: finding restaurants, retrieving details, asking questions about specific restaurants, exploring area-level data, and getting personalized recommendations. No obvious gaps for a read-only intelligence system.
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 agent knows it's a safe read operation. The description adds context about using real reviews and menu data, but does not disclose other behaviors like response format or limits.
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: first sentence states purpose and examples, second sentence states prerequisite. No wasted words, well-structured.
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?
The description sufficiently covers purpose, prerequisites, and typical usage. Output schema exists (not shown) which presumably covers return values, so no need to describe them. Minor gap: no mention of answer type (e.g., text or structured).
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 the schema already documents both parameters. The description does not add additional meaning beyond summarizing the question examples, so it meets the baseline.
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 is for asking specific questions about a restaurant based on reviews and menus, and gives examples. It is distinct from sibling tools like find_restaurant (search) and recommend (suggestions).
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 requires a restaurant_id from find_restaurant or search_restaurants, providing clear prerequisites. It does not explicitly state when not to use, but the examples imply appropriate use cases.
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, destructiveHint=false, idempotentHint=true, openWorldHint=false. Description adds that it returns aggregate statistics, which is consistent and adds context beyond annotations.
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: first states purpose, second provides usage guidance and alternative. No fluff, well-organized.
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 annotations and output schema exist, the description covers usage, parameters, and alternatives completely. No missing information.
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% with a good description for the 'area' parameter. The description adds examples and disambiguation advice, providing extra value.
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 it provides aggregate dining statistics for an area, and explicitly distinguishes from sibling tools by stating it's not for finding specific restaurants or personal recommendations.
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 when to use ('area-level context') and when not to use ('NOT for finding a specific restaurant'), and points to the 'recommend' tool as an alternative.
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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context that the tool returns Seemor IDs for use with lookup_restaurant, which is consistent with a read-only operation. 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 three concise sentences with no wasted words. It front-loads the core purpose, then provides the return value, and ends with a practical usage tip.
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 (context signal: Has output schema: true), the description covers the essential information: what it does, how to use it, and how the results integrate with sibling tools. Slightly lower because it does not mention the limit parameter or the default value, but the schema covers those.
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% with descriptions for all three parameters. The description adds value by explaining the significance of the returned IDs and reinforcing the city parameter's purpose, going 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 verb 'Find', resource 'restaurants', and what it returns (Seemor IDs). It distinguishes from sibling tools like lookup_restaurant and search_restaurants by specifying that this tool is for name-based search and returns IDs for further detail retrieval.
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 tool provides a clear usage tip: 'Use the city parameter to disambiguate common names.' It implicitly distinguishes from siblings by focusing on name search, but does not explicitly state when to use alternatives like explore_area or ask_about_restaurant.
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 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
| 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, and destructiveHint, so description adds value by explaining how fields parameter controls detail level. 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 front-load purpose and usage guidance without any extraneous detail.
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, needn't detail returns. Covers parameter usage, prerequisite sibling tools, and response detail levels. Fully adequate for the tool's complexity.
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% and fully documents both parameters with enum explanations. Description adds only a brief reiteration of the fields option, not new meaning.
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 lookup by Seemor ID, lists returned details (grade, summary, cuisine, neighborhood), and distinguishes from siblings like search_restaurants and find_restaurant.
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 advises using search_restaurants or find_restaurant first to get IDs, and mentions the fields parameter for richer data.
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?
Annotations indicate read-only behavior, and description adds useful context: ranked results, relevance levels, match reasons, and response time of 3-8 seconds. No contradictions with annotations.
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?
Extremely concise: three sentences covering purpose, method, and usage tip. No unnecessary information; every sentence adds value.
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 adequately informs what the tool does, what inputs are needed, and high-level output characteristics. Could mention optional parameters like limit, but these are already in 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 has 100% parameter coverage, so baseline is 3. Description reinforces the importance of including location but adds minimal new meaning beyond the schema 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 tool provides personalized restaurant recommendations based on natural language queries, using various analyses. Distinguishes from siblings like search_restaurants by emphasizing personalization and ranking, but could be more explicit about the difference.
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 specific guidance to include location in query or use location parameter. However, does not explicitly state when to use this tool over alternatives like find_restaurant or search_restaurants, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_restaurantsSearch RestaurantsBRead-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 indicate read-only, idempotent, non-destructive behavior. The description adds that results are graded and ranked with cuisine, price level, and Seemor analysis summaries, but no disclosure of edge cases (e.g., no results, pagination limits).
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?
Single sentence, front-loaded with action and output summary. No unnecessary 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?
Output schema exists, so description need not detail returns. It adequately summarizes output content (graded, ranked, attributes). Could mention default radius or required location, but schema covers that.
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?
Input schema has 100% description coverage, so baseline is 3. The description mentions 'cuisine, price level' but adds no new parameter-level details 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 it searches for restaurants near a location and returns graded, ranked results with specific attributes. This differentiates from siblings like 'lookup_restaurant' (likely by ID) and 'recommend' (personalized), though not explicitly.
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?
No guidance on when to use this tool versus alternatives like 'find_restaurant' or 'explore_area'. The description only states what it does, without context for selection.
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!