XP Tickets

Buy Listing at the Ask

buy_listing_now

Destructive

From XP's connected order book of resale listings. Use when an authenticated buyer wants a fan listing outright at the seller's published asking price, rather than negotiating -- 'buy it now', 'take it at the ask', 'just buy me those tickets to the game'. Only listings that carry an asking price can be bought this way; for one without an ask, use make_offer_on_listing. Two-phase: confirm=false previews the total so it can be read back to the user, confirm=true buys. A confirm here completes the sale immediately -- the money leaves the caller's XP USDC balance and the seller is committed. Pays from the caller's XP USDC balance; the x402 rail does not apply to fan listings, only to buy_tickets. Requires auth.

Input Schema

Name	Required	Description	Default
`rail`	No	How to pay. 'usdc' spends the caller's XP USDC balance.	usdc
`confirm`	No	False (default) previews. True buys at ask_per_ticket_usd, the price the preview showed.
`identifier`	Yes	Listing identifier from list_open_listings or get_open_listing.
`ask_per_ticket_usd`	No	The per-ticket price the preview showed (its ask_per_ticket_usd). Required with confirm=true: the purchase is refused if the seller has changed the ask since, so the buyer never pays a price they did not see.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

addedInput schema / properties / ask_per_ticket_usd

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The per-ticket price the preview showed (its ask_per_ticket_usd). Required with confirm=true: the purchase is refused if the seller has changed the ask since, so the buyer never pays a price they did not see."
+}

changedInput schema / properties / confirm / description

Previous value: -"False (default) previews. True buys at the seller's ask as it stands at confirm time."New value: +"False (default) previews. True buys at ask_per_ticket_usd, the price the preview showed."

First observedOct 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond annotations: confirm=true completes the sale immediately, money leaves the caller's XP USDC balance, and the seller is committed. It also discloses authentication requirements and clarifies that the x402 rail applies only to buy_tickets, not fan listings. This is consistent with destructiveHint=true and readOnlyHint=false.

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

Conciseness5/5

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

The description is front-loaded with the core action and scope, then moves through alternatives, two-phase behavior, financial consequences, payment rail, and auth. Every sentence contributes operational guidance for a high-stakes purchase tool.

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?

Given the destructive nature of the operation, the existing output schema, and rich annotations, the description covers the key missing context: preview vs. purchase semantics, authentication, payment source, price-change protection, and the alternative for listings without an ask. Nothing critical for correct invocation appears to be 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?

Schema coverage is 100%, so the baseline is 3, but the description adds workflow meaning: confirm=false previews the total for read-back, confirm=true executes the purchase, and ask_per_ticket_usd must match the previewed price or the purchase is refused. This goes beyond the schema's field-level descriptions by explaining the safety contract between preview and purchase.

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 description states a specific verb and resource ('buy a fan listing outright at the seller's published asking price') and clearly distinguishes this from negotiation and from make_offer_on_listing. An agent can identify the exact purchase action without opening the schema.

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?

It explicitly says when to use this tool: an authenticated buyer wants to purchase at the ask rather than negotiate. It also states when not to use it by routing listings without an asking price to make_offer_on_listing, and explains the two-phase preview/buy workflow.

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?