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.
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.
Average 4.4/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: find by name, search by location, lookup by ID, ask questions, explore area, and get recommendations. No overlapping functionalities that would confuse an agent.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., find_restaurant, lookup_restaurant, explore_area), with 'recommend' as the sole verb-only name, still fitting the pattern.
With 6 tools, the set is well-scoped for a restaurant intelligence server. Each tool covers a core operation without redundancy or excessive granularity.
The tool surface covers all key tasks: searching (by name and location), retrieving details, asking specific questions, getting area-level insights, and receiving personalized recommendations. No obvious gaps for the stated domain.
ask_about_restaurantAsk About RestaurantAAsk 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. |
| Name | Required | Description |
|---|---|---|
| answer | No | |
| source | No | |
| status | No | |
| message | No | |
| category | No | |
| question | No | |
| seemor_url | No | |
| restaurant_id | No | |
| restaurant_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that answers are based on analysis of reviews and menu data, which gives insight into the tool's behavior without contradicting 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, no wasted words. Essential information is front-loaded and efficiently communicated.
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 tool's simplicity, full schema coverage, presence of output schema, and clear annotations, the description is complete. It adds the necessary guidance on parameter sourcing and typical use cases.
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 both parameters are already documented. The description adds extra context: restaurant_id must come from specific tools, and provides example questions, improving agent understanding.
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 asks questions about a restaurant using reviews and menu data, and provides concrete examples. It implicitly distinguishes from siblings like find_restaurant and 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?
The description explains that a restaurant_id from find_restaurant or search_restaurants is required and gives example questions, providing useful context for when to use. Does not explicitly state when not to use, but sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explore_areaExplore AreaAGet 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. |
| Name | Required | Description |
|---|---|---|
| area | No | |
| status | No | |
| message | No | |
| highlights | No | |
| description | No | |
| top_cuisines | No | |
| neighborhoods | No | |
| price_breakdown | No | |
| total_restaurants | No | |
| grade_distribution | No | |
| analyzed_restaurants | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so no behavioral surprises. Description adds context about aggregate results but does not contradict 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 concise sentences that first state what the tool does, then provide clear usage guidance. No redundant or irrelevant 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?
Given the output schema exists (not shown) and low complexity (1 required parameter), the description fully covers what the tool needs: the area, the return aggregates, and the usage context.
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 clear parameter description. Description adds examples and disambiguation hint (comma-separated city names), going beyond schema but not fully necessary.
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 returns aggregate dining statistics for a geographic area, listing specific outputs like cuisine breakdown and grade distribution. Distinguishes from siblings by explicitly stating it is NOT for finding a specific restaurant or personal recommendation.
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 ('find me a quiet Italian'), 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 RestaurantAFind 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). |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| results | No | |
| total_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it returns Seemor IDs, which is useful context. 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?
The description is two sentences long, front-loads the core action and return value, and adds a single usage hint. Every word serves a purpose with 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?
Given the presence of an output schema and well-documented input schema, the description covers the key functionality and integration with sibling tools. It does not explain the limit parameter's default, but the schema fills that gap, making it sufficiently complete.
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 all parameters and their meanings. The description mentions using city to disambiguate, but this is already in the parameter description. No additional semantic depth beyond what the schema provides.
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 'Find restaurants by name' and distinguishes the tool from sibling lookup_restaurant by noting that returned Seemor IDs can be passed to that tool for full details. This provides a specific verb and resource, differentiating it effectively.
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 advises using the city parameter to disambiguate common names, implying when to use it. It also hints at the workflow by suggesting passing IDs to lookup_restaurant, but it does not explicitly state when not to use this tool or list alternatives beyond that sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_restaurantLook Up RestaurantALook 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. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| restaurant | No |
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 RecommendationsAGet 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. Requires a location: include one in your query (e.g. "in Soho"), or provide the location parameter, or provide latitude/longitude. If none of those is present, the tool returns a location_required refusal instead of guessing a city.
| 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. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| results | No | |
| location_used | No | |
| query_understood | No | |
| total_candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the agent knows it is safe. The description adds behavioral details: returns ranked results with relevance levels and match reasons, a response time of 3-8 seconds, and a specific refusal behavior when location is missing. 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?
The description is compact, with only a few sentences that front-load the core purpose, then detail requirements and behavior. Every sentence adds necessary information without redundancy or fluff.
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 tool's moderate complexity, the description covers location handling, result ranking, response time, and a key error case. An output schema exists, so return values are documented separately. Minor omissions include pagination details beyond limit, but overall it is sufficiently complete for an agent to use effectively alongside sibling context.
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%, providing baseline documentation. The description adds value by explaining the interplay between query, location, latitude, and longitude—e.g., location takes priority for disambiguation, and refusal if none provided. This clarifies parameter coordination beyond the individual 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?
The description clearly states it provides personalized restaurant recommendations based on a natural language query, mentioning specific dimensions like cuisine, occasion, ambiance, and price. This differentiates it from sibling tools such as search_restaurants or find_restaurant, which are likely more structured or exact-match based.
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 clearly explains the location requirement, offering three ways to specify it, and warns of a location_required refusal if absent. However, it does not explicitly state when to use this tool over alternatives like search_restaurants or explore_area, though the context of siblings and the personalized recommendation focus provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_restaurantsSearch RestaurantsASearch 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 "$$$$". |
| Name | Required | Description |
|---|---|---|
| status | No | |
| message | No | |
| results | No | |
| total_in_area | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and destructiveHint=false, so description adds value by explaining that results are graded and ranked, and include Seemor analysis summaries. This provides behavioral context beyond annotations, though 'Seemor analysis' could be clarified.
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 efficiently conveys purpose, results, and key attributes. No wasted words; front-loaded with key 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?
Given 8 parameters fully described in schema, no nested objects, and an output schema exists, the description adequately covers overall tool behavior. It explains what the tool returns, though a brief note on sorting/ranking would be helpful.
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 parameters are well-documented structurally. Description mentions return includes cuisine, price_level, and analysis, which aligns with filter params, but does not add significant meaning beyond schema. Baseline 3 is appropriate.
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 it searches for restaurants near a location, returns graded, ranked results with specific attributes (cuisine, price, Seemor analysis). This distinguishes it from sibling tools like 'find_restaurant' (likely single restaurant lookup) and 'explore_area' (broader exploration).
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?
Description implies usage for location-based restaurant search, but does not explicitly state when to use this vs alternatives like 'ask_about_restaurant' or 'recommend'. No when-not or alternative mentions.
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.
No comments yet. Be the first to start the discussion!
