Ticker: Live Event Ticket Market

Get Ticket Sales

get_sales

Read-only

Returns completed resale sales and primary seats taken, for one event, performer or venue or the account's watchlist, and as rankings across the whole market. Use it for recent sales records, for the events or sections with the most completed sales or primary seats taken over the last 1 hour to 7 days, or for one event's sales per section by date. A completed sale is one recorded resale sale; primary seats taken counts the seats that went off sale on the primary market, a separate measure. Fields the plan does not include are named in withheld. get_event_analytics with view sales reads one event's completed sales beside each market's Sales and Interest.

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_sales"
  }
}

Input Schema

Name	Required	Description	Default
`by`	No	view top: rank events (default) or sections of events.
`row`	No	view list: only sales in this row, exact, any case.
`days`	No	view sections: how many dates (UTC), today last. Default 7.
`page`	No	views list and primary: the page, from 1.
`view`	No	list (default): completed resale sales, newest first, in one scope; section, row and price are each listing's last listed state before the sale. top: events, or sections with by section, ranked by completed sales (market secondary, the default) or primary seats taken (market primary) over window, across the whole market or in a scope, at most 50 rows with total and truncated. primary: sections ranked by primary seats taken in one scope. sections: one event's completed sales per section and date.	list
`limit`	No	views list and primary: rows per page, default 50, at most 100.
`scope`	No	watchlist: only the events the account watches (its Watchlist and its team's shared stars, archived ones left out).
`market`	No	view top: secondary (completed resale sales, the default) or primary (primary seats taken). view sections: one market code; default every market the plan reads, each its own entry.
`window`	No	view top: how far back, the last 1h (default), 6h, 24h or 7d.
`date_to`	No	views list and primary: before this instant, or through this whole day. With no range the list reads the last 24 hours unless it names an event, and primary the last 24 hours.
`section`	No	view list: only sales whose section contains this text, any case. view primary: only sections whose code contains it.
`event_id`	No	One event. Ticker event id, `ev` plus ten characters, as returned by every tool here. Required for view sections.
`venue_id`	No	One venue's events. Ticker venue id, `vn` plus ten characters.
`date_from`	No	views list and primary: at or after this day (YYYY-MM-DD, from 00:00 UTC) or instant (ISO 8601).
`performer_id`	No	One performer's events. Ticker performer id, `pf` plus ten characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / view / description

Previous value: -"list (default): completed sales, newest first. top: the ranking. primary: primary seats taken per section. sections: one event's completed sales per section and date."New value: +"list (default): completed resale sales, newest first, in one scope; section, row and price are each listing's last listed state before the sale. top: events, or sections with by section, ranked by completed sales (market secondary, the default) or primary seats taken (market primary) over window, across the whole market or in a scope, at most 50 rows with total and truncated. primary: sections ranked by primary seats taken in one scope. sections: one event's completed sales per section and date."

Changed2 schema fields changedOct 29, 2026

changedInput schema / properties / market / description

Previous value: -"view top: secondary (completed resale sales, the default) or primary (box office seats taken). view sections: one market code; default every market the plan reads, each its own entry."New value: +"view top: secondary (completed resale sales, the default) or primary (primary seats taken). view sections: one market code; default every market the plan reads, each its own entry."

changedInput schema / properties / view / description

Previous value: -"list (default): completed sales, newest first. top: the ranking. primary: box office seats taken per section. sections: one event's completed sales per section and date."New value: +"list (default): completed sales, newest first. top: the ranking. primary: primary seats taken per section. sections: one event's completed sales per section and date."

AddedOct 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/non-destructive/closed-world, so the bar is lower, and the description still adds real value: it defines what a completed sale is versus primary seats taken, and notes that plan-excluded fields are surfaced in a `withheld` field. It does not cover rate limits or ordering guarantees beyond what the schema states.

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?

Front-loaded with the return content before the use cases and metric definitions, and every sentence carries information. It is dense but long, and the metric-definition sentence could be tightened without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, four-view tool with no output schema, the description covers the metrics, scopes, time windows, truncation ('at most 50 rows with total and truncated'), and plan-based field withholding – enough for correct invocation. Remaining gaps (pagination defaults, per-view required params like event_id for sections) are carried by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with six enums, so the schema already documents view/by/market/window semantics in detail. The description mostly restates those dims ('over the last 1 hour to 7 days', 'per section by date') rather than adding new parameter meaning, so baseline 3 applies.

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 specific metrics (completed resale sales, primary seats taken) and the exact scopes it can be run against (one event, performer, venue, or the account watchlist) plus whole-market rankings. It explicitly contrasts with get_event_analytics view sales, so the agent can distinguish it from a sibling without opening a schema.

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?

Gives concrete use cases: recent sales records, top events/sections by completed sales or primary seats over 1h–7d, and one event's per-section sales by date. It also points to get_event_analytics for a single event's sales alongside Sales and Interest, but stops short of an explicit 'use that instead when...' exclusion statement.

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

All Ticker: Live Event Ticket Market 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?