Skip to main content
Glama

Check Listing

check_listing
Read-only

Poll the current status and action feed for the listing tied to this call's correlation id.

IDENTITY: the correlation id is never a tool argument. It must ride the X-XP-Correlation-Id HTTP header on every MCP request, exactly like on every other tool call for this job. A missing/invalid header returns a structured error (below) instead of failing the call -- this tool is open-world (no bearer/OAuth needed); holding the correlation id (an unguessable v4 uuid) is itself the access control.

ARGS since: the cursor value returned by the previous call for this same correlation id. Omit (or pass null) on the first call to fetch the full action feed from the beginning. Must be >= 0; a negative value returns {"error": "invalid_since"}.

POLL LOOP: store cursor per correlation id in your own cache/store, send it back as since on the next call, and render only the new actions entries onto your own timeline -- the array already excludes anything at or before since and is empty when nothing changed. listing is a snapshot for cheap "current state" display only (quantity, bid count, bucket, ...); do not diff it yourself for history -- actions is the exact, ordered record (a bid placed and rescinded between two polls still yields both events).

RESULT SCHEMA (found: false -> every other field is null/absent; an unrecognized correlation id is not an error, just an empty result)::

{
  "correlation_id": "<uuid>",
  "found": true,
  "verified": true,               # identity confirmed when the listing was created
  "event_id": 406,                # last event this correlation looked at
  "listing": {                    # null until a listing exists for this id
    "swap": "d5b03i1rbqqa",       # public listing identifier (sell/checkout URLs)
    "created_at": "2026-08-12T14:00:00+00:00",
    "status_bucket": "open",      # see BUCKETS below
    "event_id": 406,
    "quantity": 2,
    "bid_count": 3,
    "top_bid_amount": 12000,      # cents, open bids, null if none
    "accepted_bid_amount": null,  # cents, set once a bid is accepted
    "sold": false,
    "last_activity_at": "2026-08-12T14:05:00+00:00"
  },
  "actions": [                    # everything after `since`, oldest first, [] if nothing new
    {"id": 91234, "event": "listing_created", "at": "2026-08-12T14:00:00+00:00"},
    {"id": 91288, "event": "bid_placed", "at": "2026-08-12T14:03:10+00:00", "amount": 12000}
  ],
  "cursor": 91301,                # send back as `since` on the next call
  "actions_truncated": true       # present+true only when 50+ new rows; call again with `cursor` to page
}

BUCKETS (listing.status_bucket) open - accepting bids, none accepted yet awaiting_tickets - a bid was accepted; seller hasn't transferred tickets yet buyer_has_tickets - tickets transferred; seller payout not yet finalized seller_payout - funds are ready to release to the seller zombies - stalled, no forward progress -- needs attention closed - terminal: cancelled, expired, or fully settled

EVENT VOCABULARY (actions[].event; only bid/sale events carry amount, in cents) listing_created, bid_placed, bid_rescinded, bid_accepted, bid_rejected, tickets_transferred, funds_claimed, listing_cancelled, listing_expired, sale_completed NOTE: no separate payout-completion signal exists -- the agent-forward payout rail is retired; sellers claim funds normally (funds_claimed).

FAILURES: this tool never raises and never returns an auth error (401). {"error": "missing_correlation_header", "message": "..."} - header missing/invalid {"error": "invalid_since"} - since < 0 {"error": "status_unavailable"} - backend down/slow/non-200

Input Schema

NameRequiredDescriptionDefault
sinceNoCursor from the previous call's `cursor` field. Omit/null on the first call to fetch the action feed from the beginning. Must be >= 0.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior2/5

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

Substantively it is rich: it discloses the required X-XP-Correlation-Id header, that a missing header yields a structured error rather than a failure, that the tool never raises 401, that found:false is a normal empty result, and the exact failure payloads. However, it labels the tool 'open-world (no bearer/OAuth needed)' while the annotations declare openWorldHint=false, which is a direct clash on a declared trait and muddies the auth/trust model the agent is supposed to rely on.

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

Conciseness3/5

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

It is front-loaded and well sectioned (IDENTITY, ARGS, POLL LOOP, RESULT SCHEMA, BUCKETS, EVENT VOCABULARY, FAILURES), so it is easy to scan. But it reproduces an entire result schema verbatim even though an output schema exists, which is bulk that the structured field could carry. The BUCKETS and EVENT VOCABULARY blocks do earn their place because they encode enumeration semantics an agent cannot infer.

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 polling tool with a cursor protocol, the description covers everything an agent needs: header-based identity, cursor round-tripping, truncation paging, bucket meanings, event vocabulary, and the full error set. Nothing material about correct invocation or result interpretation is left to inference.

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% and the schema already documents `since` as the previous call's cursor with a >=0 constraint. The description still adds real meaning beyond that: where the cursor comes from, that omitting it fetches the feed from the beginning, and that a negative value returns {"error": "invalid_since"}. This is genuine added semantics over a well-documented single parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Poll the current status and action feed for the listing tied to this call's correlation id.' The correlation-id identity model implicitly separates it from sibling tools such as get_my_listing_status or get_order_status, which presumably key off auth identity. It never names an alternative explicitly, which keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The POLL LOOP section gives clear operational context: omit `since` on the first call, store `cursor` per correlation id, send it back, and render only new `actions` rather than diffing `listing` yourself. It also explains the truncation retry path. What is missing is any statement of when to prefer this tool over sibling status tools (get_my_listing_status, get_order_status), so it stops short of explicit alternatives/exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources