Skip to main content
Glama
prmichaelsen

eventbrite-mcp

by prmichaelsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_attendee

Retrieve detailed Eventbrite attendee information by event ID and attendee ID, including ticket class, profile, barcodes, check-in status, and refund or cancellation state.

Instructions

Retrieve an Attendee by Attendee ID.

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

The Attendee object represents ticket holder details for an Event. One Attendee per sold ticket. If Event only collects Order owner info (default), all Attendees have same info except barcodes and Ticket Class ID.

Attendee objects are private - only available to User and Order owner.

ATTENDEE FIELDS:

  • created (datetime): When order placed/attendee created

  • changed (datetime): Last change to attendee

  • ticket_class_id (string): Ticket Class used when registering

  • variant_id (string): Variant of Ticket Class

  • ticket_class_name (string): Name of Ticket Class

  • quantity (integer): Always 1

  • costs (object): Ticket cost breakdown

  • profile (object): Attendee basic profile

  • addresses (object): Attendee addresses

  • questions (array, optional): Custom questions

  • answers (array, optional): Answers to custom questions

  • barcodes (array): Entry bar codes

  • team (object, optional): Team information

  • affiliate (string, optional): Affiliate code

  • checked_in (boolean): true = Checked in

  • cancelled (boolean): true = Cancelled

  • refunded (boolean): true = Receives refund

  • status (string): Attendee status

  • event_id (string): Event ID

  • order_id (string): Order ID

  • guestlist_id (string): Guest list ID (null = not a guest)

  • invited_by (string): Who invited guest (null = not a guest)

  • delivery_method (string): will_call, electronic, standard_shipping, third_party_shipping

ATTENDEE COSTS:

  • base_price (currency): Price excluding fees/tax (don't expose if include_fee used)

  • eventbrite_fee (currency): Fee (don't expose if include_fee used)

  • tax (currency): Tax amount

  • payment_fee (currency): Payment processing fee

  • gross (currency): Total cost (base_price + eventbrite_fee + payment_fee + tax)

ATTENDEE PROFILE:

  • name (string): Full name (use instead of first_name/last_name)

  • email (string): Email address

  • first_name, last_name (string): Use name instead

  • prefix, suffix (string, optional): Title/honorific

  • age (integer, optional): Age

  • job_title, company, website, blog (string, optional)

  • gender (string, optional): male or female

  • birth_date (date, optional): Birth date

  • cell_phone (string, optional): Mobile number

ATTENDEE ADDRESSES:

  • home, ship, work (address, optional): Home, shipping, work addresses

ATTENDEE BARCODES:

  • barcode (string): Barcode contents (null if: printable tickets off, delivery method mismatch, not electronic delivery)

  • status (string): unused, used, or refunded

  • created, changed (datetime): Creation and last change times

  • is_printed (boolean): true = Ticket printed

AVAILABLE EXPANSIONS:

  • event: Attendee's Event

  • order: Attendee's Order

  • promotional_code: Promo code applied to Order

  • assigned_number: Bib number for race/endurance events

  • answers: Answers to custom questions

  • survey: Custom questions presented

  • survey_responses: Responses to survey questions

  • assigned_unit: Seating assignment details (reserved seating events)

  • contact_list_preferences: Email opt-in preferences

AUTHENTICATION: Requires: Authorization: Bearer PERSONAL_OAUTH_TOKEN

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesEvent ID (required)
attendee_idYesAttendee ID (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A3.6/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 so well: it discloses the private-visibility constraint, the OAuth bearer requirement, the one-attendee-per-ticket semantics, and non-obvious value conditions (barcodes null when printable tickets are off or delivery method mismatches). It stops short of documenting error behavior or rate limits.

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?

The first two sentences are well front-loaded and state the core operation. The remainder is a very long field/expansion reference dump; it substitutes for a missing output schema, but it is not tightly scoped for selection-time reading and buries the key constraints (privacy, auth) in the middle of the text.

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?

Because no output schema exists, the extensive field, cost, profile, address, and barcode documentation meaningfully fills that gap, and auth is specified. One gap: 'AVAILABLE EXPANSIONS' are listed but the input schema exposes no expand parameter, leaving the agent unsure how to request them.

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

Parameters3/5

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

Both parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description adds the endpoint path structure showing how event_id and attendee_id nest, but no extra syntax or format guidance for the parameters themselves.

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

Purpose4/5

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

States a specific verb and resource ('Retrieve an Attendee by Attendee ID') and even pins the exact endpoint, so the operation is unambiguous. The 'by Attendee ID' phrasing implicitly separates it from the bulk list_attendees sibling, though no sibling is named explicitly, which keeps it short of a 5.

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 only implied: the agent must already know an attendee_id to call this, and the privacy note ('only available to User and Order owner') gives a precondition. There is no explicit when-to-use vs. list_attendees guidance and no exclusions, so this is minimum-viable rather than clear routing guidance.

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