Skip to main content
Glama

XP Tickets

by tickets.xp
OverviewDiscussionsAdmin

Make Offer on Listing

make_offer_on_listing
Destructive

From XP's connected resale order book. Two-phase write on the XP live offer book. Use when the user wants to make an offer on an open XP listing (e.g. 'make an offer of $50 on this'). Call with confirm=False first to preview the fee-inclusive total (no bid placed); call with confirm=True only after the user explicitly approves the previewed amount. Only confirm=True submissions return success=true. Do not use without the two-phase preview-then-confirm flow. Requires auth and write:bids scope. Do not use for browse / discovery; this is a marketplace transaction tool that places real money at risk. For standard buy-now ticket purchases without a bid, use search_events and get_ticket_listings.

Input Schema

NameRequiredDescriptionDefault
confirmNoDefaults to false, a preview of the computed total. Set true to place the offer once the user agrees.
amount_centsNoDeprecated, use amount_per_ticket_usd. Integer cents per ticket, multiple of 100.
listing_identifierYesPublic listing identifier from list_open_listings.
amount_per_ticket_usdNoWhole dollars per ticket (50 = $50.00), the same unit create_standing_bid takes. Cents are not accepted: XP rejects fractional-dollar bids. Preview returns the total.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / idempotency_key
      Removed value: -{
-  "description": "Optional client-generated UUID to prevent duplicate bids on retry.",
-  "type": [
-    "string",
-    "null"
-  ]
-}
  2. Changed6 schema fields changed
    • changedInput schema / properties / amount_cents / description
      Previous value: -"Offer amount per ticket in integer cents (5000 = $50.00). Server multiplies by quantity then converts to USDC 6-decimal raw before submitting; preview returns the fee-inclusive total."New value: +"Deprecated, use amount_per_ticket_usd. Integer cents per ticket, multiple of 100."
    • changedInput schema / properties / amount_cents / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "null"
+]
    • addedInput schema / properties / amount_per_ticket_usd
      Added value: +{
+  "description": "Whole dollars per ticket (50 = $50.00), the same unit create_standing_bid takes. Cents are not accepted: XP rejects fractional-dollar bids. Preview returns the total.",
+  "type": [
+    "number",
+    "null"
+  ]
+}
    • addedInput schema / properties / confirm / default
      Added value: +false
    • changedInput schema / properties / confirm / description
      Previous value: -"Required. True to submit the offer; False to preview the computed total without placing the offer."New value: +"Defaults to false, a preview of the computed total. Set true to place the offer once the user agrees."
    • changedInput schema / required
      Previous value: -[
-  "listing_identifier",
-  "amount_cents",
-  "confirm"
-]New value: +[
+  "listing_identifier"
+]
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: it discloses that confirm=False places no bid, that only confirm=True returns success=true, that the tool requires auth plus write:bids scope, and that real money is at risk. This is precisely the extra context annotations cannot express for a destructive write.

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?

Dense but front-loaded: source, then the two-phase rule, then guardrails, then alternatives. It is a single long paragraph and the security/scoping sentences could be trimmed, but nearly every sentence carries actionable information.

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 destructive money-moving write with an output schema present, the description covers the flow, the preview semantics, auth scope, and sibling routing. Nothing an agent needs to invoke it safely is missing, and return values are left to the output schema as expected.

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, and the description adds real meaning: the confirm flag's two-phase contract, the deprecation of amount_cents, and the unit rule that whole dollars are required and fractional-dollar bids are rejected. It does not elaborate on listing_identifier's provenance beyond pointing at list_open_listings, which the schema already covers.

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 and resource ('two-phase write on the XP live offer book' / 'make an offer on an open XP listing') and distinguishes it from browse/discovery and buy-now siblings. An agent can tell immediately this is the bid-placement tool, not a listing lookup or purchase.

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 explicit when-to-use ('user wants to make an offer on an open XP listing'), when-not ('do not use for browse / discovery'), and named alternatives ('for standard buy-now ticket purchases... use search_events and get_ticket_listings'). It also mandates the preview-then-confirm sequencing rather than leaving it to inference.

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

All XP Tickets toolsInspect
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