TicketSource MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TICKETSOURCE_API_KEY | Yes | Your API key, sent as a Bearer token. | |
| TICKETSOURCE_BASE_URL | No | Defaults to `https://api.ticketsource.io`. Used by the tests. | https://api.ticketsource.io |
| TICKETSOURCE_ALLOW_WRITES | No | `true` to enable `add_customer_note`. Off by default. | false |
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 |
|---|---|
| list_eventsA | List the events on this TicketSource account (name, category, published and archived status). Archived events are skipped unless asked for. |
| get_eventA | Get one event with its venues and performance dates. By default only dates from today onwards are returned. |
| list_upcoming_performancesA | What's on: performance dates across all active events in the next N days, soonest first, with the event name. Use the returned dat- id with get_performance_bookings. |
| get_performance_bookingsA | Who is coming to one performance date: every booking with totals (gross, net, fees, refunds, donations) and an overall summary. Set include_attendees to also list seats and attendee names. |
| get_bookingA | One booking with its totals, seats and attendee names, plus the customer ID. |
| find_customersA | Search customers by part of their name, email or phone number. The API has no server-side search, so this pages through the customer list (100 per call) up to max_pages. |
| get_customerB | A customer's contact details, membership and marketing consent, with their staff notes and most recent bookings. |
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 7 tools
Each tool targets a distinct resource and action: events, performances, bookings, and customers are clearly separated. Even list_events and list_upcoming_performances differ in scope (all events vs. upcoming performance dates), eliminating ambiguity.
All tools follow the consistent verb_noun pattern in snake_case (list_*, get_*, find_*). The naming is uniform and predictable, with no mixed conventions or vague verbs.
Seven tools is well-scoped for a read-only ticketing information server. Each tool has a clear purpose and the count falls comfortably in the ideal 3-15 range.
The surface covers core retrieval workflows: events, performances, bookings, and customers. Minor gaps exist (e.g., no create/update operations, no direct booking-by-event search), but these align with a read-only information source and do not block typical usage.