Skip to main content
Glama
prmichaelsen

eventbrite-mcp

by prmichaelsen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_ticket_class

Fetch a ticket class by event and ticket class ID to view ticket type details, pricing, availability, and sale status.

Instructions

Retrieve a Ticket Class by Ticket Class ID.

ENDPOINT: GET /events/{event_id}/ticket_classes/{ticket_class_id}/

The Ticket Class object represents a possible ticket class (i.e. ticket type) for an Event. Multiple different types of tickets for an Event can be purchased in one transaction.

TICKET CLASS TYPES:

  • Free: No cost or currency. Event with only free tickets doesn't require payout info

  • Paid: Associated cost in Event's currency

  • Donation: Order owner enters amount to donate at checkout (no fixed cost)

TICKET CLASS OBJECT - PUBLIC FIELDS:

  • name (string): Ticket Class name

  • description (string, optional): Ticket Class description

  • sorting (integer): Order in purchase flow on event listing page

  • cost (currency): Display cost on Ticket Listing page (paid only)

  • fee (currency): Display fee on Ticket Listing page (paid only)

  • donation (boolean): true = Ticket Class is a Donation

  • free (boolean): true = Ticket Class is Free

  • minimum_quantity (integer): Minimum tickets per Order

  • maximum_quantity (integer): Maximum tickets per Order

  • has_pdf_ticket (boolean): true = Attendee receives PDF confirmation

  • delivery_methods (list): electronic, will_call, standard_shipping, third_party_shipping

  • on_sale_status (string): AVAILABLE or SOLD_OUT

  • image_id (string): Image ID for ticket class (used for add-ons)

TICKET CLASS OBJECT - PRIVATE FIELDS (Organization Members only):

  • capacity (integer): Number available for sale

  • quantity_sold (integer): Number previously sold (excludes real-time purchases)

  • hidden (boolean): true = Hidden from public

  • sales_start (datetime): When sales begin

  • sales_end (datetime): When sales end

  • sales_end_relative (object): Relative values for sales_end (series parent tickets only)

  • sales_start_after (string): Ticket Class ID that triggers sales start when it sells out

  • include_fee (boolean): true = Fee included in displayed price (cannot use with split_fee)

  • split_fee (boolean): true = Fee not included, actual_cost and actual_fee shown separately

  • hide_description (boolean): true = Description hidden on Ticket Listing page

  • hide_sale_dates (boolean): true = Sale dates hidden on event page

  • auto_hide (boolean): true = Hidden when not for sale

  • auto_hide_before (datetime): Override auto-hide disable time (default: sales_start)

  • auto_hide_after (datetime): Override auto-hide enable time (default: sales_end)

  • order_confirmation_message (string): Message shown when Order completed

  • secondary_assignment_enabled (boolean): true = Secondary barcode assignment enabled (e.g., RFID)

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

  • event: Event for the Ticket Class

  • image: Image for the Ticket Class

POSSIBLE ERRORS (400):

  • AUTO_HIDE_NOT_SET: Must select an auto hide setting

AUTHENTICATION: Requires: Authorization: Bearer PERSONAL_OAUTH_TOKEN

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
event_idYesEvent ID (required)
ticket_class_idYesTicket Class ID (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A3.7/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden, and it does substantial work: it states the auth requirement (Bearer PERSONAL_OAUTH_TOKEN), splits fields into public vs organization-member-only visibility, and lists a 400 error. It omits rate limits and confirms nothing about side effects, but the auth and field-visibility disclosures are solid for a read tool.

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 purpose is correctly front-loaded and the description is organized under clear headers (endpoint, types, fields, expansions, errors, auth). However the two long field inventories make it very verbose for a simple by-ID lookup; much of that content is reference data rather than essential selection guidance.

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?

With no output schema, documenting the returned Ticket Class fields is genuinely necessary and the description does so thoroughly, plus auth, expansions, and an error case. The main gap is that the listed AUTO_HIDE_NOT_SET 400 error looks like a mutation error and is likely irrelevant to a GET, slightly muddying completeness.

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 100% and the two path parameters are self-documenting, so baseline would be 3. The description goes further by documenting an expansion query parameter (?expand=event|image) that is absent from the schema entirely, adding real meaning beyond the structured fields.

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?

The opening sentence gives a specific verb (Retrieve) and resource (Ticket Class) scoped by ID, so an agent knows this is a single-object lookup rather than the list_ticket_classes variant. It does not explicitly name the sibling alternatives, but the by-ID scoping is enough to distinguish it.

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?

There is no explicit when-to-use vs alternatives (e.g. list_ticket_classes), but the description does route optional usage through the 'AVAILABLE EXPANSIONS: Use ?expand=...' section, which tells the agent how to enrich the response. That is implicit guidance rather than a stated selection rule.

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