XP Tickets

List Tickets for Sale

create_listing

Destructive

Use when the user wants to sell tickets they hold on the XP marketplace -- 'sell my two seats for Friday', 'list section 104 row C', 'put my tickets up'. Creates the listing that buyers (other fans on XP) then make an offer on; the seller answers those with accept_offer and reject_offer. Tickets are not transferred now -- transfer happens after an offer is accepted. Ask the seller whether the seats are accessible (ADA), obstructed view or standing room only: all three are required, never assumed. Two-phase: confirm=false previews so the section, row, seats and those three can be read back to the user, confirm=true creates it. A new listing is REVIEWED before it goes live. The result carries listing_state -- live, in_review or not_accepted -- and only live means buyers can see it. Do not tell the user their tickets are for sale unless it says live. Requires auth.

Input Schema

Name	Required	Description
`ga`	No	True for general admission with no seat numbers.
`row`	No	Row, e.g. C. Omit for general admission.
`is_ada`	Yes	Required. True if accessible (ADA) seating. Ask the seller; never assume.
`is_sro`	Yes	Required. True if standing room only. Ask the seller; never assume.
`confirm`	No	False (default) previews. True creates the listing.
`section`	No	Section name exactly as the venue prints it, e.g. 104.
`event_id`	Yes	Event identifier from search_market or search_events.
`quantity`	Yes	How many tickets are being listed together.
`last_seat`	No	Last seat number, if seated.
`first_seat`	No	First seat number, if seated.
`ask_per_ticket_usd`	No	Optional asking price per ticket in dollars. Omit to invite offers with no anchor.
`is_obstructed_view`	Yes	Required. True if the view is obstructed. Ask the seller; never assume.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 14, 2026

removedInput schema / properties / is_ada / default
```
Removed value: -false
```

changedInput schema / properties / is_ada / description

Previous value: -"True for accessible seating."New value: +"Required. True if accessible (ADA) seating. Ask the seller; never assume."

removedInput schema / properties / is_obstructed_view / default
```
Removed value: -false
```

changedInput schema / properties / is_obstructed_view / description

Previous value: -"True if the view is obstructed."New value: +"Required. True if the view is obstructed. Ask the seller; never assume."

removedInput schema / properties / is_sro / default
```
Removed value: -false
```

changedInput schema / properties / is_sro / description

Previous value: -"True for standing room only."New value: +"Required. True if standing room only. Ask the seller; never assume."

changedInput schema / required

Previous value: -[
-  "event_id",
-  "quantity"
-]New value: +[
+  "event_id",
+  "quantity",
+  "is_ada",
+  "is_obstructed_view",
+  "is_sro"
+]

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 flag a non-readonly, destructive write; the description adds the traits annotations cannot express: no tickets move at listing time (transfer follows an accepted offer), new listings are reviewed, and the result's listing_state may be live/in_review/not_accepted with an explicit warning never to claim the seats are for sale unless state is live. It also notes the auth requirement.

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-loads the trigger phrase, then layers call mechanics, review behavior, and result interpretation in a logical order with no filler sentences. It is dense and long-ish for a single tool, but nearly every clause carries operational information the agent needs.

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?

Despite 12 parameters and a mutation with a review gate, the description covers the workflow prerequisites, the two-phase confirmation, the auth requirement, and the interpretation of listing_state — the risky ambiguity for this tool. Output schema handling of return shape is appropriately left to the schema.

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 description coverage is 100%, so the baseline is 3; the description earns an extra point by elevating is_ada, is_obstructed_view, and is_sro into a required seller-interview workflow ("never assumed") and by explaining what confirm=false previews actually surfaces (section, row, seats, the three flags). Pricing and seating parameters are left to the schema.

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?

"Use when the user wants to sell tickets they hold on the XP marketplace" states a specific verb, resource, and audience, then reinforces it with three natural-language triggers. It explicitly separates the tool's role from accept_offer/reject_offer (seller responding to offers) and from transfer, so an agent can place it precisely among siblings.

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 concrete when-to-use phrasing ("sell my two seats for Friday") and an implicit when-not: this is listing creation, not offer handling or ticket transfer. It also prescribes a prerequisite conversation (ask about ADA/obstructed/SRO) and a two-phase call pattern before creation.

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?