Luma Events MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LUMA_API_KEY | Yes | Your Luma API key | |
| LUMA_API_BASE | No | Optional API base URL for testing or compatible proxies | https://public-api.luma.com |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_connectionA | Verify the configured Luma API key and return the authenticated user. |
| list_eventsA | List events from the calendar attached to the configured API key. |
| get_eventA | Get complete details for one Luma event. |
| get_guestB | Get complete details for one event guest by guest ID, ticket key, guest key, or email. The response contains personal information and ticket-order details. |
| update_guest_statusA | Preview or update one guest's status. The preview shows the exact event, minimal guest identity, current and target status, captured paid-ticket count, refund choice, and notification settings. Moving an approved paid guest to a non-approved status requires an explicit refund choice. |
| update_guest_ticketsA | Preview or add and remove tickets for one guest. Added tickets are complimentary administrative tickets and may exceed capacity. Removed tickets are invalidated without a refund. Luma still sends an in-app notification even when email is disabled. |
| list_ticket_typesA | List all ticket types for an event, optionally including hidden ticket types. |
| get_ticket_typeA | Get one ticket type by its ticket-type ID. |
| create_ticket_typeA | Create a free, paid, or flexible-price ticket type after explicit confirmation. Review the event, price, currency, visibility, approval, sale dates, and capacity before confirming. |
| update_ticket_typeA | Update selected fields on a ticket type after explicit confirmation. Nullable fields clear their current value. |
| delete_ticket_typeA | Preview or delete one ticket type. The preview verifies that the ticket type belongs to the event and shows its exact settings. Luma may refuse deletion when tickets have been sold or when this is the last visible ticket type. |
| add_hostA | Add a host or check-in staff member to an event after explicit confirmation. |
| update_hostA | Update a host's access level or public visibility after explicit confirmation. The event creator's access level cannot be changed. |
| remove_hostA | Preview or remove one host from an event. The preview resolves the event and exact email. Visible hosts include their returned Luma identity; hidden hosts may be omitted from the event response and are clearly marked as unverified before confirmation. |
| create_eventB | Create a Luma event. Call only after the user has explicitly confirmed the event name, date/time, timezone, and supplied details. |
| update_eventB | Update selected fields on a Luma event. Call only after showing the changes and receiving explicit confirmation. |
| delete_eventA | Preview or permanently cancel and delete one Luma event. Call with confirmed=false first to show the exact event, approved guest count, and whether a refund choice is required. Cancellation is irreversible: Luma deletes the event and notifies all guests. Call with confirmed=true only after the user explicitly confirms the event and, for a paid event, whether guests should be refunded. |
| add_guestsA | Add guests directly to an event with tickets and an approved, pending-approval, or waitlist status. This registers guests rather than sending a soft invite. Show the event, recipient count, status, ticket assignment, and email choice before asking for confirmation. |
| send_invitesA | Send soft event invitations by email and, when linked to a Luma account, SMS. Invited people choose whether to register. Show the event, recipient count, and message before asking for confirmation. |
| invite_guests_from_eventA | Build a privacy-conscious audience from selected guest statuses on a source event, remove duplicate emails and anyone already on the target event, and send soft Luma invitations in batches. Call with confirmed=false first to preview aggregate counts without exposing identities; call again with confirmed=true only after explicit approval. |
| approve_waitlisted_guestsA | Approve up to 90 currently waitlisted guests per run, leaving rate-limit headroom. Large waitlists are safely resumable by rerunning the tool until resume_required is false. Call only after showing the event, waitlisted guest count, and email notification choice, then receiving explicit confirmation. |
| list_guestsA | List guests for an event. Guest data may include personal information; use only for event operations requested by the user. |
| registration_summaryA | Count guest approval states and check-ins for an event across all guest pages without returning guest identities. |
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 23 tools
Most tools map to a distinct resource/action combination, but add_guests, send_invites, and invite_guests_from_event occupy similar invite/registration territory, and approve_waitlisted_guests overlaps with update_guest_status at the bulk level. Detailed descriptions help, but an agent could still hesitate between these related actions.
Nearly all tools follow a snake_case verb_noun pattern (create_event, delete_ticket_type, update_guest_status), with resource-consistent CRUD verbs. Minor deviations like registration_summary and synonym variation (add vs create, remove vs delete) keep it from being perfect.
23 tools is at the high end for an MCP server and will feel heavy to navigate, though the count is justified by distinct subdomains (events, guests, hosts, ticket types, invites). It is not excessive enough to be chaotic, but it exceeds the ideal 3-15 range.
Events, hosts, and ticket types have full CRUD/lifecycle coverage, and guests have add/list/get/update operations with bulk approval. Gaps like direct guest removal and guest check-in are noticeable but can be partially worked around through status/ticket updates and registration_summary.