Superseded by the canonical Dim Hour connector at https://glama.ai/mcp/connectors/com.dimhour.mcp/dim-hour (same server on its branded domain).
Search nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
Scored across 7 tools
fetch and get_venue are nearly identical, both retrieving a full venue record by id, with get_venue only adding a story for Iconic 50 venues. Similarly, search and search_venues both search the catalog across all cities, with search_venues adding filters and single-city support, making selection ambiguous.
Names mix bare verbs (fetch, search), verb_noun with _venue(s) (get_venue, search_venues), and list_noun (list_cities, list_curated, list_new_venues). The list_* pattern is consistent, but overall conventions vary, though still readable.
Seven tools is well within the typical 3-15 range for a venue discovery service. The count is appropriately scoped, with no excessive bloat.
The tool set covers search, venue details, city listing, curated lists, and new venues—core workflows for a catalog. A minor gap is the lack of a direct way to list all venues without a search query, but this is workable.
Get 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the list of returned fields, which is useful but does not describe potential errors, rate limits, or other behavioral nuances.
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 immediately states the operation and parameter source, then compactly enumerates the returned fields. Every part is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter, a clear field list, and an output schema present, the description is complete for the agent to select and invoke the tool correctly. Annotations cover the safety profile, so no further behavioral caveats are required.
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 documents the id parameter well, including format and an example ('city:id' e.g. 'nyc:1367'). The description restates that the id comes from `search` but adds no meaning beyond the schema, 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 clearly states the action: get the full Dim Hour record for a venue by id, and enumerates the fields returned. However, it does not differentiate itself from the sibling get_venue, which may serve an overlapping purpose.
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 a clear usage context: use the id returned from `search`. It does not, however, explicitly discuss when to choose this tool over get_venue or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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 cover the read-only, non-destructive nature of the tool. The description adds useful behavior context by listing the returned fields and noting the special long-form story condition for Iconic 50 venues. However, it does not disclose behaviors such as parameter precedence, required city context, error cases, 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 a single front-loaded sentence that states the primary purpose immediately and then uses a compact field list to convey the response contents. Every phrase earns its place with no redundant 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?
Between the explicit field list, the Iconic 50 conditional, the read-only annotations, and a fully described input schema, an agent can understand what this tool returns and that it is a safe read operation. The main gap is the lack of guidance on how to choose among id, city, and name when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, city, and name. The description adds no additional parameter-level meaning, such as how id and name interact or why city is required, so it stays at the baseline for high schema coverage.
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 action ('Get') and the resource ('the full Dim Hour record for one venue'), then enumerates the exact content fields returned. This distinguishes it from the list/search siblings, which operate over multiple venues, by emphasizing a single-venue detail lookup.
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 no explicit guidance on when to use this tool versus alternatives like search_venues or search. It implies a detail-lookup purpose ('full record for one venue'), but does not tell the agent to first obtain a venue id via search_venues or explain the role of the required city parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 22 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 known. The description adds context beyond that: the exact count (22 cities) and the fact that the output is a mapping of city keys for use elsewhere. 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?
A single sentence that is front-loaded with the action and resource, and immediately explains the value ('city key to pass to the other tools'). No wasted words; every part 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?
For a parameterless read-only tool with an output schema (indicated by 'Has output schema: true'), the description fully covers what the agent needs: what it returns, the count, and how to use it. Nothing is missing for correct invocation.
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 tool has zero parameters, so the schema is trivially complete (100% coverage). With no parameters to document, the baseline is 4, and the description correctly focuses on the output semantics rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('the 22 cities Dim Hour covers'), and explains the purpose ('with the city key to pass to the other tools'). It clearly distinguishes itself from sibling tools like list_curated or list_new_venues by focusing on cities, not venues or curated content.
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 the usage context: this is the tool to call when you need the list of city keys before using other tools. It doesn't explicitly name alternatives or exclusions, but the phrase 'to pass to the other tools' makes it clear this is a prerequisite lookup, which is adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dim Hour's editorial 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?
The description goes well beyond the readOnlyHint annotation by disclosing the dual-mode behavior: without list_id it returns titles, with list_id it returns venues and editorial notes. This makes the tool's actual behavior fully transparent to the 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?
Two compact sentences convey the theme, the example, and the two call modes without any filler. The most important scoping information ('editorial themed lists for a city') is front-loaded.
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 low complexity, two parameters, existing output schema, and annotations, the description is complete. It covers both invocation modes and the nature of the returned data, leaving no essential gap for an agent to call the tool correctly.
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 baseline is 3. The description adds value by explaining how list_id changes the output semantics and confirming that city scopes the editorial lists. This extra context helps the agent understand the parameters' roles beyond their 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 the resource ('Dim Hour's editorial themed lists for a city') and the specific behaviors for both call modes ('Without list_id: returns all list titles. With list_id: returns that list's venues with editorial notes.'). This is a specific verb+resource statement that distinguishes the tool from generic venue-list siblings like 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 gives clear usage context: the tool is for editorial lists, and it explicitly explains how the optional list_id changes the result. It does not explicitly name sibling alternatives or state when not to use the tool, but the conditional behavior provides enough guidance for the common cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Venues recently added to the Dim Hour catalog — across all 22 cities or one city. Use for 'what's new on Dim Hour' / new-opening alerts / weekly digests. Scored places to eat and drink come first; hotels, malls, museums and landmarks carry no score and follow them. Recency orders within each group. 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. The description adds value by explaining ordering (scored first, then no-score), recency ordering, and the date estimation caveat. This goes beyond annotations, giving agents insight into result structure and data reliability.
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?
Concise but dense: two sentences pack purpose, usage, ordering, and a data-quality note. No filler, and key information is front-loaded.
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?
Complete for a read-only listing tool: purpose, usage, ordering, and a data caveat are all covered. Output schema handles return format, and limit/days parameters handle pagination and window. No critical missing info.
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 all parameters are documented in the schema. The description does not add any parameter-specific details, so it meets the baseline of 3 but does not exceed it.
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 'list' and resource 'new venues', and clarifies scope ('across all 22 cities or one city') plus ordering behavior. It clearly distinguishes from siblings like search or get_venue by focusing on recent catalog additions.
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 names use cases: 'what's new on Dim Hour', new-opening alerts, weekly digests. Provides clear context for when to invoke, though it doesn't mention alternatives or exclusions, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dim Hour's restaurant, bar and venue catalog across all 22 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 tool is known to be read-only. The description adds that it returns ranked venues with a dimhour.com link, which is behavioral output information beyond the annotations. It does not mention any side effects, errors, or rate limits, but for a search tool with read-only annotation, this is adequate. No contradiction 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 with no fluff. The first sentence states the action and result, the second gives usage context. It is front-loaded with the core purpose and efficiently communicates all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter search tool with a read-only annotation and an output schema (indicated by 'Has output schema: true'), the description is complete. It explains what it searches, what it returns, and when to use it. No additional context is needed for correct invocation.
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% for the single parameter 'query', and the schema already provides a descriptive example. The description does not add further meaning to the parameter beyond what the schema gives. Since coverage is high, baseline of 3 is appropriate; the description is not required to compensate.
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 searches Dim Hour's restaurant, bar, and venue catalog across 22 cities, returns ranked venues with a dimhour.com link. The verb 'search' is specific to the resource, and the scope (22 cities) and output (ranked venues with links) are explicit. It distinguishes itself from sibling tools like fetch or get_venue by its general search nature and explicit use cases.
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 explicit guidance on when to use it: 'Use for questions about where to eat or drink — by cuisine, dish, neighborhood, city, vibe, or award.' This gives clear context for the agent. It does not explicitly mention when not to use it or name alternatives, but given the sibling list includes search_venues, it could have differentiated. However, the usage context is strong 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.
Search Dim Hour's restaurant, bar and venue catalog. Pass city to search one city, or OMIT city to search more than 20,000 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. Free-text query matches each content word individually across cuisine, dish, vibe, and name (filler like 'best' or 'tonight' is ignored) - one strong keyword beats a sentence; 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; every content word must appear in name, cuisine, neighborhood, tags, dishes, or description (filler like 'best'/'tonight' is ignored). One strong keyword beats a full sentence. | |
| 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 cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds non-obvious behavior: the free-text query matches each content word independently across cuisine/dish/vibe/name, filler words are ignored, and results are ranked with a 0-100 quality score, price tier, neighborhood, happy-hour info and a link.
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?
Front-loaded with purpose, then scope rule, then return shape, then query semantics — a logical progression with no filler. It is on the longer side (four dense clauses), but each carries usable 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 annotations covering safety and an output schema covering return structure, the description supplies the two behaviors an agent most needs: city-scoped vs cross-city search and free-text query matching semantics. Minor gaps remain around result limits and whether a 20,000-venue scan is expensive, but nothing critical is missing.
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%, including the city-omission semantics, query matching rules, and score range, so the description largely restates structured data. It adds only marginal value through examples and the note that query should be combined with filters — correct baseline 3 when the schema already does the work.
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 names a specific verb ('Search') and a concrete resource ('Dim Hour's restaurant, bar and venue catalog'), so the object of the operation is unambiguous. It does not, however, differentiate itself from sibling tools like `search`, `get_venue`, or `list_curated`, which an agent must disambiguate on its own.
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 gives an explicit either/or rule — pass `city` for one city, omit it to search all 20,000+ venues — plus concrete cross-city query examples ('best ramen anywhere', 'michelin spots'). It also advises combining a single strong keyword with filters, which is real invocation guidance. It stops short of naming alternative sibling tools for narrower lookups.
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.
list_cities1 field changedOutput schema / properties / cities / items / properties / kind / enumPrevious value: -[
- "city",
- "region"
-]New value: +[
+ "city",
+ "state"
+]Editorial guide to restaurants and bars — hand-picked venues with opinions, not a places database
Discover 356K+ restaurants in 20 countries: search, reviews, cultural context, time-based offers.
Human-verified directory of non-alcoholic bars: 1,500+ venues in 70 cities, rated and re-checked.
Search and discover local businesses. 30+ categories with verified contact info, hours, and reviews.
Add one secure layer between your agents and this server.
