Skip to main content
Glama
prmichaelsen

eventbrite-mcp

by prmichaelsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

list_attendees

Retrieve a paginated list of attendees for an event by ID, with optional filters by status, changed date, or attendee IDs.

Instructions

List Attendees by Event ID. Returns a paginated response.

ENDPOINT: GET /events/{event_id}/attendees/

ATTENDEE OBJECT: The Attendee object represents the details of Attendee (ticket holder to an Event). The model is one Attendee per each sold ticket. If the Event is specified to only collect information on the Order owner (the default), all returned Attendees have the same information, apart from the barcodes and Ticket Class ID. Attendee objects are considered private; meaning that all Attendee information is only available to the User and Order owner.

ATTENDEE FIELDS RETURNED:

  • created (datetime): Attendee creation date and time (i.e. when order was placed)

  • changed (datetime): Date and time of last change to Attendee

  • ticket_class_id (string): Ticket Class used by Attendee when registering

  • variant_id (string): Variant of Ticket Class used by Attendee when registering

  • ticket_class_name (string): Name of Ticket Class used by Attendee when registering

  • quantity (integer): Always 1

  • costs (attendee_cost): Attendee ticket cost breakdown

  • profile (attendee-profile): Attendee basic profile information

  • addresses (attendee-addresses): Attendee address

  • questions (attendee-questions, optional): Custom questions for the Attendee

  • answers (attendee-answers, optional): Attendee's answers to custom questions

  • barcodes (attendee-barcodes): Attendee's entry bar code

  • team (attendee-team, optional): Attendee team information

  • affiliate (attendee-affiliate, optional): Attendee's affiliate code

  • checked_in (boolean): true = Attendee checked in

  • cancelled (boolean): true = Attendee cancelled

  • refunded (boolean): true = Attendee receives a refund

  • status (string): Attendee status

  • event_id (string): Event ID of the Attendee's Event

  • order_id (string): Order ID under which this Attendee's ticket was purchased

  • guestlist_id (string): Guest list ID under which the Attendee is listed. A null value means that this Attendee is not a guest

  • invited_by (string): Attendee who invited guest. A null value means that this Attendee is not a guest

  • delivery_method (string): Ticket delivery method used for the Attendee. Can be will_call, electronic, standard_shipping or third_party_shipping

PARAMETERS:

  • event_id (string, required): Event ID

  • status (enum, optional): Filter Attendees by status • attending: Attendee's status is either Attending or Checked In • not_attending: Attendee's status is Not Attending or Deleted • unpaid: Attendee's Order is not paid

  • changed_since (datetime, optional): Filter Attendees changed on or after the specified time

  • last_item_seen (number, optional): When passed in conjunction with changed_since, filter Attendees changed on or after the specified time and with an ID later than the value of the last_item_seen field

  • attendee_ids (array[string], optional): Filter Attendees with the specified IDs

AVAILABLE EXPANSIONS: Use ?expand=expansion_name to include additional data:

  • event: Attendee's Event

  • order: Attendee's Order

  • promotional_code: Promotional Code applied to Attendee's Order

  • assigned_number: Attendee bib number, if one exists for a race or endurance Event

  • answers: Attendee answers to custom questions

  • survey: Custom questions presented to the Attendee

  • survey_responses: Attendee's responses to survey questions

  • assigned_unit: Attendee's seating assignment details if Event has reserved seating

  • contact_list_preferences: Opt-in preferences for the email address associated with the Attendee

PAGINATION: Returns paginated response with continuation token support

AUTHENTICATION: Requires: Authorization: Bearer PERSONAL_OAUTH_TOKEN

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoFilter Attendees by status: attending (Attending or Checked In), not_attending (Not Attending or Deleted), unpaid (Order is not paid)
eventIdYesEvent ID (required)
pageSizeNoNumber of attendees to return per page (default: 50, max: 50)
continuationNoContinuation token for pagination

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does a fair job: it discloses pagination with continuation tokens, the required Bearer auth, the one-attendee-per-sold-ticket model, and that attendee data is private to the User and Order owner. It does not state rate limits or ordering guarantees, but the privacy and pagination context are meaningful additions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded correctly (purpose first) and organized under headers, but the exhaustive enumeration of 25 attendee fields and every expansion is long and reads like pasted API documentation. Much of the field detail is padding relative to the task of invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the returned-field documentation is genuinely useful, and auth, pagination, endpoint, and filtering are all covered. Completeness is slightly undercut by describing parameters the schema does not expose, but overall an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so baseline is 3, but the description adds real value by documenting parameters absent from the schema (changed_since, last_item_seen, attendee_ids, and the ?expand= mechanism) along with filter semantics. The mismatch between these documented params and the actual schema is a minor weakness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states a specific verb (List) and resource (Attendees), scopes it by Event ID, and notes the paginated nature. This clearly distinguishes it from the sibling get_attendee, which retrieves a single attendee.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the endpoint, filter parameters, and the distinction between listing and single-record retrieval, but there is no explicit statement of when to choose this tool over get_attendee or how the status/changed_since filters select it. No exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools