Skip to main content
Glama

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.

MCP client
Glama
MCP server

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.

100% free. Your data is private.
Tool DescriptionsA

Average 4.3/5 across 1 of 1 tools scored.

Server CoherenceA
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'search_events' has a clearly defined and distinct purpose.

Naming Consistency5/5

The naming pattern is trivially consistent as there is only one tool. It follows a clear verb_noun convention with 'search_events', which is a standard and readable format.

Tool Count2/5

A single tool is too few for a server named 'VenuNite Events', which implies a domain of event management. While the tool is comprehensive for search, the lack of tools for creating, updating, deleting, or managing events suggests an incomplete surface for the apparent scope.

Completeness2/5

The server is severely incomplete for an event management domain. It only provides search functionality, with no tools for CRUD operations (e.g., create_event, update_event, delete_event) or other essential actions like booking or user management, which are typical in such systems.

Available Tools

1 tool
search_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of events to return. Default 20. Prefer small (5-10) when the user asked for a single recommendation.
date_endNoISO-8601 end of the search window. Default: 14 days from date_start. 'Tonight' → date_start + 6 hours. 'Next weekend' → date_start + 2 days.
max_costNoUpper bound on event cost in USD. 'cheap' ≈ 15, 'affordable' ≈ 30, 'under $X' → X. Leave unset if the user didn't constrain price.
min_costNoLower bound on event cost. Rarely useful — only set when the user explicitly excluded free events.
vibe_tagsNoCanonical 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.
categoriesNoEvent 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_latNoLatitude (only if you already have precise coordinates — otherwise pass place_name).
center_lngNoLongitude (paired with center_lat).
date_startNoISO-8601 start of the search window. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight.
local_onlyNoSet 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_nameNoHuman-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_textNoFree-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_milesNoSearch 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_venueNoPer-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.
Behavior4/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does an excellent job explaining key behaviors: it describes the search methodology (combines semantic search, filtering), safety tag handling (hard filters that exclude venues without them), and output format (ranked events with score breakdown). However, it doesn't mention rate limits, authentication requirements, or error conditions, which prevents a perfect score despite the strong coverage of core functionality.

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

Conciseness4/5

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

The description is well-structured and appropriately sized for a complex tool. It front-loads the core purpose, then provides important behavioral details and usage guidelines. Every sentence adds value, with no wasted words. However, it could be slightly more concise by integrating some of the tag explanation more tightly, but overall it's efficient and clear.

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

Completeness4/5

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

Given the complexity (13 parameters, no annotations, no output schema), the description does an excellent job providing context. It explains the search methodology, safety tag behavior, and invocation pattern. The main gap is the lack of output schema, so the description doesn't detail the structure of returned events or score breakdowns. However, it compensates well with behavioral transparency and usage guidelines, making it nearly complete for agent understanding.

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

Parameters3/5

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

With 100% schema description coverage, the schema already documents all 13 parameters thoroughly. The description adds some context about the 'vibe_tags' field (mentioning the 49 canonical tags across 6 facets and emphasizing safety-critical tags as hard filters), but most parameter semantics are already covered in the schema. The baseline of 3 is appropriate since the schema does the heavy lifting, though the description provides useful supplemental guidance on tag usage.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Find events matching a user's natural-language request.' It specifies the exact functionality (semantic search, geographic radius filtering, date/cost/category hard filters, safety tags) and distinguishes it from potential alternatives by emphasizing 'Call this ONCE per user query' rather than multiple speculative calls. This is specific, comprehensive, and leaves no ambiguity about what the tool does.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when and how to use this tool. It states 'Call this ONCE per user query with the structured args you inferred from their question — do not try to issue multiple speculative calls,' which clearly defines the invocation pattern. It also explains when to include safety tags ('Only include a safety tag when the user's query explicitly requested it') and provides context on tag usage, making it clear when to apply specific filters versus general queries.

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

Discussions

No comments yet. Be the first to start the discussion!

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources