Luma Events MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GEOCODING_API_KEY | No | API key for geocoding provider (required if using google or mapbox). | |
| GEOCODING_PROVIDER | No | Geocoding provider (google, mapbox, or nominatim). Default nominatim. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| set_preferencesA | Save default search preferences (persists across restarts). IMPORTANT for agents:
Args: categories: List of category slugs to set as defaults. Must be from: tech, ai, food, arts, climate, fitness, wellness, crypto. address: Street address for distance filtering center point. max_distance_miles: Default search radius in miles. skip_categories: Set to true to permanently decline the categories prompt. skip_address: Set to true to permanently decline the address prompt. |
| search_eventsA | Search for Luma events. Two modes depending on whether Home mode (no Travel mode ( The default time window is the next 2 weeks. Use IMPORTANT for agents:
Args: city: Luma city for travel mode (e.g. "sf", "london", "los angeles"). category: One-off category override for home mode. Must be an exact slug. keywords: Filter by keywords (matches title/description). Use for specific terms. center_address: One-off address to filter around (e.g. "Union Square, San Francisco"). Overrides stored address for this search only. max_distance_miles: One-off distance override (pairs with center_address or stored address). after: ISO 8601 datetime — only events starting after this time. before: ISO 8601 datetime — only events starting before this time. days: Search window in days from now (e.g. 7, 30). Overrides the default 14-day window. Simpler alternative to after/before. latin_only: Filter out non-Latin-script events. Auto-detected from region when not set. added_within_days: Only return events first seen within this many days. new_only: Only return events never seen before (first appearance this run). sort: Sort order — "date" (default), "distance", or "newest". login: Set to true to open browser and log in to Luma. skip_login_days: Decline login for N days (0 = ask next time, -1 = never). |
| get_eventB | Get full details for a single Luma event. Args: event_id: Luma event API id (e.g. "evt-abc123"). url: lu.ma event URL or ID (e.g. "https://lu.ma/myevent" or "myevent"). |
| export_event_icsA | Generate an ICS calendar string for a Luma event (Add to Calendar). Args: event_id: Luma event API id (e.g. "evt-abc123"). url: lu.ma event URL or ID. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: export_event_ics generates calendar files, get_event retrieves event details, search_events searches for events, and set_preferences saves search defaults. There is no functional overlap.
All tool names follow a consistent verb_noun snake_case pattern: export_event_ics, get_event, search_events, set_preferences. This predictability helps agents select the right tool.
Four tools cover the core functionality of searching, retrieving details, exporting calendar data, and setting preferences. This is a well-scoped set for an event discovery server.
The tool set covers search, retrieval, and export, but lacks actions like creating or managing events, or handling user RSVPs. For a discovery-focused server this is reasonable, but there are minor gaps.