Search nearly 20,000 verified restaurants and bars across 24 cities plus the New Mexico region, with venue detail and curated lists.
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?
The annotations already declare read-only and non-destructive behavior. The description adds value by enumerating the response fields (description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website, Instagram) and indicating a comprehensive retrieval. It does not cover error cases but that is acceptable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. The list of returned fields is informative without being verbose. Every phrase contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the existing annotations, and the presence of an output schema, the description provides sufficient context for an agent to select and invoke it correctly. It clearly states the input source and the nature of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a thorough description of the `id` parameter, including its source (from search) and an example format. The description reiterates this source but adds no new semantic detail. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('full Dim Hour record'), and clearly states the input source (id from search). It lists the contained fields, making the purpose unambiguous. However, it does not explicitly differentiate itself from the sibling tool 'get_venue', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear workflow: first call `search` to obtain an id, then use this tool to fetch the full record. This provides useful context for when to use it. It does not explicitly mention alternatives or when not to use it, so it stops short of giving full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Dim Hour record for one venue: description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website, Instagram, and (for Iconic 50 venues) the long-form story.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Venue id from search_venues | |
| city | Yes | City name or key | |
| name | No | Venue name (used if id not given) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| lat | No | |
| lng | No | |
| url | Yes | |
| name | Yes | |
| tags | Yes | |
| hours | Yes | |
| phone | Yes | |
| price | No | |
| score | No | |
| story | No | |
| awards | Yes | |
| dishes | Yes | |
| iconic | No | |
| opened | No | |
| address | Yes | |
| cuisine | Yes | |
| website | Yes | |
| photoUrl | Yes | |
| trending | No | |
| city_name | Yes | |
| Yes | ||
| happy_hour | Yes | |
| highlights | No | |
| price_tier | No | |
| description | Yes | |
| reservation | Yes | |
| neighborhood | Yes | |
| other_locations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds useful conditional detail (long-form story only for Iconic 50 venues) and clarifies the record's composition, providing value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and then lists fields in a dense, readable manner. It is slightly long but every word adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a read-only annotation, full schema coverage, and an output schema, this description is sufficiently complete for a single-record retrieval tool. It does not elaborate on error handling or sibling differentiation beyond implied usage, but those gaps are minor given existing structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), and the tool description does not add extra meaning beyond labeling the record as 'full.' The schema already explains id/name/city roles, so the description contributes minimal additional parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full Dim Hour record for a single venue and enumerates the included fields (description, signature dishes, address, hours, etc.). This specific verb+resource pairing distinguishes it from sibling tools like search_venues or fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving detailed records after a search, and the input schema explicitly notes the id comes from search_venues. However, it does not state when not to use it or mention alternatives for list/lightweight data, leaving room for more explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 24 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, and the description's 'List' matches that safety profile. It additionally discloses the exact scope ('24 cities') and the useful detail that the output contains city keys.
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, efficient sentence that states exactly what the tool does and why the result matters. No filler or redundant content.
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 list operation with an output schema available, the description fully covers what an agent needs to call it correctly and understand its role in the workflow.
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 adds value by explaining that the output provides city keys for use elsewhere, which is the only semantic guidance needed for a parameterless call.
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'), a precise resource ('the 24 cities Dim Hour covers'), and the practical purpose ('city key to pass to the other tools'). This clearly distinguishes it from sibling tools that list venues or search 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 gives clear context: this tool is the source for city keys needed by other tools, implying it should be used to obtain valid city identifiers. It does not explicitly name exclusions or alternatives, but the use case is unambiguous.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail beyond annotations: the response differs based on whether list_id is supplied, returning list titles in one case and venues with editorial notes in the other. 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 compact, front-loaded with the core purpose, and includes an illustrative example. Each sentence earns its place: one defines scope, and two concisely cover the parameter-dependent behavior. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, full schema coverage, presence of an output schema, and read-only annotations, the description covers everything needed to invoke it correctly. It explains the required city context, the optional list_id, and what each call returns, making it complete without needing to repeat schema or output details.
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. The description adds extra semantic value by explaining the behavior associated with list_id omission vs. inclusion, which the schema only hints at through the parameter description 'A list id from the no-arg call.' This directly clarifies how the parameters affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('returns') and names a precise resource: 'Dim Hour's editorial themed lists for a city.' It clearly distinguishes itself from siblings like list_new_venues by emphasizing editorial lists, and it explains the two invocation modes (with and without list_id) so the tool's purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context: editorial themed lists for a city, and gives concrete usage guidance for when list_id is omitted versus included. It does not explicitly name alternatives or say when not to use this tool, but the editorial focus and conditional behavior make the intended usage clear.
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 24 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?
Beyond the readOnlyHint and destructiveHint annotations, the description reveals non-obvious ordering behavior: scored places come first, non-scored venues follow, and within each group recency orders results. It also discloses that dates before 2026-06-06 are reconstructed estimates, which is exactly the kind of behavioral context an agent needs.
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 front-loaded with the core purpose, then gives concrete use cases, ordering behavior, and a date-estimate caveat. Every sentence carries meaningful information with no filler or 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?
With an output schema present and all parameters documented at 100% coverage, the description still covers the essential use context, ordering semantics, and an important data-quality caveat. Nothing critical is missing for selecting or invoking this 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%, so the schema already documents city, days, and limit thoroughly. The description adds only the '24 cities' detail and recency concept, but does not materially explain parameter usage beyond what the schema provides, 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 'Venues recently added to the Dim Hour catalog', which names the exact resource and distinguishes this tool from siblings like list_curated and search_venues by its recency focus. It also clarifies the scope ('across all 24 cities or one city'), leaving no ambiguity about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: "Use for 'what's new on Dim Hour' / new-opening alerts / weekly digests." It does not explicitly say when not to use it or name alternative tools, so it stops short of a full 5, but the use cases are clear.
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 24 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful non-schema behavior: results are 'ranked' and each venue includes a dimhour.com link. No contradictions 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?
Two concise sentences front-load the core action and scope, then add return-format and use-case guidance. Every sentence earns its place with no filler or 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 single-parameter search tool with a full output schema and read-only annotations, the description covers scope, return value, and typical use cases. Nothing essential is missing for an agent to invoke 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 coverage is 100% and the schema already describes the query parameter with examples. The description adds meaning by enumerating search dimensions (cuisine, dish, neighborhood, city, vibe, award) that give the agent a richer sense of acceptable query targets beyond the schema's 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?
The description clearly states a specific verb ('Search'), resource ('Dim Hour's restaurant, bar and venue catalog'), and scope ('across all 24 cities'). It also names the return value (ranked venues with a dimhour.com link). However, it does not explicitly differentiate itself from the sibling tool `search_venues`, so it misses full sibling distinction.
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 when-to-use guidance: 'Use for questions about where to eat or drink' and lists query dimensions (cuisine, dish, neighborhood, city, vibe, award). It does not mention when not to use it or point to any alternative sibling tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Dim Hour's restaurant, bar and 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.
| 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 mark readOnlyHint=true and destructiveHint=false, so the description only needs to add behavior, and it does: it discloses ranked matches, score range, return fields, and query tokenization ('matches each content word individually', 'filler ... is ignored'). Also explains the global-search behavior when city is omitted. No contradiction.
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, tightly written: purpose, city behavior/returns, and query guidance. Each sentence adds distinct information; no filler or repetition. Front-loads 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?
The description covers the two most ambiguous behaviors (omitting city, query tokenization) and summarizes return fields, while the output schema and 100% parameter descriptions provide the rest. With 11 optional params and no required args, it gives enough orientation to call correctly without drowning in detail.
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 does restate query matching and city omission, but adds no new parameter-specific meaning beyond the schema (e.g., 'one strong keyword beats a sentence' is already in the query schema description). It remains accurate and integrated, so no penalty beyond baseline.
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 'Search' and a specific resource 'Dim Hour's restaurant, bar and venue catalog', and distinguishes itself by explaining city-scoped vs global search. This clearly separates it from siblings like 'get_venue' and the generic 'search' without needing to open the 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: 'Pass city to search one city, or OMIT city to search more than 19,000 venues across every city at once' and advises combining free-text query with filters. It does not explicitly contrast with the sibling 'search' or say when to prefer 'get_venue', so it stops short of full exclusion guidance.
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. Dates show when Glama detected each change.
list_cities4 fields changedOutput schema / properties / cities / items / properties / childrenAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / cities / items / properties / kindAdded value: +{
+ "enum": [
+ "city",
+ "region"
+ ],
+ "type": "string"
+}Output schema / properties / cities / items / properties / parentAdded value: +{
+ "type": "string"
+}Output schema / properties / cities / items / requiredPrevious value: -[
- "key",
- "name",
- "state"
-]New value: +[
+ "key",
+ "name",
+ "state",
+ "kind"
+]search_venues1 field changedInput schema / properties / query / descriptionPrevious value: -"Free text matched against name, cuisine, neighborhood, tags, dishes, description"New value: +"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."add_to_triplist_my_tripspost_to_brainread_brainsave_venueadd_to_trip1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "type": "boolean"
+ },
+ "already_present": {
+ "type": "boolean"
+ },
+ "date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "share_url": {
+ "type": "string"
+ },
+ "time": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "trip_code": {
+ "type": "string"
+ },
+ "trip_created": {
+ "type": "boolean"
+ },
+ "trip_name": {
+ "type": "string"
+ },
+ "venue": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "trip_code",
+ "trip_name",
+ "trip_created",
+ "added",
+ "already_present",
+ "venue",
+ "date",
+ "time",
+ "share_url",
+ "note"
+ ],
+ "type": "object"
+}get_venue1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "awards": {
+ "type": "string"
+ },
+ "city_name": {
+ "type": "string"
+ },
+ "cuisine": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "dishes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "happy_hour": {
+ "type": "string"
+ },
+ "highlights": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "hours": {
+ "type": "string"
+ },
+ "iconic": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "number"
+ },
+ "instagram": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lng": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "opened": {
+ "type": "string"
+ },
+ "other_locations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "phone": {
+ "type": "string"
+ },
+ "photoUrl": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "price_tier": {
+ "type": "number"
+ },
+ "reservation": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "story": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "trending": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "cuisine",
+ "neighborhood",
+ "tags",
+ "description",
+ "dishes",
+ "happy_hour",
+ "address",
+ "hours",
+ "phone",
+ "reservation",
+ "awards",
+ "website",
+ "instagram",
+ "url",
+ "city_name",
+ "photoUrl"
+ ],
+ "type": "object"
+}list_cities1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "cities": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key",
+ "name",
+ "state"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "cities"
+ ],
+ "type": "object"
+}list_curated1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lists": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "subtitle": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "venue_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "subtitle",
+ "venue_count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "subtitle": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "venues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "note",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "city"
+ ],
+ "type": "object"
+}list_my_trips1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "total": {
+ "type": "number"
+ },
+ "trips": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "code": {
+ "type": "string"
+ },
+ "items": {
+ "type": "number"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "share_url": {
+ "type": "string"
+ },
+ "updated_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "name",
+ "city",
+ "items",
+ "updated_at",
+ "share_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total",
+ "trips"
+ ],
+ "type": "object"
+}list_new_venues1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "feed_generated": {
+ "type": "string"
+ },
+ "showing": {
+ "type": "number"
+ },
+ "total_new": {
+ "type": "number"
+ },
+ "venues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "awards": {
+ "type": "string"
+ },
+ "city": {
+ "type": "string"
+ },
+ "city_name": {
+ "type": "string"
+ },
+ "cuisine": {
+ "type": "string"
+ },
+ "estimated": {
+ "type": "boolean"
+ },
+ "first_seen": {
+ "type": "string"
+ },
+ "happy_hour": {
+ "type": "string"
+ },
+ "id": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "city",
+ "city_name",
+ "id",
+ "name",
+ "cuisine",
+ "neighborhood",
+ "awards",
+ "happy_hour",
+ "first_seen",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "window_days": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "window_days",
+ "city",
+ "total_new",
+ "showing",
+ "venues"
+ ],
+ "type": "object"
+}post_to_brain1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "note": {
+ "type": "string"
+ },
+ "posted": {
+ "type": [
+ "string",
+ "number"
+ ]
+ },
+ "sender_node": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "target_node": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "posted",
+ "status",
+ "sender_node",
+ "target_node",
+ "note"
+ ],
+ "type": "object"
+}read_brain1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "law": {
+ "type": "string"
+ },
+ "posts": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "created_at": {
+ "type": "string"
+ },
+ "id": {
+ "type": [
+ "string",
+ "number"
+ ]
+ },
+ "payload": {},
+ "sender_node": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "target_node": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "topic": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "created_at",
+ "sender_node",
+ "target_node",
+ "topic",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "law",
+ "posts"
+ ],
+ "type": "object"
+}save_venue1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "already_saved": {
+ "type": "boolean"
+ },
+ "city": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "saved": {
+ "type": "boolean"
+ },
+ "venue": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "saved",
+ "already_saved",
+ "venue",
+ "city",
+ "kind",
+ "note"
+ ],
+ "type": "object"
+}search_venues1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "scope": {
+ "type": "string"
+ },
+ "showing": {
+ "type": "number"
+ },
+ "total_matches": {
+ "type": "number"
+ },
+ "venues": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "awards": {
+ "type": "string"
+ },
+ "cuisine": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "happy_hour": {
+ "type": "string"
+ },
+ "iconic": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "neighborhood": {
+ "type": "string"
+ },
+ "opened": {
+ "type": "string"
+ },
+ "price": {
+ "type": "string"
+ },
+ "reservation": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "trending": {
+ "type": "boolean"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "cuisine",
+ "neighborhood",
+ "happy_hour",
+ "reservation",
+ "description",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "total_matches",
+ "showing",
+ "venues"
+ ],
+ "type": "object"
+}fetchsearchadd_to_tripget_venuelist_citieslist_curatedlist_my_tripslist_new_venuespost_to_brainread_brainsave_venuesearch_venuesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
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.
Search 7,000+ local service businesses across America by category, location, or keyword.
Add one secure layer between your agents and this server.
fetch and get_venue both describe retrieving the full record for a venue, differing only in an extra long-form story for Iconic 50 venues, making their boundaries unclear. Similarly, search and search_venues both search the same catalog with overlapping descriptions, leaving an agent unsure which to call.
The list_* tools are consistently verb_noun, but search and search_venues repeat the same action with different names, and fetch breaks the otherwise intuitive get_* pattern. The naming is readable but not systematic.
Seven tools is a reasonable count for a venue-discovery server, but redundancy between fetch/get_venue and search/search_venues inflates the set and makes it feel less tight than the domain requires.
The surface covers searching, retrieving details, browsing curated lists, and listing new venues across cities, so core discovery workflows are supported. Minor gaps exist around filtering/sharing list results, but agents can generally complete end-to-end tasks.
