VenuNite Events
Server Details
Hyperlocal event search across 50 US states — 29K venues, 275K upcoming events.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 1 of 1 tools scored.
Only one tool exists, so there is no possibility of ambiguity or confusion between tools.
The single tool uses a clear verb_noun pattern ('search_events'), which is consistent and predictable even without other tools to compare.
One tool is too few for a server named 'VenuNite Events'. Although the tool is comprehensive, the scope suggests a need for additional CRUD or management tools.
The server only provides search functionality. Missing obvious tools for creating, updating, or deleting events, leaving significant gaps for event management workflows.
Available Tools
1 toolsearch_eventsAInspect
Find events matching a user's natural-language request. Combines semantic search over venue vibes, geographic radius filtering, date/cost/category hard filters, and strict safety tags. Returns ranked events with score breakdown. Call this ONCE per user query with the structured args you inferred from their question — do not try to issue multiple speculative calls.
Tag vocabulary is fixed (49 canonical tags across 6 facets: ambiance, social, time, age, venue_type, activity). See the vibe_tags field description.
Safety-critical tags (queer-friendly, family-friendly, all-ages, 18-plus, 21-plus) are hard filters: if included, venues without that tag are excluded entirely — never just down-ranked. Only include a safety tag when the user's query explicitly requested it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of events to return. Default 20. Prefer small (5-10) when the user asked for a single recommendation. | |
| date_end | No | ISO-8601 end of the search window. Default: 14 days from date_start. 'Tonight' → date_start + 6 hours. 'Next weekend' → date_start + 2 days. | |
| max_cost | No | Upper bound on event cost in USD. 'cheap' ≈ 15, 'affordable' ≈ 30, 'under $X' → X. Leave unset if the user didn't constrain price. | |
| min_cost | No | Lower bound on event cost. Rarely useful — only set when the user explicitly excluded free events. | |
| vibe_tags | No | Canonical vibe vocabulary. Include tags the user explicitly or strongly implied. IMPORTANT: the tags `queer-friendly`, `family-friendly`, `all-ages`, `18-plus`, `21-plus` are HARD filters — only include them when the user's query explicitly asked for that property. Including `family-friendly` for a user who just said 'something fun tonight' will exclude most venues. | |
| categories | No | Event category(s). Map the user's intent: 'live music' → music, 'standup' → comedy, 'trivia night' → trivia-games, 'art opening' → arts-culture. 'anything to do' → omit (no category filter). | |
| center_lat | No | Latitude (only if you already have precise coordinates — otherwise pass place_name). | |
| center_lng | No | Longitude (paired with center_lat). | |
| date_start | No | ISO-8601 start of the search window. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight. | |
| local_only | No | Set true when the user's query implies 'in my immediate area' — 'what's on my block', 'nearby tonight', 'close by'. The server clamps the effective radius to a neighborhood-scale max based on local density (≤10mi urban, ≤30mi suburban, ≤50mi rural), even if radius_miles is larger. Prefer this over guessing a small radius — the server knows the density of the area and you don't. | |
| place_name | No | Human-readable location if the user mentioned one: 'Westminster, CO' or 'Five Points Denver'. Prefer this over lat/lng when you have a name. Always include the state abbrev when the city name is ambiguous. | |
| query_text | No | Free-text vibe description extracted from the user's query. Keep it short — e.g. 'chill jazz' or 'loud rock club'. Omit when the user's request is purely geographic / tag-based (e.g. 'any comedy shows tonight near me'). | |
| radius_miles | No | Search radius in miles. OMIT this field to let the server pick a density-aware default: 5mi in dense metros (Chicago, NYC), 15mi suburban, 25mi rural. Only pass an explicit value when the user's phrasing implies a specific scope: - 'walking distance' / 'on my block' → 2-3 - 'near me' in a dense downtown or neighborhood → 5-7 - 'near me' in a suburb → 10-15 - 'metro area' / 'anywhere in <city>' → 25-30 - rural 'near me' or 'within driving distance' → 25-50 For a user who says 'things to do tonight' in Lincolnwood, Chicago, or any other dense-urban location: omit this field. Passing 15 there pulls events from 8-10 miles away in other neighborhoods, which is worse than the density-aware default. Max 500. Use 'local_only: true' instead of a small radius when you're unsure of local density. | |
| max_events_per_venue | No | Per-venue diversity cap. Default 1 — each venue contributes at most one event, giving a diverse 'what's on' feed. Raise to 3-5 for 'what's on at <specific venue>' queries where the user expects multiple shows from the same room. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits. It explains that safety tags are hard filters (not just down-ranked), that the tool combines semantic and structured search, and that the return includes a score breakdown. This gives the agent a complete understanding of the tool's behavior beyond the schema.
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 well-structured with three clear paragraphs: overall purpose and usage guidance, tag vocabulary, and safety constraints. It is informative without being verbose, and each sentence adds value. While longer than minimal, it earns its length given the tool's complexity.
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 complexity (14 parameters, no output schema), the description covers purpose, usage, parameter semantics, and behavior adequately. It lacks explicit return value structure (only mentions 'ranked events with score breakdown'), but this is a minor gap. The guidance on parameter defaults and inference rules is comprehensive.
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% coverage with detailed descriptions for each parameter. The description adds extra semantic context, such as the fixed tag vocabulary (49 canonical tags across 6 facets), the hard-filter nature of safety tags, and the 'local_only' preference over guessing small radius. This goes beyond schema definitions, providing guidance on parameter selection and usage.
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 purpose: 'Find events matching a user's natural-language request' and lists the combination of search methods used (semantic, geographic, date/cost/category filters, safety tags). It also mentions the return type: 'ranked events with score breakdown.' This is specific and actionable, distinguishing it from any potential sibling tools (none provided).
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 explicit usage guidance: 'Call this ONCE per user query... do not try to issue multiple speculative calls.' It also warns about safety-critical tags: 'Only include a safety tag when the user's query explicitly requested it.' This gives clear context on when and how to use the tool effectively. However, since there are no sibling tools, no comparison is needed.
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.
Discussions
No comments yet. Be the first to start the discussion!