VenuNite Events
Server Details
Local US events: trivia, libraries, markets and gigs, with VenuNite links and ticket handoffs.
- Status
- Healthy
- Uptime
- 66.9% over 36 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 2 tools
The two tools are sharply distinct: one searches for events and the other creates a handoff for a specific event_id. There is no ambiguity about which tool to call for a given step in the workflow.
Both tool names follow the same verb_noun snake_case pattern: search_events and create_ticket_handoff. The naming clearly indicates action and object.
Two tools is on the thin side, but the pair covers a reasonable minimal workflow of searching events and handing off to ticket pages. It feels borderline rather than egregiously sparse.
The search-to-handoff flow is covered end-to-end, including provenance links and explicit handoff limitations. Minor gaps exist, such as no dedicated get_event_details tool, but search results already carry the needed facts and URLs.
Available Tools
2 toolscreate_ticket_handoffCreate Ticket HandoffAInspect
When the user wants to proceed to tickets for a specific search result, create an attributed VenuNite handoff using its event_id. Requires a live API key issued at https://venunite.com/developers/keys. Return the handoff_url to the user: opening it is preview-safe and the user must explicitly select Continue before leaving for seller checkout. Do not follow or submit the Continue form for the user. This tool records a handoff but does not purchase, reserve, hold inventory, guarantee availability or final prices, or confirm a booking. Calls count against normal MCP tool-call limits; no search-result rows are charged. The handoff service also limits creation to 10 per minute per account.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | The stable VenuNite event_id returned by search_events. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate readOnly=false, idempotent=false, and openWorld=true. The description goes well beyond these by explaining that the returned handoff_url is preview-safe, the user must explicitly select Continue, the agent must not submit the Continue form, calls count against limits, and creation is rate-limited to 10 per minute. It also clarifies the tool's non-committal nature regarding purchases and reservations.
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 dense but well-organized: the trigger and core action are front-loaded, followed by critical prerequisites, user-safety requirements, and operational constraints. Every sentence adds necessary information, and there is 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?
Given that an output schema exists, the return value is already specified elsewhere. The description otherwise covers prerequisites, side effects, rate limits, billing implications, and the important constraint that the agent must not advance checkout on the user's behalf. This is complete for an agent to invoke the tool safely and 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% and the event_id parameter is already documented as the stable VenuNite event_id returned by search_events. The description mentions using the event_id but adds no meaningful parameter semantics beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: create an attributed VenuNite handoff for a specific search result. It uses a specific verb and resource, and it is clearly distinguishable from the sibling search_events tool because it is about proceeding to tickets rather than searching.
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 the tool: when the user wants to proceed to tickets for a specific search result. It also states when not to rely on it by clarifying that it does not purchase, reserve, hold inventory, guarantee prices, or confirm bookings, and it gives the prerequisite of a live API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsSearch Local 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 event facts, stable event_id values, canonical VenuNite event_url links when a stored slug exists, original source_url links for provenance, and the filters that shaped the results. The legacy url field remains the original source. Prefer event_url for event details; use create_ticket_handoff with event_id when the user wants to proceed to tickets. Call this ONCE per user query with the structured args you inferred from their question — do not try to issue multiple speculative calls.
The tool cannot buy tickets, create or modify events, edit calendars, or message organizers. Calls record private quota and request telemetry. An uncached place_name is sent to the public Nominatim geocoder.
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: results that don't satisfy them are excluded entirely, never just down-ranked. family-friendly, all-ages, 18-plus and 21-plus are judged on each event's own audience and age policy, with the venue's tag counting only when the event's classification doesn't contradict it; queer-friendly is a venue tag. Only include a safety tag when the user's query explicitly requested it.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ordering axis. Results are presented by calendar day in timezone; sort orders within each day. With query_text and no explicit sort (or relevance), the server selects the strongest event-text and venue-vibe matches before applying that day order. Explicit date, distance, or demand sorts select by day and that axis. Without query_text, default date is chronological. | |
| limit | No | Number of events to return. Default 20. Prefer small (5-10) when the user asked for a single recommendation. | |
| date_end | No | Exclusive ISO-8601 end of the search window, including the local UTC offset. Default: 14 days from date_start. 'Tonight' → date_start + 6 hours. 'Next weekend' → date_start + 2 days. An event starting exactly at date_end is outside this window. | |
| max_cost | No | Upper bound on event cost in USD. 'cheap' ≈ 15, 'affordable' ≈ 30, 'under $X' → X. Set include_unknown_prices=false when the user explicitly wants a verified budget such as 'under $100'. max_cost=0 returns only proven-free events. 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. | |
| timezone | No | IANA timezone (e.g. 'America/New_York') used for the calendar-day grouping of results. Default UTC — pass the user's local zone so 'today/tomorrow' day buckets match their clock. | |
| 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 events. | |
| 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_match | No | overlap includes events already running during the window, such as multi-day festivals or prior-night shows; events ending exactly at date_start are excluded. starts_within requires the event to start at or after date_start and before date_end. Prefer starts_within for requests about events starting tomorrow, on a specified date, this evening, or this weekend. Keep overlap when the user asks what is currently happening or wants ongoing activities. | overlap |
| date_start | No | Inclusive ISO-8601 start of the search window, including the local UTC offset. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight. The timezone field controls day grouping, not parsing: date-times without an offset are interpreted as UTC. Use date_match=starts_within when the user wants events starting on a particular date or evening. | |
| 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 guessed lat/lng when you have a name; existing precise coordinates take precedence. Always include the state abbrev when the city name is ambiguous. An unresolved place returns location_unresolved; correct the place or use known coordinates rather than dropping the location. | |
| 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'). | |
| state_hint | No | Two-letter state abbreviation to disambiguate place_name (e.g. place_name 'Frederick' + state_hint 'MD'). Unnecessary when place_name already contains the state. | |
| 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. Range 0.5 to 500. An out-of-range value FAILS the entire call and returns zero events — it is not clamped — so omit the field rather than guessing. 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. | |
| include_unknown_prices | No | Include events whose admission price cannot be determined. Default true preserves broad discovery; positive price bounds may then include unknown prices, which must be labeled unverified. Set false with min_cost/max_cost when the user explicitly requires a verified budget. This never relaxes the proven-free requirement of max_cost=0. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| results | Yes | |
| applied_filters | No | |
| validation_errors | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only convey readOnlyHint=false/openWorldHint/idempotentHint=false, so the description carries the burden — and it delivers: it discloses that calls 'record private quota and request telemetry', that an uncached place_name 'is sent to the public Nominatim geocoder', and that the tool cannot buy tickets, modify events, edit calendars, or message organizers. It also explains the hard-filter exclusion semantics for safety tags, which is genuine behavioral context beyond the annotation flags.
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 long (~250 words) but front-loaded with a clear purpose sentence, then organized into coherent blocks: return semantics, usage constraints, side effects, and tag policy. Each paragraph earns its place, though the safety-tag hard-filter guidance partially duplicates the vibe_tags schema description, and the length slightly exceeds what a leaner rewrite could achieve.
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 19-parameter, no-required-args search tool with an output schema present, the description is complete: it covers call frequency, field-usage philosophy, side effects, capabilities/limits, sibling routing, and tag-filter semantics. With the output schema and 100% schema coverage handling return shape and parameter details, nothing an agent needs to invoke this correctly 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?
Schema coverage is 100% and the schema descriptions are already rich (radius_miles has detailed mapping, date_start/date_end give defaults, vibe_tags warns about hard filters), so baseline is 3. The description adds value above that by defining the fixed tag vocabulary (49 canonical tags across 6 facets), clarifying how family-friendly/all-ages safety tags are judged (event classification over venue tag, with queer-friendly being purely a venue tag), and reinforcing the explicit-request rule for safety tags.
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?
Opens with a specific verb and resource ('Find events matching a user's natural-language request') and enumerates the exact mechanism (semantic search, radius filtering, hard filters, safety tags) and return payload. It also distinguishes itself from the only sibling, create_ticket_handoff, by specifying when to use that tool instead. No ambiguity remains about what this tool does.
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 explicit when-to-use guidance ('Call this ONCE per user query... do not try to issue multiple speculative calls') and names the alternative with its trigger condition ('use create_ticket_handoff with event_id when the user wants to proceed to tickets'). It also warns against common misuse (speculative calls, guessing radii, including safety tags the user didn't request).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Added
create_ticket_handoff - Changed
search_events3 fields changed- added
Output schema / properties / results / items / properties / event_idAdded value: +{ + "description": "Stable VenuNite identity; use this value with create_ticket_handoff.", + "type": "integer" +} - added
Output schema / properties / results / items / properties / event_urlAdded value: +{ + "description": "Canonical VenuNite event page; null when no stored slug exists. Prefer this link for event details.", + "format": "uri", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / results / items / properties / source_urlAdded value: +{ + "description": "Original event source for provenance. The legacy url field retains the same meaning.", + "format": "uri", + "type": [ + "string", + "null" + ] +}
1 tool update
- Changed
search_events1 field changed- changed
Input schema / properties / vibe_tags / descriptionPrevious value: -"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."New value: +"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 events."
1 tool update
- Changed
search_events3 fields changed- changed
Input schema / properties / radius_miles / descriptionPrevious value: -"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:\n - 'walking distance' / 'on my block' → 2-3\n - 'near me' in a dense downtown or neighborhood → 5-7\n - 'near me' in a suburb → 10-15\n - 'metro area' / 'anywhere in <city>' → 25-30\n - rural 'near me' or 'within driving distance' → 25-50\n\nFor 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.\n\nMax 500. Use 'local_only: true' instead of a small radius when you're unsure of local density."New value: +"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:\n - 'walking distance' / 'on my block' → 2-3\n - 'near me' in a dense downtown or neighborhood → 5-7\n - 'near me' in a suburb → 10-15\n - 'metro area' / 'anywhere in <city>' → 25-30\n - rural 'near me' or 'within driving distance' → 25-50\n\nFor 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.\n\nRange 0.5 to 500. An out-of-range value FAILS the entire call and returns zero events — it is not clamped — so omit the field rather than guessing. Use 'local_only: true' instead of a small radius when you're unsure of local density." - added
Input schema / properties / radius_miles / maximumAdded value: +500 - added
Input schema / properties / radius_miles / minimumAdded value: +0.5
1 tool update
- Changed
search_events3 fields changed- added
Output schema / properties / applied_filters / properties / horizon_endAdded value: +{ + "format": "date-time", + "type": [ + "string", + "null" + ] +} - added
Output schema / properties / applied_filters / properties / policy_versionAdded value: +{ + "type": [ + "integer", + "null" + ] +} - added
Output schema / properties / applied_filters / properties / requested_limitAdded value: +{ + "type": [ + "integer", + "null" + ] +}
1 tool update
- Changed
search_events8 fields changed- changed
Input schema / properties / date_end / descriptionPrevious value: -"ISO-8601 end of the search window. Default: 14 days from date_start. 'Tonight' → date_start + 6 hours. 'Next weekend' → date_start + 2 days."New value: +"Exclusive ISO-8601 end of the search window, including the local UTC offset. Default: 14 days from date_start. 'Tonight' → date_start + 6 hours. 'Next weekend' → date_start + 2 days. An event starting exactly at date_end is outside this window." - added
Input schema / properties / date_matchAdded value: +{ + "default": "overlap", + "description": "overlap includes events already running during the window, such as multi-day festivals or prior-night shows; events ending exactly at date_start are excluded. starts_within requires the event to start at or after date_start and before date_end. Prefer starts_within for requests about events starting tomorrow, on a specified date, this evening, or this weekend. Keep overlap when the user asks what is currently happening or wants ongoing activities.", + "enum": [ + "overlap", + "starts_within" + ], + "type": "string" +} - changed
Input schema / properties / date_start / descriptionPrevious value: -"ISO-8601 start of the search window. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight. NOTE: the window matches by OVERLAP — an event that STARTED before date_start but is still running during the window (multi-day festival, a show that ends after midnight) is included. Filter client-side on `start` if you strictly need events that begin inside the window."New value: +"Inclusive ISO-8601 start of the search window, including the local UTC offset. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight. The timezone field controls day grouping, not parsing: date-times without an offset are interpreted as UTC. Use date_match=starts_within when the user wants events starting on a particular date or evening." - added
Input schema / properties / include_unknown_pricesAdded value: +{ + "default": true, + "description": "Include events whose admission price cannot be determined. Default true preserves broad discovery; positive price bounds may then include unknown prices, which must be labeled unverified. Set false with min_cost/max_cost when the user explicitly requires a verified budget. This never relaxes the proven-free requirement of max_cost=0.", + "type": "boolean" +} - changed
Input schema / properties / max_cost / descriptionPrevious value: -"Upper bound on event cost in USD. 'cheap' ≈ 15, 'affordable' ≈ 30, 'under $X' → X. Leave unset if the user didn't constrain price."New value: +"Upper bound on event cost in USD. 'cheap' ≈ 15, 'affordable' ≈ 30, 'under $X' → X. Set include_unknown_prices=false when the user explicitly wants a verified budget such as 'under $100'. max_cost=0 returns only proven-free events. Leave unset if the user didn't constrain price." - changed
Input schema / properties / place_name / descriptionPrevious value: -"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."New value: +"Human-readable location if the user mentioned one: 'Westminster, CO' or 'Five Points Denver'. Prefer this over guessed lat/lng when you have a name; existing precise coordinates take precedence. Always include the state abbrev when the city name is ambiguous. An unresolved place returns location_unresolved; correct the place or use known coordinates rather than dropping the location." - added
Output schema / properties / applied_filters / properties / date_matchAdded value: +{ + "enum": [ + "overlap", + "starts_within" + ], + "type": "string" +} - added
Output schema / properties / applied_filters / properties / include_unknown_pricesAdded value: +{ + "type": "boolean" +}
1 tool update
- Changed
search_events1 field changed- changed
Input schema / properties / sort / descriptionPrevious value: -"Ordering axis. Results are always grouped chronologically by calendar day (in `timezone`); `sort` orders WITHIN each day. 'date' (default) = by start time; 'distance' = nearest first; 'demand' = most popular first; 'relevance' = semantic score first (best with query_text)."New value: +"Ordering axis. Results are presented by calendar day in timezone; sort orders within each day. With query_text and no explicit sort (or relevance), the server selects the strongest event-text and venue-vibe matches before applying that day order. Explicit date, distance, or demand sorts select by day and that axis. Without query_text, default date is chronological."
1 tool update
- Changed
search_events1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": false, + "anyOf": [ + { + "required": [ + "applied_filters" + ] + }, + { + "required": [ + "error" + ] + } + ], + "properties": { + "applied_filters": { + "additionalProperties": false, + "properties": { + "categories": { + "items": { + "type": "string" + }, + "type": "array" + }, + "center": { + "anyOf": [ + { + "items": { + "type": "number" + }, + "maxItems": 2, + "minItems": 2, + "type": "array" + }, + { + "type": "null" + } + ] + }, + "d_half_miles": { + "type": "number" + }, + "date_end": { + "format": "date-time", + "type": "string" + }, + "date_start": { + "format": "date-time", + "type": "string" + }, + "density_class": { + "type": [ + "string", + "null" + ] + }, + "limit": { + "type": "integer" + }, + "local_only": { + "type": "boolean" + }, + "max_cost": { + "type": [ + "number", + "null" + ] + }, + "max_events_per_venue": { + "type": "integer" + }, + "min_cost": { + "type": [ + "number", + "null" + ] + }, + "original_radius_miles": { + "type": [ + "number", + "null" + ] + }, + "original_strict_tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "query_text": { + "type": [ + "string", + "null" + ] + }, + "radius_miles": { + "type": "number" + }, + "relaxed": { + "items": { + "type": "string" + }, + "type": "array" + }, + "soft_tags": { + "items": { + "type": "string" + }, + "type": "array" + }, + "sort": { + "type": "string" + }, + "sort_requested": { + "type": [ + "string", + "null" + ] + }, + "strict_tags": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "error": { + "type": "string" + }, + "results": { + "items": { + "additionalProperties": false, + "properties": { + "age": { + "type": [ + "string", + "null" + ] + }, + "category": { + "type": [ + "string", + "null" + ] + }, + "cost_numeric": { + "type": [ + "number", + "null" + ] + }, + "cost_text": { + "type": [ + "string", + "null" + ] + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "end": { + "format": "date-time", + "type": [ + "string", + "null" + ] + }, + "image_url": { + "format": "uri", + "type": [ + "string", + "null" + ] + }, + "is_free": { + "type": [ + "boolean", + "null" + ] + }, + "slug": { + "type": [ + "string", + "null" + ] + }, + "start": { + "format": "date-time", + "type": [ + "string", + "null" + ] + }, + "title": { + "type": "string" + }, + "url": { + "format": "uri", + "type": [ + "string", + "null" + ] + }, + "venue": { + "additionalProperties": false, + "properties": { + "city": { + "type": [ + "string", + "null" + ] + }, + "distance_miles": { + "type": [ + "number", + "null" + ] + }, + "name": { + "type": "string" + }, + "state": { + "type": [ + "string", + "null" + ] + }, + "vibeTags": { + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "name", + "city", + "state", + "vibeTags", + "distance_miles" + ], + "type": "object" + } + }, + "required": [ + "title", + "slug", + "description", + "start", + "end", + "cost_text", + "is_free", + "cost_numeric", + "age", + "category", + "url", + "image_url", + "venue" + ], + "type": "object" + }, + "type": "array" + }, + "validation_errors": { + "items": { + "additionalProperties": false, + "properties": { + "field": { + "type": "string" + }, + "message": { + "type": "string" + } + }, + "required": [ + "field", + "message" + ], + "type": "object" + }, + "type": "array" + } + }, + "required": [ + "results" + ], + "type": "object" +}
1 tool update
- Changed
search_events5 fields changed- changed
Input schema / properties / categories / items / enumPrevious value: -[ - "music", - "karaoke", - "sports", - "comedy", - "theater", - "trivia-games", - "food-drink", - "arts-culture", - "community" -]New value: +[ + "music", + "karaoke", + "sports", + "comedy", + "theater", + "trivia-games", + "food-drink", + "arts-culture", + "community", + "festivals" +] - changed
Input schema / properties / date_start / descriptionPrevious value: -"ISO-8601 start of the search window. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight."New value: +"ISO-8601 start of the search window. Default: now. For 'tonight' pass now. For 'this weekend' pass the upcoming Saturday midnight. NOTE: the window matches by OVERLAP — an event that STARTED before date_start but is still running during the window (multi-day festival, a show that ends after midnight) is included. Filter client-side on `start` if you strictly need events that begin inside the window." - added
Input schema / properties / sortAdded value: +{ + "description": "Ordering axis. Results are always grouped chronologically by calendar day (in `timezone`); `sort` orders WITHIN each day. 'date' (default) = by start time; 'distance' = nearest first; 'demand' = most popular first; 'relevance' = semantic score first (best with query_text).", + "enum": [ + "date", + "distance", + "demand", + "relevance" + ], + "type": "string" +} - added
Input schema / properties / state_hintAdded value: +{ + "description": "Two-letter state abbreviation to disambiguate place_name (e.g. place_name 'Frederick' + state_hint 'MD'). Unnecessary when place_name already contains the state.", + "type": "string" +} - added
Input schema / properties / timezoneAdded value: +{ + "description": "IANA timezone (e.g. 'America/New_York') used for the calendar-day grouping of results. Default UTC — pass the user's local zone so 'today/tomorrow' day buckets match their clock.", + "type": "string" +}
1 tool update
- Changed
search_events4 fields changed- added
Input schema / properties / local_onlyAdded value: +{ + "default": false, + "description": "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.", + "type": "boolean" +} - changed
Input schema / properties / radius_miles / defaultPrevious value: -15New value: +null - changed
Input schema / properties / radius_miles / descriptionPrevious value: -"Search radius in miles. Default 15 if the user said 'near X' without specifying. 25-30 for 'metro area', 5 for 'walking distance'. Max 500."New value: +"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:\n - 'walking distance' / 'on my block' → 2-3\n - 'near me' in a dense downtown or neighborhood → 5-7\n - 'near me' in a suburb → 10-15\n - 'metro area' / 'anywhere in <city>' → 25-30\n - rural 'near me' or 'within driving distance' → 25-50\n\nFor 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.\n\nMax 500. Use 'local_only: true' instead of a small radius when you're unsure of local density." - changed
Input schema / properties / vibe_tags / descriptionPrevious value: -"Canonical vibe vocabulary. Include tags the user explicitly or strongly implied. IMPORTANT: the tags `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."New value: +"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."
1 tool update
- First observed
search_events
Related MCP Connectors
Search 190k+ US live events; every ticket bought funds animal-shelter supplies at no extra cost.
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
European and US event data from Eventbrite: dates, venues, categories, ticket prices, organizers.
Live LA events, ticket price comparison, bars & nightlife with real-time happy hours
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides music events, concerts, music festivals, nightclubs and other events information.172MIT
- AlicenseNot gradedqualityDmaintenanceDiscover tech events, startup meetups, AI events across cities including hidden ones.25 npm2MIT
- AlicenseAqualityAmaintenanceMCP server for the On the Cheap network — local guides to free and cheap things to do across 14 US cities. Provides daily event listings with times, prices and venues, plus a searchable archive of deals and guides.8401 npmMIT
- AlicenseAqualityDmaintenanceEnables users to search for events, performers, and venues through the SeatGeek API. Provides event recommendations, detailed venue seating information, and performer discovery capabilities for ticketed entertainment events.43MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.