Skip to main content
Glama

Ticker: Live Event Ticket Market

Get Event Analytics

get_event_analytics
Read-only

Returns one event's market numbers, whole-event: prices, inventory, demand, recent changes, prediction markets, sale windows and weather. Use it for one event's numbers now; for a section or general admission use get_event_sections. Pass range for how they read on each past date, and view sales whenever the question is about this event's sales: completed resale sales, primary seats taken per section, each market's Sales and Interest. For a chart over time use get_event_chart; to compare many events use screen_events; for the news behind a move use research_event. Current values are dated by their source timestamps; changes_close_date names the UTC close used by changes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "event_id": "<event_id>"
    },
    "name": "get_event_analytics"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowNoOnly sales in this row, exact, any case.
viewNosales: the event's completed resale sales, newest first (time, section, row, tickets and the listing's last listed price before the sale), primary seats taken per section, and each market's Sales (tickets over 24 hours, 7 and 30 days) and Interest side by side, never summed. Takes no range: the newest sales are the latest.
limitNoNewest completed sales returned, at most 50. Default 20.
rangeNoReads the event's numbers as they stood on each past date, one row per date, to test a signal against what came next: 7d, 14d, 28d, 90d (the default) or all (about a year). A date listed in days_missing has no row; never fill it.
columnsNoevent_analytics columns to return (bare names). Now: omit for the full row; `presales` and `onsale` name the sale windows. With range: omit for the headline signal set.
sectionNoOnly sales whose section contains this text, any case.
currencyNousd or venue. venue answers an event in a Canadian or UK venue with every price in the venue's currency (CAD or GBP) at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for USD. A view with no price ignores it. An answer in the venue's currency says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD or GBP. A US event is always USD. mlb_* prices keep mlb_currency.
event_idYesThe event to look up. Ticker event id, `ev` plus ten characters, as returned by every tool here. A marketplace event link also resolves, as does a marketplace id with its source prefix (`vs:`, `sh:`, `tm:`, `sg:`, `gt:`, `ax:`, `tp:`) or bare until 2027-09-13. An id two events share is refused with both their ids.
by_section_daysNoAlso return sections_by_day: the event's completed resale sales per section, one count for each date (UTC) over this many dates, today last. Where the account reads SH, also SH's best selling sections by date.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / currency / description
      Previous value: -"usd or venue. venue answers an event in a Canadian venue with every price in CAD at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for USD. A view with no price ignores it. An answer about an event in a Canadian venue says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD. A US event is always USD. mlb_* prices keep mlb_currency."New value: +"usd or venue. venue answers an event in a Canadian or UK venue with every price in the venue's currency (CAD or GBP) at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for USD. A view with no price ignores it. An answer in the venue's currency says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD or GBP. A US event is always USD. mlb_* prices keep mlb_currency."
  2. Changed1 schema field changed
    • changedInput schema / properties / currency / description
      Previous value: -"usd or venue. venue answers an event in a Canadian venue with every price in CAD at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for the account's saved choice (USD unless the person chose venue in Settings). An answer about an event in a Canadian venue says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD. A US event is always USD. mlb_* prices keep mlb_currency."New value: +"usd or venue. venue answers an event in a Canadian venue with every price in CAD at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for USD. A view with no price ignores it. An answer about an event in a Canadian venue says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD. A US event is always USD. mlb_* prices keep mlb_currency."
  3. Changed2 schema fields changed
    • changedInput schema / properties / range / description
      Previous value: -"Lookback window over as_of_date: 7d | 14d | 28d | 90d | all (all is bounded to ~1 year). Default 90d."New value: +"Reads the event's numbers as they stood on each past date, one row per date, to test a signal against what came next: 7d, 14d, 28d, 90d (the default) or all (about a year). A date listed in days_missing has no row; never fill it."
    • changedInput schema / properties / view / description
      Previous value: -"sales: the event's completed sales, seats taken and each market's sales and interest. Takes no range: the newest sales are always the latest."New value: +"sales: the event's completed resale sales, newest first (time, section, row, tickets and the listing's last listed price before the sale), primary seats taken per section, and each market's Sales (tickets over 24 hours, 7 and 30 days) and Interest side by side, never summed. Takes no range: the newest sales are the latest."
  4. Changed1 schema field changed
    • addedInput schema / properties / currency
      Added value: +{
      +  "description": "usd or venue. venue answers an event in a Canadian venue with every price in CAD at the event's Bank of Canada rate; one rate converts every market, so the cheapest market and any order stay the same. Omit for the account's saved choice (USD unless the person chose venue in Settings). An answer about an event in a Canadian venue says currency, venue_currency, fx_rate (USD per one unit of venue_currency) and fx_rate_date; quote the currency with every price and the rate date when it is CAD. A US event is always USD. mlb_* prices keep mlb_currency.",
      +  "enum": [
      +    "usd",
      +    "venue"
      +  ],
      +  "type": "string"
      +}
  5. Changed3 schema fields changed
    • addedInput schema / properties / by_section_days
      Added value: +{
      +  "description": "Also return sections_by_day: the event's completed resale sales per section, one count for each date (UTC) over this many dates, today last. Where the account reads SH, also SH's best selling sections by date.",
      +  "enum": [
      +    "7",
      +    "14",
      +    "28"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / event_id / description
      Previous value: -"The event to look up. Ticker event id, `ev` plus ten characters, as returned by every tool here. A marketplace id also resolves when it carries its source prefix (`vs:`, `tm:`, `tp:`), and a bare marketplace id resolves until 2027-09-13."New value: +"The event to look up. Ticker event id, `ev` plus ten characters, as returned by every tool here. A marketplace event link also resolves, as does a marketplace id with its source prefix (`vs:`, `sh:`, `tm:`, `sg:`, `gt:`, `ax:`, `tp:`) or bare until 2027-09-13. An id two events share is refused with both their ids."
    • changedInput schema / properties / view / description
      Previous value: -"sales: the event's completed sales, seats taken and each market's sales and interest."New value: +"sales: the event's completed sales, seats taken and each market's sales and interest. Takes no range: the newest sales are always the latest."
  6. Changed4 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Newest completed sales returned, at most 50. Default 20.",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / row
      Added value: +{
      +  "description": "Only sales in this row, exact, any case.",
      +  "maxLength": 16,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / section
      Added value: +{
      +  "description": "Only sales whose section contains this text, any case.",
      +  "maxLength": 64,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "const": "sales",
      +  "description": "sales: the event's completed sales, seats taken and each market's sales and interest.",
      +  "type": "string"
      +}
  7. Changed2 schema fields changed
    • changedInput schema / properties / columns / description
      Previous value: -"Specific event_analytics columns to return (bare names, no namespace). Omit for the full row; this is the drill-down tool, so full is the default."New value: +"event_analytics columns to return (bare names). Now: omit for the full row; `presales` and `onsale` name the sale windows. With range: omit for the headline signal set."
    • addedInput schema / properties / range
      Added value: +{
      +  "description": "Lookback window over as_of_date: 7d | 14d | 28d | 90d | all (all is bounded to ~1 year). Default 90d.",
      +  "enum": [
      +    "7d",
      +    "14d",
      +    "28d",
      +    "90d",
      +    "all"
      +  ],
      +  "type": "string"
      +}
  8. Changed1 schema field changed
    • changedInput schema / properties / columns / description
      Previous value: -"Specific event_analytics columns to return (bare names, no namespace). Omit for the full row — this is the drill-down tool, so full is the default."New value: +"Specific event_analytics columns to return (bare names, no namespace). Omit for the full row; this is the drill-down tool, so full is the default."
  9. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds real behavior beyond that: current values are dated by their source timestamps, changes_close_date defines the UTC close used by changes, and dates in days_missing must not be filled. It stops short of describing response size, pagination, or failure modes beyond the ambiguous-id case that lives in the schema.

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 core statement, then routing, then parameter guidance — a sensible order with almost no filler. The middle sentence bundling range, view, sales definition, and metric semantics is dense and slightly overloaded, costing a point.

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 nine-parameter tool with no output schema, the description supplies the missing orientation: what the whole-event payload contains, which sibling to use instead, how time-ranged reads and missing dates behave, and that CAD/GBP answers must be quoted with currency and fx rate date. Remaining gaps (response shape, limits of the view=sales payload) are modest given 100% schema coverage.

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% and the schema's own parameter descriptions are unusually thorough (currency, view, event_id, range). The description mostly restates the when-to-use framing for range and view rather than adding format or syntax detail, so it earns the baseline rather than more; the one clear addition is tying changes to changes_close_date.

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 ("Returns one event's market numbers, whole-event") and enumerates the content: prices, inventory, demand, recent changes, prediction markets, sale windows, weather. It explicitly demarcates scope ("whole-event") against the sibling that handles sections (get_event_sections), so an agent can pick correctly without opening schemas.

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 routing: use this for one event's numbers now, get_event_sections for a section or GA, get_event_chart for a chart over time, screen_events for many events, research_event for news behind a move. It also states the trigger for the optional parameters ("Pass range for how they read on each past date, and view sales whenever the question is about this event's sales").

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