Dim Hour

Search venues

search_venues

Read-only

Search Dim Hour's curated restaurant/bar/venue catalog. Pass city to search one city, or OMIT city to search more than 19,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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`city`	No
`note`	No
`scope`	No
`venues`	Yes
`showing`	Yes
`total_matches`	Yes

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior beyond them: per-content-word matching with filler ignored, ranked results with score/price tier/neighborhood/happy-hour info and a dimhour.com link, and catalog coverage of 19,000+ venues.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and the most important usage decision (city vs all-cities). The return-fields and query-semantics sentences are dense but each earns its place; it is slightly long but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with 100% schema coverage, an output schema, and safety annotations, the description covers the key decision points: scope, matching behavior, and what results contain. Nothing an agent needs to call it correctly is missing, aside from explicit routing versus the generic 'search' sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for all 11 parameters, so the baseline is 3. The description adds strategic meaning beyond the schema by explaining the city-omission behavior and how free-text `query` is interpreted (content-word matching, filler ignored, one strong keyword beats a sentence), which materially improves query construction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Search Dim Hour's curated restaurant/bar/venue catalog') with a named resource and clear scope. The 'curated' qualifier and the explicit city vs all-cities mode distinguish it from the generic sibling 'search' and from 'list_curated'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear operating context: pass `city` for one city, omit it for the full ~19,000-venue catalog, and offers search strategy tips ('one strong keyword beats a sentence; combine with filters'). It does not explicitly name sibling tools or state when-not-to-use conditions, so it earns a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Dim Hour tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation2/5

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 Consistency3/5

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.

Tool Count5/5

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).

Completeness4/5

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.

Resources

Need Help?