XP Tickets

Get Ticket Listings

get_ticket_listings

Read-only

Use when the user wants to see ticket options and fee-inclusive prices for a specific XP event after search_events (e.g. 'cheap seats', 'parking for the game'). Pulls the live offer book of resale inventory. Do not use before an event has been resolved — call search_events or get_event_details first. Prices are dollars: each ticket row carries per_ticket_usd. error_code NO_INVENTORY means the event is real but has nothing listed right now: do not retry, give the user the event page or another date. NO_MATCHING_TICKETS means tickets exist but none fit the filters: widen or drop them. EVENT_NOT_FOUND means the event_id is wrong: resolve it again with search_events.

Input Schema

Name	Required	Description
`tags`	No	Alias for section_tags.
`is_ga`	No	If true, filter for general admission only.
`limit`	No	Maximum ticket listings to return.
`offset`	No	Pagination offset.
`event_id`	No	Event identifier from search_events or get_event_details. If omitted, the assistant should search/select an event first.
`order_by`	No	Price sort order.
`quantity`	No	Number of tickets requested.
`sections`	No	Alias for section_ids.
`api_limit`	No	Backend limit (advanced; usually omit).
`section_ids`	No	Section IDs filter (list, comma-separated string, or numeric IDs; supports simple ranges like '100-110').
`parking_only`	No	If true, return only parking tickets.
`section_tags`	No	Section tags filter (e.g. 'Floor', '1xx').
`max_price_usd`	No	Maximum all-in price per ticket in dollars.
`min_price_usd`	No	Minimum all-in price per ticket in dollars.
`max_cache_level`	No	Backend cache level override (advanced; usually omit).
`max_price_cents`	No	Deprecated, use max_price_usd. Integer cents.
`min_price_cents`	No	Deprecated, use min_price_usd. Integer cents.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 14, 2026

changedInput schema / properties / max_price_cents / description

Previous value: -"Maximum ticket price. Integer cents (20000 = $200.00)."New value: +"Deprecated, use max_price_usd. Integer cents."

addedInput schema / properties / max_price_usd

Added value: +{
+  "description": "Maximum all-in price per ticket in dollars.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

changedInput schema / properties / min_price_cents / description

Previous value: -"Minimum ticket price. Integer cents (5000 = $50.00)."New value: +"Deprecated, use min_price_usd. Integer cents."

addedInput schema / properties / min_price_usd

Added value: +{
+  "description": "Minimum all-in price per ticket in dollars.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

First observedOct 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the read-only/non-destructive profile, and the description adds substantial non-obvious behavior: prices are in dollars with a per-row `per_ticket_usd` field, and three named error codes are decoded into actions (NO_INVENTORY = do not retry, NO_MATCHING_TICKETS = widen filters, EVENT_NOT_FOUND = re-resolve the event). This is exactly the retry/routing context an agent cannot infer from structured fields.

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

Conciseness4/5

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

Front-loaded with the trigger condition, then behavior, then error semantics — a sensible priority order with no filler. It is on the long side and restates the dollar/pricing point that the schema also carries, which keeps it just below a 5.

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

Completeness5/5

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

For a 17-parameter read tool with full schema coverage, an output schema, and annotations, the description supplies the remaining pieces an agent needs: prerequisite ordering, price units, and error-driven recovery paths. Nothing essential to correct invocation is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds interpretive value: it clarifies that price filters and results are dollar-denominated all-in prices and that 'none fit the filters' should be handled by widening or dropping them. It does not cover other notable params (quantity default, sections vs section_ids aliasing, deprecated cents fields), so it falls short of a 5.

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?

States a specific verb+resource ('see ticket options and fee-inclusive prices'), names the prerequisite tool (`search_events`), and characterizes the data source as 'the live offer book of resale inventory'. This clearly separates it from `search_market`, `get_seat_map`, and `get_event_details` in the sibling list.

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

Usage Guidelines5/5

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

Gives an explicit trigger ('after search_events', example user phrasings 'cheap seats', 'parking for the game') and an explicit exclusion ('Do not use before an event has been resolved — call search_events or get_event_details first'). It even routes follow-up decisions by error code, which is more than most definitions offer.

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

All XP Tickets tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?