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 9 tools
`fetch` and `get_venue` are near-duplicates, both returning a full venue record, so an agent cannot reliably choose between them. `search`, `search_venues`, and `find_places` also overlap heavily, with distinctions that are subtle rather than clear-cut. Several tools have unclear boundaries.
Most tools follow a verb_noun pattern (`find_places`, `get_hours`, `get_venue`, `list_cities`, `list_curated`, `list_new_venues`, `search_venues`), but bare verbs `fetch` and `search` break the convention. The mixed conventions remain readable, but they are not fully consistent.
Nine tools is a reasonable, well-scoped count for a venue-discovery catalog. However, the redundant `fetch`/`get_venue` pair means not every tool clearly earns its place, so it is slightly over-provisioned rather than perfectly scoped.
The surface covers core discovery workflows: city listing, curated lists, new venues, search, venue details, and hours. Minor gaps remain, such as no direct reservation or booking operation, but the read-only browsing domain is largely complete.
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 | |
| receipt | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds only the shape of the returned record; it says nothing about auth needs, missing-id behavior, or rate limits, which is acceptable but not rich given the lower bar set by 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?
One front-loaded sentence with no filler, and the identifier source is stated early. The trailing enumeration of return fields is somewhat redundant given an output schema exists, but it is compact and does not derail the sentence.
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 read tool with full schema coverage, an output schema, and annotations covering safety, the definition supplies enough to invoke it correctly. The one gap is that it does not resolve the overlap with the `get_venue` sibling.
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% and the single `id` parameter is already documented with its 'city:id' format and `search` provenance. The description restates the same provenance, adding no syntax or format detail beyond the schema, so baseline 3 applies.
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?
States a specific verb+resource ('Get the full Dim Hour record for one venue') and names the identifier source, which is clear enough to act on. However, it never distinguishes itself from the sibling `get_venue`, which reads like the same operation, so an agent cannot tell the two apart from the description alone.
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 one real precondition – the id must come from `search` – which is a genuine routing hint. But it offers no when-to-use/when-not guidance and no differentiation from `get_venue` or `search_venues`, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find places for a specific occasion in one city — the task-shaped entry point. Give the city and what the evening needs (a cuisine, a neighborhood, a budget, a vibe) and it returns ranked, citable venues with a freshness receipt. Prefer this over search_venues when you are planning rather than browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or key from list_cities | |
| limit | No | Max results, default 6 | |
| max_price | No | Max price tier 1-4 | |
| looking_for | No | What the occasion needs, e.g. 'omakase', 'patio', 'birthday dinner' | |
| neighborhood | No | Narrow to a neighborhood |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| note | No | |
| venues | Yes | |
| receipt | Yes | |
| showing | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: results are ranked, citable, and come with a 'freshness receipt'. It does not discuss rate limits or failure modes, keeping it short of a 5.
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 tight sentences, front-loaded with the core action and scope, followed by inputs and then the sibling-routing rule. No sentence is redundant.
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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. What remains - what the tool does, what to pass, and when to prefer it over the sibling - is all present.
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 five parameters are already documented, making 3 the baseline. The description loosely maps the occasion needs to inputs ('a cuisine, a neighborhood, a budget, a vibe') but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (find places) plus the scope constraint 'in one city', and explicitly labels itself the task-shaped entry point. It distinguishes itself from the sibling search_venues by name, so an agent can route without opening either schema.
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?
Gives an explicit selection rule: 'Prefer this over search_venues when you are planning rather than browsing.' That names the alternative and the condition that chooses it, which is exactly what routing guidance should do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opening hours for one venue, from the Dim Hour catalog. ALWAYS returns as_of and never claims to be live — hours are catalog data, not a live feed, and the receipt says how old they are. Measured 2026-09-16, 82% of venues carry hours; when a venue has none this ABSTAINS and says so rather than guessing. Confirm with the venue before relying on it.
| 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 | |
| url | Yes | |
| city | Yes | |
| name | Yes | |
| hours | Yes | |
| receipt | Yes | |
| warning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnly, non-destructive, closed-world), while the description supplies genuinely additive behavior: it always returns an `as_of` receipt, explicitly refuses to pose as a live feed, abstains instead of guessing when a venue lacks hours, and quantifies coverage at 82%. That is exactly the beyond-annotations context this dimension rewards.
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?
Four sentences, front-loaded with what the tool returns and the provenance constraint, each sentence carrying distinct information (source, staleness receipt, abstention, coverage stat). The coverage-percentage detail is slightly peripheral but still earns its place as a reliability signal.
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?
An output schema exists, so return-value structure needn't be described, and the description still explains the one field that matters semantically (`as_of`). Combined with the abstention behavior and data-freshness disclosure, an agent has everything needed to call and interpret this 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 description coverage is 100%, so the required `city` and optional `id`/`name` lookup parameters are already fully documented by the schema. The description adds no format, precedence, or disambiguation guidance beyond that, so the baseline of 3 applies.
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?
States a specific verb and resource ('Opening hours for one venue') plus the data source ('the Dim Hour catalog'), which cleanly separates it from venue-detail siblings like get_venue and search_venues. An agent knows exactly what it will receive without opening a sibling schema.
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?
Gives clear context for use: one venue, catalog data, abstains when the venue has no hours, and a caveat to confirm with the venue before relying on it. It never routes the agent to a sibling (e.g., where to get hours another way, or which tool to use for other venue fields), so it falls short of explicit when-not/alternatives.
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 | |
| receipt | 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 declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context about the breadth of the record and the Iconic 50 long-form story variant, but says nothing about lookup failure behavior or the id-vs-name resolution rule.
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 immediately names the resource and then lists the payload. The field enumeration is long but each item is informative, so it largely 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 an output schema present, the description need not explain return values, yet it usefully previews them. Only minor gaps remain: no statement of the id/name fallback logic or what happens when the venue is not found.
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 baseline is 3 and the schema already explains id, city, and name, including that id comes from search_venues. The description adds no parameter-level detail beyond noting the Iconic 50 variant.
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?
States a specific verb and resource ('Get the full Dim Hour record for one venue') and enumerates the returned fields, making it clear this is a single-record lookup rather than a list. It does not explicitly distinguish itself from siblings like fetch or get_hours, so it stops short of a 5.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as search_venues (which is only referenced inside the schema, not the description). The agent must infer that this is a follow-up to a search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 26 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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the dataset's bounded scope (a fixed set of 26 cities), which is genuinely useful behavioral context, but says nothing about ordering, auth, or resumability — appropriate for a simple read-only list.
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 with zero filler, front-loading the action and immediately stating the practical payoff of the returned key. Nothing can be trimmed without losing 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 zero-parameter, read-only enumeration with an output schema present, the description supplies everything an agent needs: what is returned, how many entries, and how the result is consumed downstream. Return-format details are correctly left to the output 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?
The tool takes zero parameters, so there is nothing to document; the baseline of 4 applies. The description correctly implies no input is needed to retrieve the full list.
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?
States a specific verb (List) and resource (cities Dim Hour covers), and adds scope plus the reason the output matters — the city key feeds the other tools. This clearly separates it from the venue-oriented siblings like list_curated, list_new_venues, and find_places.
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 phrase 'the city key to pass to the other tools' implies the intended workflow (call this first, then use the key elsewhere), which is useful implicit guidance. However, there is no explicit when-to-use/when-not statement or named alternative, so the guidance remains inferred rather than stated.
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 | |
| receipt | Yes | |
| subtitle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds value by disclosing that behavior changes with list_id and what each mode returns (titles vs. venues plus editorial notes), which the annotations do not convey.
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 filler, and the core purpose is front-loaded before the mode differences. Every clause carries information the agent needs.
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 read-only, two-parameter tool with an output schema, the description covers purpose and both modes sufficiently. It omits anything about result limits, pagination, or empty-list behavior, which is the only remaining gap.
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 and the baseline would be 3. The description goes beyond the schema by explaining the behavioral effect of presence/absence of list_id, giving the agent mode semantics rather than just a type.
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 and resource — 'editorial themed lists for a city' — and grounds it with a concrete example ('Unmarked Doors' speakeasies). It is clear enough to separate from siblings like search_venues and list_new_venues by resource type, though it never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It spells out the two operating modes and their trigger condition: omit list_id to browse all list titles, pass list_id to drill into that list's venues. That is real when-to-use guidance, but there is no statement of when not to use it or which sibling to prefer for other listing needs.
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 26 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 | |
| receipt | 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 readOnly/openWorld=false/destructive=false, but the description adds real behavioral context: grouped result ordering (scored eat/drink first, un-scored venue types after), recency ordering within groups, and a data-quality caveat that dates before 2026-06-06 are reconstructed estimates. Pagination behavior is not mentioned, keeping it short of a 5.
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 sentences, front-loaded with scope and purpose, then usage, then result semantics and the date caveat. No filler and nothing repeated from structured 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?
With an output schema present, return values need not be explained, and the description covers scope, ordering/grouping, and the estimate caveat for early dates. An agent has everything needed to call it 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 description coverage is 100%, so city/days/limit are already documented in the schema with defaults and bounds. The description only alludes to the city parameter ('all 26 cities or one city') and adds no syntax or format detail beyond the schema — baseline 3 applies.
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?
States a specific verb+resource+scope: venues 'recently added to the Dim Hour catalog', across all 26 cities or one city. The recency qualifier cleanly distinguishes it from siblings like search_venues, find_places and list_curated.
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?
Gives concrete use cases ('what's new on Dim Hour', new-opening alerts, weekly digests), which tells the agent when this tool is the right pick. It stops short of naming an alternative tool or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dim Hour's restaurant, bar and venue catalog across all 26 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 |
|---|---|---|
| receipt | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results are ranked and each carries a dimhour.com link, which is modest extra value; it says nothing about result counts, pagination, or empty-result behavior. With annotations and an output schema present, a 3 is appropriate.
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 tightly written sentences with the purpose and scope front-loaded and no redundant filler. The '26 cities' detail earns its place as scope; nothing else could be trimmed meaningfully.
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, geographic scope, return shape (ranked venues with links), and intended question types; the output schema handles return-value detail. The one real hole is sibling disambiguation against `search_venues`/`find_places`, which matters given the crowded namespace.
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% and the single `query` param already carries examples, so the baseline is 3. The description goes slightly further by naming the facets a query can express (cuisine, dish, neighborhood, city, vibe, award), enriching how an agent should phrase input beyond the schema's three examples.
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?
States a specific verb and resource ('Search Dim Hour's restaurant, bar and venue catalog') plus scope ('across all 26 cities'). However, it never distinguishes itself from the close siblings `search_venues` and `find_places`, which appear to overlap heavily.
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 usage context ('Use for questions about where to eat or drink') and enumerates useful search facets (cuisine, dish, neighborhood, city, vibe, award). But with `search_venues`, `find_places`, and `list_*` tools present, the absence of any when-to-use-this-vs-that routing leaves selection ambiguous.
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. | |
| sort | No | Result order. Default score_desc (highest quality first). | |
| 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. | |
| fields | No | Return only these fields on each venue, to keep a result small. `id`, `name` and `url` are always included — `url` is the citation link. | |
| 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 | |
| receipt | Yes | |
| showing | Yes | |
| total_exact | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and a closed (non-open-world) catalog, so the safety profile is covered. The description adds useful behavioral detail beyond that: the ranked return shape (score, price tier, neighborhood, happy hour, citation link) and the fact that queries are tokenized word-by-word with filler ignored.
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 dense sentences, front-loaded with purpose then scope then query mechanics; nothing is padded. It is slightly information-packed, but each clause carries actionable signal.
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 13-parameter, optional-only search tool with an output schema present, the description covers scope, query semantics, return contents, and filter combination. Nothing an agent needs to call it correctly 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 coverage is 100%, so the baseline is 3. The description goes further by explaining the query matching model ('one strong keyword beats a sentence') and the cross-parameter interaction with filters, which helps an agent compose calls rather than just fill fields.
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?
States a specific verb and resource ('Search Dim Hour's restaurant, bar and venue catalog') and immediately clarifies the two search scopes (one city vs all cities). It does not explicitly differentiate itself from close siblings like `search`, `find_places`, or `get_venue`, so it stops short of a 5.
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?
Gives clear operational guidance: pass `city` for one city, OMIT it for the 20k-venue global sweep, with example intents. It does not say when to prefer this tool over `find_places` or `search`, so there is no explicit alternative routing.
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.
fetch1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}find_places1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}get_hours1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}get_venue1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}list_curated1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}list_new_venues1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}search1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}search_venues1 field changedOutput schema / properties / receipt / properties / scope_noteAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}get_hours2 fields changedOutput schema / properties / warningAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "city",
- "id",
- "name",
- "hours",
- "url",
- "receipt"
-]New value: +[
+ "city",
+ "id",
+ "name",
+ "hours",
+ "warning",
+ "url",
+ "receipt"
+]Editorial guide to restaurants and bars — hand-picked venues with opinions, not a places database
Verified food venues in 222 cities with provenance, festivals with dates, bookable tours and stays.
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.
Add one secure layer between your agents and this server.
