Skip to main content
Glama
Blackie360

Luma Events MCP Server

by Blackie360

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LUMA_API_KEYYesYour Luma API key
LUMA_API_BASENoOptional API base URL for testing or compatible proxieshttps://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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 23 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues