Discover 356K+ restaurants in 20 countries: search, reviews, cultural context, time-based offers.
Make a reservation at a Flow-discounted time slot. Phone must be E.164 (e.g. +34911234567). To make retries safe, send the same Idempotency-Key HTTP header on retries (any UUID); replays within 24h return the original reservation. Rate limited to 5 reservations per email per day and 10 attempts per IP per minute.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Restaurant URL slug. | |
| notes | No | ||
| guest_name | Yes | ||
| party_size | No | ||
| guest_email | Yes | ||
| guest_phone | Yes | E.164 format, e.g. +34911234567. | |
| yield_offer_id | Yes | Offer ID returned by get_flow_offers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency and rate limits, which are important behavioral traits. No annotations provided, so description carries the burden; missing failure behavior and authorization details.
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 focused sentences, each adding distinct value. No 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?
Covers purpose, idempotency, rate limits, and phone format. Lacks description of return values (no output schema) and when to use relative to other 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?
Only 43% schema coverage; description clarifies phone format and mentions idempotency header but does not explain guest_name, notes, or other parameters beyond what 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?
Clearly states it makes a reservation at a Flow-discounted time slot. Distinct from siblings like get_flow_offers which provides offers.
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 phone format, idempotency retry, and rate limit info but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find restaurants near a famous landmark (monument, museum, park). Returns landmark info from Wikidata + nearby restaurants sorted by walking distance. Examples: 'Sagrada Familia', 'Colosseum', 'Central Park', 'Tour Eiffel'.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City hint for landmark disambiguation. | |
| limit | No | ||
| radius | No | Search radius in meters. | |
| landmark | Yes | Landmark name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it returns landmark info and nearby restaurants sorted by walking distance, but lacks details on behavior when landmark is not found, authentication, or rate limits. Adequate but not comprehensive.
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 and output, second provides examples. No fluff, front-loaded, and every sentence earns its place.
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 no output schema, the description mentions what is returned but does not specify format, pagination, or filtering. For a simple tool with 4 parameters, it is minimally adequate but could be more 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 description coverage is 75%, and the description adds value by listing example landmarks and mentioning 'city hint' for disambiguation. However, it does not explain the semantics of limit, radius, or how the city parameter is used beyond what the schema provides. Baseline 3 with slight positive increment.
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 finds restaurants near a famous landmark, specifies return includes landmark info and restaurants sorted by walking distance, and provides examples. This distinguishes it from sibling 'search_restaurants' which is 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 implies usage for landmark-relative searches via examples, but does not explicitly state when to use this tool vs alternatives like 'search_restaurants' or when not to use it. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cultural context around a restaurant: nearby monuments, museums, parks, historical sites with distance and heritage status. Powered by Wikidata.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Restaurant URL slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides basic behavioral disclosure: it uses Wikidata and returns distance and heritage status. However, it lacks details on response structure, pagination, or potential latency, which would be important for an AI agent.
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?
A single, front-loaded sentence that efficiently conveys the tool's purpose and key features with no extraneous 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 there is no output schema, the description partially covers what is returned (monuments, museums, parks, historical sites with distance and heritage status). However, it does not specify the format, ordering, or any limits, leaving some ambiguity.
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% with a clear description for the only parameter 'slug'. The tool description does not add additional meaning beyond the schema, so it meets the baseline expectation.
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 'Get' and the resource 'cultural context around a restaurant', listing specific types (monuments, museums, parks, historical sites) and data source (Wikidata), effectively distinguishing from siblings like get_restaurant_details or search_restaurants.
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 such as find_restaurants_near_landmark or search_restaurants. There are no usage scenarios or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
POS.DO Flow time-based offers for a restaurant. Off-peak hours have bigger discounts. Returns time slots with discount percentages and remaining covers. Tagline: 'Tu hora, tu precio'.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date YYYY-MM-DD (default: today). | |
| slug | Yes | Restaurant URL slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return structure (time slots, discounts, covers) and indicates a read-only nature via the verb 'get'. It adds value by explaining the 'off-peak discount logic', but does not detail potential side effects, auth needs, or rate 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 plus a tagline, all essential. It is front-loaded with the tool's purpose, then details output and logic. Every sentence adds distinct value without 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?
For a 2-parameter tool with no output schema, the description adequately covers the concept, input purpose, and output format. It could be enhanced by mentioning the typical use case sequence (e.g., use before booking), but overall it provides sufficient context given the simplicity.
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% (both 'slug' and 'date' are described). The description enriches understanding by explaining that the tool adjusts discounts based on off-peak timing, which goes beyond the schema's technical definitions. It provides business context for the parameters.
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 returns 'time-based offers for a restaurant' with off-peak discounts, and specifies the output: 'time slots with discount percentages and remaining covers'. It distinguishes from siblings like 'book_flow_reservation' (a booking action) and 'find_restaurants_near_landmark' (location search), as it focuses solely on offering details.
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 implies use when checking discounts ('Off-peak hours have bigger discounts'), but lacks explicit guidelines on when to use versus alternatives (e.g., before booking or comparing restaurants). No direct comparison with siblings or conditions for non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full profile of a restaurant by URL slug. Returns name, address, coordinates, rating, reviews count, phone, opening hours, photos, services, cuisine type, price level, current Flow offers, and cultural context.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Restaurant URL slug. Example: 'anima-e-cuore-osteria-bilbao'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description lists returned fields but does not disclose behavioral traits like authentication requirements, rate limits, or side effects. It is a read operation but not explicitly marked.
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. Front-loaded with verb and resource, then enumerates returned data efficiently.
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 a single required parameter and no output schema, the description is fairly complete. It lists return fields but could mention error conditions or edge 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%; the description does not add extra meaning beyond what the schema already provides for the 'slug' parameter. Baseline score of 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?
The description clearly states 'Get the full profile of a restaurant by URL slug' and lists the specific data returned. It distinguishes from siblings like get_restaurant_reviews (only reviews) and get_flow_offers (only offers).
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?
It implies use when full restaurant details are needed, but does not explicitly state when not to use it or mention alternatives. Sibling tools exist for specific subsets (e.g., reviews, offers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated reviews for a restaurant. Filter by star rating, sort by date or rating. Returns review text, author, rating, date, photos, language, owner response, and rating distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Restaurant URL slug. | |
| sort | No | recent | |
| limit | No | ||
| offset | No | ||
| rating | No | Filter by exact star rating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pagination (limit, offset), sorting, and filtering capabilities, but does not explicitly state read-only behavior, authentication needs, or rate limits. The name 'get' implies safety, but explicit disclosure is missing.
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-loaded with action and key capabilities, followed by a concise list of return fields. No superfluous content.
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 covers primary functionality (pagination, filter, sort) and return fields, but lacks mention of response structure (e.g., total count or pagination token) and does not clarify how to interpret the 'rating distribution' field. Adequate but not exhaustive.
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 only 40% (slug and rating have descriptions). The description adds meaning for 'sort' and 'rating' parameters by stating 'Filter by star rating, sort by date or rating', but does not describe 'limit', 'offset', or 'slug' in detail. Partial compensation, but not full.
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 'Get paginated reviews for a restaurant' with specific actions: filtering by star rating, sorting by date or rating. It distinguishes from siblings like 'get_restaurant_details' and 'search_restaurants' by focusing on reviews and pagination.
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 implies usage for retrieving reviews, but does not explicitly compare to sibling tools or provide when-to-use vs. when-not-to-use guidance. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search restaurants in a specific city. Filter by cuisine type, price range, and features like outdoor seating, WiFi, delivery. Returns up to 20 results with name, rating, cuisine, price range, address, coordinates, photo, amenities, and current Flow offers.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name. Examples: 'Madrid', 'New York', 'Milano', 'Barcelona'. | |
| limit | No | ||
| query | No | Free-text search: cuisine, occasion, features (e.g. 'romantic italian terrace'). | |
| cuisine | No | Cuisine filter. Examples: 'italian', 'mexican', 'sushi', 'spanish', 'indian'. | |
| features | No | Comma-separated feature filters: terrace, wifi, parking, delivery, accessible. | |
| price_max | No | Max price level 1=budget, 4=fine dining. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears the full burden. It discloses that the tool returns up to 20 results with specific fields (name, rating, cuisine, etc.), which is transparent. It does not mention rate limits or authorization, but for a read-only search this is acceptable.
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 clear sentences with no unnecessary words. It front-loads the core purpose and efficiently lists filters and return fields.
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?
Despite no output schema, the description enumerates return fields. It covers all parameters meaningfully, specifies result limit, and provides enough context for an AI agent to use the tool correctly given the tool's moderate 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 coverage is 83%, and the description adds value by explaining filters like 'comma-separated features' and 'free-text search for cuisine/occasion'. It also specifies the default limit and max results, enhancing the schema's information.
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 restaurants in a specific city with multiple filters. It distinguishes itself from sibling tools like find_restaurants_near_landmark and get_restaurant_details by specifying city-based search and return fields.
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 indicates using this tool for searching restaurants by city and filters. It does not explicitly state when not to use it or compare with siblings, but the context of city-based search is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
book_flow_reservationfind_restaurants_near_landmarkget_cultural_context_around_restaurantget_flow_offersget_restaurant_detailsget_restaurant_reviewssearch_restaurantsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Search nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
OSM-sourced local business data across 9 niches — cuisine, dietary options, delivery, accessibility.
Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: reservation booking, landmark-based search, cultural context, flow offers, restaurant details, reviews, and general search. No overlapping functionalities.
All tools follow a consistent verb_noun pattern (e.g., book_flow_reservation, get_restaurant_details), making it easy to infer actions.
Seven tools cover the core domain (search, details, reviews, offers, booking, cultural context) without being excessive or insufficient.
Core workflows are covered, but the set lacks reservation cancellation or update functionality, which is a minor gap for a booking system.
