XP Tickets

Get My Offers

get_my_offers

Read-only

The offers the caller has placed on XP listings, as open or completed -- 'show my bids', 'did any of my offers settle?'. Rejected, lapsed and refunded offers are left out. Paged: 25 by default, up to 200 with limit, and offset to continue; pagination.total counts only the offers shown, and has_more marks further pages. Open offers resting across events are in list_my_open_offers. Requires sign-in.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_my_offers"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	How many bids to return, 1-200. Defaults to 25.
`offset`	No	Skip this many. Use with limit to page.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare a safe read, but the description goes well beyond them: it discloses that rejected/lapsed/refunded offers are silently omitted, that results are paged, and that pagination.total counts only the offers actually shown rather than the full set — a real trap for an agent computing totals. Sign-in requirement is stated too.

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?

Three sentences, front-loaded with scope, then exclusions, then pagination caveats. Every clause carries information an agent needs; nothing is padding.

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?

An output schema exists, so return values needn't be enumerated, and the description still flags the one output detail agents routinely misread (total vs. shown). With two optional params fully covered by the schema and safety carried by annotations, nothing material 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?

Schema coverage is 100%, so the limit/offset mechanics are already documented and the description's restatement of 25/200 adds little. It does earn credit for clarifying has_more and the non-obvious semantics of pagination.total in the result, which the schema alone does not convey.

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?

Names a specific resource scoped to the caller ("offers the caller has placed on XP listings") plus the included states (open or completed) and the excluded ones (rejected, lapsed, refunded). The example phrasings ("show my bids", "did any of my offers settle?") pin down intent unambiguously and distinguish it from the open-offers sibling.

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?

Explicitly routes the agent: use this for the caller's offers in any state, but open offers resting across events belong to list_my_open_offers. It also states exclusions and the sign-in prerequisite, so both the when and the when-not are covered.

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?