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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the list of returned fields, which is useful but does not describe potential errors, rate limits, or other behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence immediately states the operation and parameter source, then compactly enumerates the returned fields. Every part is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter, a clear field list, and an output schema present, the description is complete for the agent to select and invoke the tool correctly. Annotations cover the safety profile, so no further behavioral caveats are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the id parameter well, including format and an example ('city:id' e.g. 'nyc:1367'). The description restates that the id comes from `search` but adds no meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: get the full Dim Hour record for a venue by id, and enumerates the fields returned. However, it does not differentiate itself from the sibling get_venue, which may serve an overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: use the id returned from `search`. It does not, however, explicitly discuss when to choose this tool over get_venue or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Dim Hour record for one venue: description, signature dishes, address, hours, phone, happy hour, reservation platform, awards, website, Instagram, and (for Iconic 50 venues) the long-form story.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Venue id from search_venues | |
| city | Yes | City name or key | |
| name | No | Venue name (used if id not given) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| lat | No | |
| lng | No | |
| url | Yes | |
| name | Yes | |
| tags | Yes | |
| hours | Yes | |
| phone | Yes | |
| price | No | |
| score | No | |
| story | No | |
| awards | Yes | |
| dishes | Yes | |
| iconic | No | |
| opened | No | |
| address | Yes | |
| cuisine | Yes | |
| website | Yes | |
| photoUrl | Yes | |
| trending | No | |
| city_name | Yes | |
| Yes | ||
| happy_hour | Yes | |
| highlights | No | |
| price_tier | No | |
| description | Yes | |
| reservation | Yes | |
| neighborhood | Yes | |
| other_locations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, non-destructive nature of the tool. The description adds useful behavior context by listing the returned fields and noting the special long-form story condition for Iconic 50 venues. However, it does not disclose behaviors such as parameter precedence, required city context, error cases, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that states the primary purpose immediately and then uses a compact field list to convey the response contents. Every phrase earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the explicit field list, the Iconic 50 conditional, the read-only annotations, and a fully described input schema, an agent can understand what this tool returns and that it is a safe read operation. The main gap is the lack of guidance on how to choose among id, city, and name when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, city, and name. The description adds no additional parameter-level meaning, such as how id and name interact or why city is required, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('the full Dim Hour record for one venue'), then enumerates the exact content fields returned. This distinguishes it from the list/search siblings, which operate over multiple venues, by emphasizing a single-venue detail lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like search_venues or search. It implies a detail-lookup purpose ('full record for one venue'), but does not tell the agent to first obtain a venue id via search_venues or explain the role of the required city parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 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 cover readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is established. The description adds the concrete detail that the result is a fixed set of exactly 24 cities, reinforcing the closed-world annotation, but adds nothing about edge cases or error behavior. This is modest value beyond the annotations, consistent with a 3.
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 18-word sentence places the verb and resource first, then the key-purpose detail. Every word earns its place; there is no repetition of the title or annotations.
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 enumeration tool, the description plus annotations and output schema are fully sufficient. It states the count, the scope (Dim Hour), and the purpose of the returned key, while safety is covered by annotations and return shape by 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 has zero parameters, so the baseline of 4 applies; the description correctly implies no inputs are needed. Schema coverage is 100% vacuously, and the description does not mislead about any inputs. There is nothing further to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List'), a concrete resource ('the 24 cities Dim Hour covers'), and a precise scope (a fixed set of 24). It also states what the output is for ('city key to pass to the other tools'), leaving no ambiguity. Sibling tools are all venue/search operations, so this enumeration tool is clearly distinguishable by domain.
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 'with the city key to pass to the other tools' gives clear contextual guidance: this is a prerequisite lookup for downstream city-keyed calls. It does not have explicit when-not conditions or named alternatives, but given that every sibling tool operates on venues or searches, the routing is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dim Hour's editorial themed lists for a city (e.g. 'Unmarked Doors' speakeasies). Without list_id: returns all list titles. With list_id: returns that list's venues with editorial notes.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or key | |
| list_id | No | A list id from the no-arg call |
| Name | Required | Description |
|---|---|---|
| id | No | |
| city | Yes | |
| note | No | |
| lists | No | |
| title | No | |
| venues | No | |
| subtitle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by disclosing the dual-mode behavior: without list_id it returns titles, with list_id it returns venues and editorial notes. This makes the tool's actual behavior fully transparent to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences convey the theme, the example, and the two call modes without any filler. The most important scoping information ('editorial themed lists for a city') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, two parameters, existing output schema, and annotations, the description is complete. It covers both invocation modes and the nature of the returned data, leaving no essential gap for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how list_id changes the output semantics and confirming that city scopes the editorial lists. This extra context helps the agent understand the parameters' roles beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource ('Dim Hour's editorial themed lists for a city') and the specific behaviors for both call modes ('Without list_id: returns all list titles. With list_id: returns that list's venues with editorial notes.'). This is a specific verb+resource statement that distinguishes the tool from generic venue-list siblings like list_new_venues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: the tool is for editorial lists, and it explicitly explains how the optional list_id changes the result. It does not explicitly name sibling alternatives or state when not to use the tool, but the conditional behavior provides enough guidance for the common cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Venues recently added to the Dim Hour catalog — across all 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?
With readOnlyHint and destructiveHint annotations already covering safety, the description adds valuable behavioral detail: scoring affects ordering, non-scored venue types are grouped after scored ones, ordering is by recency within groups, and pre-2026-06-06 dates are estimates. These are exactly the kind of non-obvious behaviors an agent needs to interpret results correctly.
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 and well-organized: purpose first, then use cases, then result ordering, then the 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?
The description covers what the tool does, when to use it, how results are ordered and grouped, and the key data-quality caveat about estimated dates. Combined with a complete input schema and an output schema, nothing essential is missing for an agent to select and invoke 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. The description reinforces the city scope ('across all 24 cities or one city') but adds no new parameter-level meaning beyond the schema 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?
The description states a specific verb and resource: listing venues recently added to the Dim Hour catalog, with a clear scope of all 24 cities or one city. The phrase 'recently added' cleanly distinguishes it from sibling tools like search or list_curated without needing to open their schemas.
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 names concrete use cases: 'what's new on Dim Hour', new-opening alerts, and weekly digests. It does not provide exclusion criteria or directly reference alternatives, but the stated use cases give an agent clear context for when this tool is appropriate.
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 declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context by specifying that results are ranked venues and include a dimhour.com link for each. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The tool's purpose and scope are front-loaded, followed immediately by query guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, an output schema, and annotations covering safety and scope, the description is complete. It explains what the tool searches, what results look like, and what kinds of queries to use it for. No critical information 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?
The schema already documents the single query parameter with examples, so baseline is 3. The description adds meaningful semantic guidance by enumerating what kinds of queries are supported (cuisine, dish, neighborhood, city, vibe, or award), going 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 the tool searches Dim Hour's restaurant, bar, and venue catalog across 24 cities, and that it returns ranked venues with dimhour.com links. It does not explicitly differentiate from the sibling 'search_venues', but the scope and output are specific enough for an agent to understand the core function.
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 guidance on when to use this tool: 'questions about where to eat or drink' and lists query facets like cuisine, dish, neighborhood, city, vibe, or award. It does not mention when not to use it or point to alternatives such as list_curated or search_venues, but the use context is otherwise well defined.
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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: query content words are matched individually, filler words are ignored, results are ranked with a 0-100 score, and the response includes price tier, neighborhood, happy-hour info, and a link. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences that front-load the purpose and city behavior, then cover return fields and query strategy. There is no fluff, repetition, or unnecessary restatement of schema details. Every sentence contributes useful 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 an 11-parameter, all-optional tool, the description covers the essential behaviors: city scoping, query semantics, output contents, and combining filters. The output schema and annotations fill most remaining gaps. It could be more explicit about routing between this tool and the generic 'search' sibling, but an agent has enough context to 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%, so the input schema already documents all 11 parameters in detail; the baseline is 3. The description reinforces query matching semantics and provides useful examples, but it does not add substantial per-parameter meaning beyond what the schema already states. It earns some credit for the city behavior and keyword guidance, but not enough to exceed the 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?
The description states a specific verb and resource: it searches Dim Hour's restaurant, bar, and venue catalog. It also clarifies the core scoping decision (pass city vs. omit for all venues), which helps an agent understand what the tool targets. It stops short of 5 because it does not explicitly differentiate itself from the generic 'search' sibling.
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 for using the tool: pass city to narrow to one city, omit it to search all 19,000+ venues, and use one strong keyword rather than a sentence. It also advises combining with filters. However, it does not mention alternatives or exclusions relative to siblings like 'search' or 'list_*', so it lacks explicit when-not-to-use 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.
fetchget_venuelist_citieslist_curatedlist_new_venuessearchsearch_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!
Add one secure layer between your agents and this server.
fetch and get_venue both retrieve essentially the same full venue record, differing only by an extra long-form story field. Similarly, search and search_venues both search the same catalog and return ranked venue results, making it unclear which one an agent should call and creating real misselection risk.
The list_* tools are consistent and readable, and most tools use snake_case verb_noun naming. However, fetch and search are bare verbs, and fetch vs get_venue introduces two different verbs for the same operation, so the overall pattern is mixed but still understandable.
Seven tools is a reasonable size for a venue guide server, but the count is slightly padded because fetch duplicates get_venue and search duplicates search_venues. The effective surface is closer to five distinct tools, so the count is slightly over what is needed.
The read-only domain is well covered: city discovery, search, curated editorial lists, new venue updates, and full venue details are all present, and search naturally leads into detail retrieval. Minor gaps exist, such as no dedicated non-search way to browse all venues in a city, but the core workflows have no dead ends.