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.4/5 across 10 of 10 tools scored.
Each tool targets a distinct resource and action: venue lookup, search, city listing, curated lists, new venues, trip management, saves, and brain communication. Even overlapping capabilities (e.g., search vs. curated lists) are clearly separated by intent and description, making misselection unlikely.
Most tools follow a verb_noun pattern (get_venue, list_cities, list_my_trips, list_new_venues, read_brain, save_venue, search_venues), but three deviate: add_to_trip and post_to_brain use verb_prep_noun, and list_curated is a verb_adjective. This minor inconsistency does not harm readability.
Ten tools is well within the ideal 3-15 range for a domain-specific server. Each tool earns its place, covering discovery, personalization, and internal coordination without redundancy or bloat.
Catalog querying is robust (search, get, curated lists, new venues, cities), but user data management has notable gaps: saves can be created but not listed or removed, and trips can be listed but not viewed in detail (contents) or deleted. These gaps prevent full lifecycle workflows for user data.
add_to_tripAdd a venue to a tripAInspectAdd a venue to one of the user's Dim Hour trips (creates the trip if needed). Identify the trip by trip_code (from list_my_trips) or trip_name; with neither, a new trip is created for the venue's city. Requires the user's Dim Hour API key. Returns the trip's public share link (dimhour.com/trip.html?code=...).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Venue id from search_venues / get_venue | |
| city | Yes | City name or key of the venue | |
| date | No | Reservation date YYYY-MM-DD | |
| time | No | Reservation time, e.g. '7:30 PM' | |
| trip_code | No | 6-char trip code from list_my_trips | |
| trip_name | No | Trip name to match or create, e.g. 'NYC July' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint false, etc.), the description discloses key behaviors: 'creates the trip if needed', the fallback to city-based trip creation, the requirement for the user's Dim Hour API key, and the specific return value (public share link). This adds substantial context not present in 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 three sentences, each earning its place: the first states the core action and side effect, the second explains trip identification logic, and the third covers auth and return value. It is front-loaded with the main verb and contains no wasteful words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no output schema, the description covers the essential operational details: how to identify a trip, the creation fallback, auth, and return value. It does not explain date/time parameters or precedence when both trip_code and trip_name are provided, but these are documented in the schema and are not critical 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining the relationship between trip_code, trip_name, and city, noting that if neither trip_code nor trip_name is provided, a new trip is created for the venue's city. This clarifies fallback logic beyond the individual parameter 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 tool's function: 'Add a venue to one of the user's Dim Hour trips' with a specific verb and resource. It distinguishes from siblings by mentioning trip creation, trip identification via code/name, and the returned share link, which sets it apart from tools like save_venue or list_my_trips.
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 when to use the tool, including the prerequisite of having a trip_code from list_my_trips or a trip_name, and the fallback behavior of creating a new trip for the venue's city. However, it does not explicitly name alternatives or state when not to use this tool, so it falls 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.
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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read nature is covered. The description adds value by disclosing the exact payload fields and the conditional long-form story for Iconic 50 venues, which is a behavior not captured 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?
A single, information-dense sentence that lists all returned fields and the special case. It is compact and front-loaded, though the list is long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately describes the return payload and the Iconic 50 exception. It does not cover error handling or parameter precedence, but for a simple read-only getter it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (id, city, name) with 100% coverage, so the schema carries the load. The description adds no additional parameter-level semantics.
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 explicitly states it 'Get[s] the full Dim Hour record for one venue' and enumerates the specific fields returned, clearly distinguishing it from sibling tools like search_venues (which finds venues) and save_venue (which persists 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 implies use for retrieving a single venue's details after search, but does not explicitly contrast with alternatives or state when not to use it. The context of 'one venue' and the mention of Iconic 50 gives some situational guidance, but no explicit when-not or alternative references.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds useful context: a fixed count of 20 cities, the coverage scope ('Dim Hour covers'), and the fact that it returns city keys. This goes beyond the annotations without contradicting them.
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 conveys the key information without redundancy. Every phrase adds value: the count, the coverage, and the purpose of the city key.
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 tool with no output schema, the description is complete: it states the exact output (20 cities with keys), the scope (Dim Hour's coverage), and the purpose (keys for other tools). No additional context is needed.
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 baseline is 4. The description does not need to explain parameters and correctly focuses on the output; no schema parameter descriptions are needed.
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 Dim Hour covers, with a specific verb and resource. It distinguishes itself from sibling list tools (list_curated, list_my_trips, list_new_venues) by specifying 'cities' and the city key's role in passing to other tools.
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 'to pass to the other tools' implies when to use it: before calling tools that require a city key. It provides clear context for usage, though it does not explicitly contrast with alternatives or state 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.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds valuable behavioral context: without list_id it returns all list titles, with list_id it returns venues with editorial notes. This goes beyond the annotations and helps the agent predict outputs.
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, includes an example, and efficiently covers both usage modes. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description fully explains what to expect in both invocation modes. Combined with the good annotations, the agent has enough information to use the tool correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description adds extra meaning by explaining that list_id comes from the no-arg call and that its presence changes the response, which helps the agent understand the relationship between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Dim Hour's hand-curated themed lists for a city, with a concrete example ('Unmarked Doors' speakeasies). It distinguishes itself from siblings like list_new_venues and search_venues by focusing specifically on curated lists, and explains the two operation modes (with/without list_id).
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 for when to use the tool and explains how the presence of list_id changes the output. It does not explicitly name alternatives or exclusions, but the scope is unambiguous and the mode-based guidance is practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_tripsList my tripsAList the user's Dim Hour trips (code, name, city, item count, share link). Requires the user's Dim Hour API key. Use the code with add_to_trip.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe read. The description adds the return payload (code, name, city, item count, share link) and the API key requirement, giving context 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?
Two sentences, with the core verb-resource pair first and additional details in a second sentence. No redundant phrasing 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 (no params, no output schema), the description covers the return fields, the auth requirement, and a cross-tool usage hint, making it fully self-contained.
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?
There are zero parameters in the schema, so the baseline score is 4. The description clarifies that the only external requirement is the Dim Hour API key, which is useful context for invocation.
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 opens with 'List the user's Dim Hour trips', a specific verb+resource that clearly distinguishes it from sibling list tools like list_cities or list_curated. It also enumerates the returned fields (code, name, city, item count, share link), making the purpose unmistakable.
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 explicitly states the prerequisite API key and provides a concrete usage directive: 'Use the code with add_to_trip.' This tells the agent both how and when to apply the tool, though it doesn't formally exclude sibling list tools.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds a valuable data-quality caveat that dates before 2026-06-06 are estimates reconstructed from history. This goes beyond the schema and annotations by disclosing the reliability of results.
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 function, then provides use cases and a caveat. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with optional filters and no output schema, the description covers purpose, scope, typical use cases, and an important data caveat in just two sentences. It is complete enough for an agent to select and invoke 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 description coverage is 100% for all three parameters (city, days, limit), so the schema already explains their meanings. The description reinforces the city parameter ('all 20 cities or one city') but adds no new semantic details about parameter usage or syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists venues recently added to the catalog, with an optional city filter. This distinguishes it from sibling tools like search_venues (general search) and list_curated (curated picks) by its specific focus on new 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?
Provides explicit use cases: 'what's new on Dim Hour', new-opening alerts, and weekly digests. This gives clear context for when to use the tool, though it does not explicitly mention alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
post_to_brainPost to the brain busAInspectPost a message or a proposed state-change into the Dim Hour Triangle brain (the shared room for Poke, Claude, and Clicky). Use this to drop an objective, a status note, or a proposed live_nodes patch. IMPORTANT: every post is recorded as 'asserted' and is NOT treated as true until Claude verifies it against the real repo/DB and lands it in THREAD.md / live_nodes.json. You cannot mark a post verified. Requires the user's Dim Hour API key.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Optional evidence: a git sha, PR url, or dashboard link | |
| body | Yes | The message text, or — for node_update — a JSON patch string, e.g. {"repo":{"catalog_venues":10200}} | |
| kind | Yes | thread = a message for the room; node_update = a proposed JSON patch to live_nodes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavior beyond the annotations: every post is recorded as 'asserted' and not treated as true until Claude verifies it against the repo/DB, the caller cannot mark a post verified, and a Dim Hour API key is required. These are substantive details not present in 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 three sentences: first states purpose, second lists use cases, third highlights the critical verification caveat and API key requirement. It is front-loaded and every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers the core behavior, the important asserted-vs-verified status, and the auth requirement. It does not mention the response format or error cases, but those are not essential given the tool's simplicity and available annotations.
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 input schema has 100% description coverage for all three parameters, including the enum for kind and the JSON patch example for body. The description does not add parameter-specific meaning beyond what the schema already conveys, 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?
The description opens with a specific verb and resource: 'Post a message or a proposed state-change into the Dim Hour Triangle brain.' It clearly distinguishes itself from the read_brain sibling by framing this as the write/post action, and it lists concrete use cases (objective, status note, live_nodes patch).
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 says 'Use this to drop an objective, a status note, or a proposed live_nodes patch,' giving clear when-to-use guidance. It also notes posts are not considered true until verified, implying this is for proposals. However, it does not explicitly name alternatives or state when not to use the tool, so it falls 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.
read_brainRead brain postsARead the recent Dim Hour Triangle brain posts (the shared room) so you can see what's been proposed and what Claude has verified. Posts route sender_node -> target_node with a topic + payload; status is 'pending' (unverified), 'processing', 'completed' (confirmed by Claude against the repo/DB), or 'failed'. Requires the user's Dim Hour API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max posts, default 20 | |
| status | No | Optional filter to one status; omit for all recent posts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: true, and the description adds domain context: posts route sender_node -> target_node, statuses have specific meanings, and requires the user's Dim Hour API key. This enriches the agent's understanding without contradicting 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 two sentences, front-loaded with the core purpose and followed by domain context and requirements. Every sentence adds value 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?
For a read tool with no output schema, the description covers the data model (sender_node, target_node, topic, payload, status) and the auth requirement, which helps predict return values. The fact that it reads 'brain posts' makes it clear the response is a list of such posts, so the lack of an explicit return statement is not a significant 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 provides descriptions for both parameters (limit and status) with 100% coverage, so the baseline is 3. The description adds meaning by defining what each status represents ('pending' unverified, 'completed' confirmed by Claude against the repo/DB), which helps the agent understand the filter values.
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 'Read the recent Dim Hour Triangle brain posts' with a specific verb and resource. It distinguishes from sibling post_to_brain by being the read operation, and from other listing tools by focusing on brain posts.
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 explains the purpose: 'so you can see what's been proposed and what Claude has verified,' giving clear context for when to use. It does not explicitly exclude write operations or name alternatives, so it falls short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_venueSave a venueAInspectSave a venue to the user's Dim Hour account: 'fav' (Favorites), 'want' (Want to try), or 'visited' (Been there). Requires the user's Dim Hour API key (generated in the app: Profile → Concierge API key). The save appears in the app after its next sync (app open or sign-in).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Venue id from search_venues / get_venue | |
| city | Yes | City name or key | |
| kind | Yes | fav = Favorites, want = Want to try, visited = Been there |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: it requires a specific API key and notes that saves appear only after the next app sync. Annotations already indicate a write operation (readOnlyHint false), so the added auth and latency context is valuable. It doesn't mention idempotency, but the annotation idempotentHint=false covers that.
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, each with a distinct purpose: main function and classifications, auth requirement, and sync behavior. No redundancy or filler. The description is front-loaded with the core action.
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 the core operation, authentication requirement, and synchronization delay. Missing details about response/error handling and idempotency on duplicate saves, but for a simple save operation with a rich schema, it is largely complete. Could be improved by explaining how to supply the API key.
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 has 100% coverage with descriptions for all three parameters, including the enum values. The description repeats the enum meanings but doesn't add significant new semantic detail beyond what the schema already provides. 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 states the action (save), the resource (venue), the destination (user's Dim Hour account), and the specific categories ('fav', 'want', 'visited'). It distinguishes itself from sibling tools like add_to_trip and post_to_brain by naming the three account lists directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: saving a venue to one of three user account lists. It also states a prerequisite (Dim Hour API key) with exact generation instructions. It does not explicitly exclude alternatives or compare to sibling tools, but the context is sufficient for selection.
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 ~9,500 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds useful behavioral context by detailing return fields ('score (0-100 quality), price tier, neighborhood, happy-hour info, and a dimhour.com link'). This goes beyond the structured annotations and enhances transparency.
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, each serving a distinct purpose: what the tool does, how the 'city' parameter works, and what the response includes with query usage. No fluff or repetition.
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?
Without an output schema, the description adequately covers the key return fields and search behavior. It is reasonably complete for a 11-parameter search tool, though it does not explain ranking details or pagination, which are less critical given the schema's coverage.
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 has 100% parameter coverage, so the baseline is 3. The description adds value by highlighting the city/query interaction and giving an example ('best ramen anywhere'), which helps the agent form better queries. It does not fully compensate for all params but provides meaningful usage nuance.
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 'Search Dim Hour's curated restaurant/bar/venue catalog' with a specific verb and resource. It distinguishes from siblings like get_venue (single venue) and list_curated (curated lists) by emphasizing ranked search across the catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on city handling ('Pass `city` to search one city, or OMIT `city` to search all'), and explains query usage ('Use free-text `query` for cuisine, dish, vibe, or name; combine with filters'). This gives clear context for when to use it, though it does not explicitly name alternative tools or exclusions.
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!
