Skip to main content
Glama

list_ticket_classes

Retrieve all ticket classes for an event, including pricing, capacity, sales dates, and status. Filter results by point of sale to manage event ticketing.

Instructions

List all ticket classes for an event.

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

Returns paginated list of ticket classes with complete details including name, description, cost, fee, capacity, quantity_sold, sales dates, hidden status, and delivery methods.

TICKET CLASS TYPES:

  • Free: No cost, no payout info required

  • Paid: Has cost in event's currency

  • Donation: Buyer enters amount at checkout

RESPONSE INCLUDES:

  • ticket_classes (array): List of Ticket Class objects

  • pagination: Pagination information

TICKET CLASS FIELDS RETURNED: PUBLIC:

  • name, description, sorting, cost, fee

  • donation, free, minimum_quantity, maximum_quantity

  • has_pdf_ticket, delivery_methods, on_sale_status, image_id

PRIVATE (Organization Members):

  • capacity, quantity_sold, hidden

  • sales_start, sales_end, sales_end_relative, sales_start_after

  • include_fee, split_fee, hide_description, hide_sale_dates

  • auto_hide, auto_hide_before, auto_hide_after

  • order_confirmation_message, secondary_assignment_enabled

FILTERING:

  • pos (optional): Filter by point of sale

    • online: Online sales

    • at_the_door: At-the-door sales

    • lock_box: Lock box sales

AUTHENTICATION: Requires: Authorization: Bearer PERSONAL_OAUTH_TOKEN

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
posNoFilter by point of sale (optional): online, at_the_door, lock_box
event_idYesEvent ID (required)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.6

TDQS

A3.8/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 well: it states the operation is a paginated GET, discloses the required Bearer token auth, and importantly notes that certain fields (capacity, quantity_sold, hidden, sales dates) are only visible to Organization Members. It omits rate limits and error behavior, but covers the key behavioral traits.

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, but the exhaustive enumeration of every returned field across PUBLIC and PRIVATE tiers is bloated and largely redundant detail that outweighs its usefulness.

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?

There is no output schema, so documenting the response shape and field tiers is genuinely necessary and largely done. Auth, filtering, and response structure are all covered, making the definition adequate to call 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 3 is the baseline, but the description adds value by explaining the meaning of each pos value (online/at_the_door/lock_box sales) and confirming event_id is required.

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 sentence states a specific verb and resource with scope: 'List all ticket classes for an event.' This clearly distinguishes it from the sibling retrieval tool get_ticket_class (singular) and the mutation siblings create/update_ticket_class.

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

Usage Guidelines2/5

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

The description never states when to use this tool versus alternatives such as get_ticket_class, nor does it describe prerequisites or contexts of use. The only conditional guidance is on the pos filter values, not on selecting the tool itself.

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