XP Tickets

Rest a Standing Offer

create_standing_bid

Destructive

Creates a STANDING OFFER -- that is the term to use when speaking to the user; the tool keeps standing_bid only because the stored records do. Use when the user wants to make an offer at their own price across one or more events and sections and wait for it to fill, rather than paying an asking price now -- e.g. 'offer 80 a seat for any of these nights', 'let me know if something in 104 comes up at my number'. The offer rests on XP's live offer book and fills itself when a matching fan listing appears, so it needs no listing to exist yet. Worth knowing before resting one: when a matching listing is already open, an offer on it (make_offer_on_listing) gets an answer the user will see -- accept, reject or counter -- while a standing offer waits for supply that may never arrive. Check what is open first (list_open_listings, or get_market_read for one event). Both are valid; resting a price where nobody is selling yet is what this tool is for. Say which you did. Two-phase: call with confirm=false to preview the total commitment, then confirm=true once the user agrees. Price is whole dollars per ticket -- XP refuses cents so every fill passes per-ticket validation. Fills take whole lots and cannot strand a remainder. Requires auth.

Input Schema

TableJSON Schema

Name	Required	Description
`confirm`	No	False (default) previews without committing. True rests the offer.
`quantity`	Yes	How many tickets the offer is good for.
`sections`	Yes	Section names the offer covers, e.g. 104 and 105. Exact names.
`event_ids`	Yes	Event ids this offer may fill on, from search_market or search_events.
`expires_at`	No	Optional ISO-8601 UTC expiry. Omit for no expiry.
`amount_per_ticket_usd`	Yes	Whole dollars per ticket. Cents are not accepted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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 only declare readOnlyHint=false, destructiveHint=true, openWorldHint=false; the description goes well beyond by disclosing the two-phase confirm preview flow, that fills take whole lots with no stranded remainder, that whole-dollar pricing is enforced, that auth is required, and that the offer rests on a live offer book that self-fills. This is exactly the extra behavioral context the annotations cannot convey.

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?

Purpose and the sibling contrast are front-loaded, and most sentences carry decision-relevant content. It is long and leans on parenthetical asides and meta-instructions ('that is the term to use when speaking to the user'), which slightly dilute density, but nothing is truly wasted.

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?

With an output schema present, full schema description coverage, and annotations covering the safety profile, the description supplies everything else an agent needs: auth requirement, two-phase calling convention, pricing granularity, fill behavior, and alternative-tool routing.

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 real meaning: the two-phase confirm=false/true lifecycle, the whole-dollar constraint rationale ('XP refuses cents so every fill passes per-ticket validation'), and the whole-lot fill semantics that qualify quantity. Some of this overlaps the schema ('Cents are not accepted'), keeping it below 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?

The description states a specific verb and resource ('Creates a STANDING OFFER'), defines the term explicitly, and distinguishes it from the closely related make_offer_on_listing and buy_listing_now by explaining the fill/wait mechanic. An agent can identify this tool without inspecting any 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 gives concrete when-to-use triggers with example utterances ('offer 80 a seat for any of these nights'), names the alternatives (make_offer_on_listing, list_open_listings, get_market_read), and explicitly clarifies that both paths are valid to forestall misuse. Exclusions and pre-checks are all present.

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?