Search 18000+ verified restaurants and bars across 20 cities, each with a 0-100 Quality Score, venue detail, curated lists and Trip Saving
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.3/5 across 7 of 7 tools scored.
There are two pairs of nearly identical tools: `fetch` and `get_venue` both retrieve full venue records by ID, differing only in an optional long-form story; `search` and `search_venues` both perform catalog searches with overlapping scope and filtering. This creates real ambiguity about which tool to select for a given task.
Naming mixes single verbs (`fetch`, `search`) with verb_noun snake_case (`get_venue`, `list_cities`, `search_venues`). The pattern is not uniform, and synonyms like fetch/get and search/search_venues further muddy the naming convention.
Seven tools is a reasonable number for a venue discovery server. Even accounting for redundancy, the count is well within the typical range and each tool ostensibly serves a distinct operation (search, retrieve, list).
The tool surface covers the core workflows: discovering venues (search, search_venues), retrieving details (fetch, get_venue), and listing collections (list_cities, list_curated, list_new_venues). No major lifecycle operations are missing, though the redundant pairs suggest the design could have been more streamlined.
fetchFetch a Dim Hour venueAGet the full Dim Hour record for one venue by the id returned from search: description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website and Instagram.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Venue id from `search`, in the form 'city:id' e.g. 'nyc:1367' |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only and non-destructive behavior. The description adds value by enumerating the response fields (description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website, Instagram) and indicating a comprehensive retrieval. It does not cover error cases but that is acceptable given the simple read-only nature.
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, well-structured sentence that front-loads the action and resource. The list of returned fields is informative without being verbose. Every phrase contributes to understanding the tool's purpose and output.
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 (one parameter), the existing annotations, and the presence of an output schema, the description provides sufficient context for an agent to select and invoke it correctly. It clearly states the input source and the nature of the returned data.
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?
The schema already provides a thorough description of the `id` parameter, including its source (from search) and an example format. The description reiterates this source but adds no new semantic detail. Since schema coverage is 100%, a 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 uses a specific verb ('Get') and resource ('full Dim Hour record'), and clearly states the input source (id from search). It lists the contained fields, making the purpose unambiguous. However, it does not explicitly differentiate itself from the sibling tool 'get_venue', so it misses the top score.
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 a clear workflow: first call `search` to obtain an id, then use this tool to fetch the full record. This provides useful context for when to use it. It does not explicitly mention alternatives or when not to use it, so it stops short of giving full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_venueGet venue detailsAGet the full Dim Hour record for one venue: description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website, Instagram, and (for Iconic 50 venues) the long-form story.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Venue id from search_venues | |
| city | Yes | City name or key | |
| name | No | Venue name (used if id not given) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| lat | No | |
| lng | No | |
| url | Yes | |
| name | Yes | |
| tags | Yes | |
| hours | Yes | |
| phone | Yes | |
| price | No | |
| score | No | |
| story | No | |
| awards | Yes | |
| dishes | Yes | |
| iconic | No | |
| opened | No | |
| address | Yes | |
| cuisine | Yes | |
| website | Yes | |
| photoUrl | Yes | |
| trending | No | |
| city_name | Yes | |
| Yes | ||
| happy_hour | Yes | |
| highlights | No | |
| price_tier | No | |
| description | Yes | |
| reservation | Yes | |
| neighborhood | Yes | |
| other_locations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds useful conditional detail (long-form story only for Iconic 50 venues) and clarifies the record's composition, providing value beyond the structured 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 a single sentence that front-loads the main purpose and then lists fields in a dense, readable manner. It is slightly long but every word adds value, with no filler.
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 a read-only annotation, full schema coverage, and an output schema, this description is sufficiently complete for a single-record retrieval tool. It does not elaborate on error handling or sibling differentiation beyond implied usage, but those gaps are minor given existing structured metadata.
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?
All three parameters are fully described in the schema (100% coverage), and the tool description does not add extra meaning beyond labeling the record as 'full.' The schema already explains id/name/city roles, so the description contributes minimal additional parameter context.
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 fetches the full Dim Hour record for a single venue and enumerates the included fields (description, signature dishes, address, hours, etc.). This specific verb+resource pairing distinguishes it from sibling tools like search_venues or fetch.
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 for retrieving detailed records after a search, and the input schema explicitly notes the id comes from search_venues. However, it does not state when not to use it or mention alternatives for list/lightweight data, leaving room for more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_citiesList citiesAList the 20 cities Dim Hour covers, with the city key to pass to the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by stating the fixed count of 20 cities and the purpose of providing keys, which goes beyond the 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?
Single sentence, front-loaded with the verb 'List', and every word adds useful information. No redundancy or filler.
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 (0 params, output schema present, read-only), the description is complete. It tells the agent what it returns (20 cities), the format (city keys), and why it matters (for 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?
With zero parameters, the baseline is 4. The description doesn't need to explain parameter syntax, and none exist. It appropriately focuses on the output.
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 lists the 20 cities covered by Dim Hour, which is a specific verb and resource. It also explains the purpose of the output (the city key to pass to other tools), which distinguishes it from sibling tools like list_curated or list_new_venues.
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 notes that the city key is passed to other tools, implying this is a prerequisite/support tool. It doesn't offer explicit alternatives or when-not-to-use guidance, but for a simple list tool 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.
list_curatedList curated listsADim Hour's hand-curated themed lists for a city (e.g. 'Unmarked Doors' speakeasies). Without list_id: returns all list titles. With list_id: returns that list's venues with editorial notes.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or key | |
| list_id | No | A list id from the no-arg call |
| Name | Required | Description |
|---|---|---|
| id | No | |
| city | Yes | |
| note | No | |
| lists | No | |
| title | No | |
| venues | No | |
| subtitle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral detail beyond annotations: the dual-mode return behavior (titles vs venues with editorial notes) and the fact that lists are hand-curated. This enriches the agent's understanding of what to expect from the call.
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-loaded with the core purpose and example, then succinctly explaining behavior for both invocation modes. No filler or redundancy; every clause contributes useful 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?
With only two parameters (one required), an output schema, and annotations indicating a safe read operation, the description covers both call variants and notes the presence of editorial notes. It does not need to describe return fields because the output schema exists. The information is complete for an agent to select and invoke the tool effectively.
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?
The schema describes city as 'City name or key' and list_id as 'A list id from the no-arg call'. The description reinforces and expands this by explaining that list_id changes the output from list titles to venues with editorial notes, and that list_id comes from the no-arg call. This adds meaningful semantic context beyond the schema, even though schema coverage is 100%.
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 function: listing Dim Hour's hand-curated themed lists for a city. It distinguishes from siblings like list_cities and list_new_venues by specifying 'hand-curated themed lists' and provides a concrete example ('Unmarked Doors' speakeasies). It also explains the two modes (with and without list_id), making the purpose fully unambiguous.
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 provides clear context on how to use the tool: call without list_id to get all list titles, and with list_id to get venues with editorial notes. It implies using this tool when curated lists are needed, but does not explicitly mention when to avoid it or name alternative sibling tools for other list types. Thus it gives clear usage context but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_new_venuesList new venuesAVenues recently added to the Dim Hour catalog — across all 20 cities or one city. Use for 'what's new on Dim Hour' / new-opening alerts / weekly digests. Dates earlier than 2026-06-06 are estimates reconstructed from history.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city name or key; omit for all cities | |
| days | No | Look-back window in days, default 30 (max 90) | |
| limit | No | Max results, default 25 |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| venues | Yes | |
| showing | Yes | |
| total_new | Yes | |
| window_days | Yes | |
| feed_generated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a meaningful behavioral caveat: dates before 2026-06-06 are estimates reconstructed from history, which is valuable for interpreting results. This goes beyond the 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 concise and front-loaded with purpose, followed by a useful data-quality caveat. Every sentence earns its place; no fluff or redundancy with schema or annotations.
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 simple read-only nature, complete schema, annotations, and presence of an output schema, the description covers all necessary context. It communicates scope, usage, and a critical data caveat without needing to explain return values (handled by output schema) or defaults (handled by 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 parameters are already fully documented. The description adds minor context (e.g., 'across all 20 cities') but doesn't provide significant new parameter semantics beyond the 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?
The description clearly identifies the tool as listing venues recently added to the Dim Hour catalog, with scope across all 20 cities or a single city. It distinguishes itself from sibling tools like search_venues or list_curated by focusing on newly added venues.
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 use cases ('what's new on Dim Hour', new-opening alerts, weekly digests), providing clear context for when to use the tool. It doesn't explicitly mention alternatives or exclusions, but the use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Dim HourASearch Dim Hour's curated restaurant, bar and venue catalog across all 20 cities. Returns ranked venues with a dimhour.com link for each. Use for questions about where to eat or drink — by cuisine, dish, neighborhood, city, vibe, or award.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for, e.g. 'best ramen in NYC', 'michelin dallas', 'rooftop bar miami' |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns 'ranked venues with a dimhour.com link for each' and clarifies the catalog is curated across all 20 cities. This goes beyond just repeating 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, front-loaded with the main purpose in the first sentence, and the second sentence gives usage guidance. No wasted words; every sentence contributes.
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 search tool with one parameter and an output schema, the description is complete: what it searches (curated catalog, 20 cities), what it returns (ranked venues with links), and when to use it (food/drink questions by various facets). No major gaps.
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% – the 'query' parameter has a description with examples. The tool description itself adds nothing about the parameter beyond what the schema already provides, so the baseline 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 states a specific verb ('Search') and resource ('Dim Hour's curated restaurant, bar and venue catalog'), and adds scope details ('across all 20 cities'). It clearly differentiates itself from the broad sibling 'search_venues' by emphasizing 'curated' catalog and providing a dimhour.com link, but it does not explicitly name alternatives or contrast with siblings like 'search_venues'.
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 gives clear usage context: 'Use for questions about where to eat or drink — by cuisine, dish, neighborhood, city, vibe, or award.' This is explicit and helpful, but it does not mention when not to use the tool or point to alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_venuesSearch venuesASearch Dim Hour's curated restaurant/bar/venue catalog. Pass city to search one city, or OMIT city to search all 19,071 venues across every city at once (e.g. 'best ramen anywhere', 'michelin spots'). Returns ranked matches with score (0-100 quality), price tier, neighborhood, happy-hour info, and a dimhour.com link. Use free-text query for cuisine, dish, vibe, or name; combine with filters.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name or key, e.g. 'NYC', 'dallas'. OMIT to search ALL cities at once. | |
| limit | No | Max results, default 10 | |
| query | No | Free text matched against name, cuisine, neighborhood, tags, dishes, description | |
| cuisine | No | Filter to a cuisine (substring match) | |
| max_price | No | Max price tier 1-4 ($-$$$$) | |
| min_score | No | Minimum quality score 0-100 | |
| iconic_only | No | Only 'Iconic 50' venues (NYC has these today) | |
| neighborhood | No | Filter to a neighborhood (substring match) | |
| trending_only | No | Only trending venues | |
| awards_contains | No | Only venues whose awards field matches, e.g. 'michelin', 'james beard', 'bib gourmand' | |
| happy_hour_only | No | Only venues with happy hour info |
| Name | Required | Description |
|---|---|---|
| city | No | |
| note | No | |
| scope | No | |
| venues | Yes | |
| showing | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: the tool returns ranked matches with score, price tier, neighborhood, happy-hour info, and a dimhour.com link, and that omitting 'city' searches across all cities. This goes beyond what annotations provide.
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 sentences with zero fluff. It front-loads the core action, immediately explains the crucial city-vs-omission behavior, then covers return values and search guidance. Every sentence earns its place, making it easy to scan.
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 tool with 11 optional parameters and an existing output schema, the description covers the essential behavior (scope, return fields, search approach) without needed to repeat parameter details. It does not mention rate limits or auth, but read-only annotations and the output schema cover practical calling needs. Minor gaps like pagination are already handled by the 'limit' parameter description.
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 all parameters are documented. The description adds extra semantic value by explaining the special behavior of 'city' (omit to search all cities with examples) and advising that 'query' accepts free text for cuisine, dish, vibe, or name. This is more than a repetition of 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 uses a specific verb ('Search') and a specific resource ('Dim Hour's curated restaurant/bar/venue catalog'), immediately distinguishing it from the generic sibling 'search'. It also names the return contents (score, price tier, neighborhood, happy-hour info, link), leaving no ambiguity about what the tool accomplishes.
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 gives concrete usage guidance: pass 'city' to search one city, omit it to search all 19,071 venues, and combine free-text 'query' with filters. It does not explicitly contrast with sibling tools like the generic 'search' or 'get_venue', but the curated-catalog scope and behavior are clear enough to infer when this is the right choice.
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!
