get_event_chart

Charts one event over time, one row per date: its prices and inventory, or its demand.

When to use it

You want the price path of one event: how its median and lowest prices and its listings moved, from the source you pick.
You want to see whether demand for one event is building or fading: set metric to demand.
For one section in finer steps, use get_event_sections_live with view series. For the event's other numbers over time, use get_event_analytics with range.
It replaces get_event_price_chart and get_event_demand_chart, whose names still answer: see Old names.

metric (string): price (the default) for prices and inventory, demand for interest in the event's listings and recent ticket sales. One of price, demand.
event_id (string, required): The event, by its Ticker id (ev plus ten characters), as search_events and the other tools return it.
range (string): How far back the series reaches: 90 days for price and 28 days for demand when you leave it out. all reaches back up to one year. For an event that has taken place, it counts back from the event date. With price it applies to vs only: the other sources always answer their full history. One of 7d, 14d, 28d, 90d, all.
source (string): With price, the market the prices come from. vs, tp, tmr, gt, sg and sh are the resale market; tm, mlb (the team's own box office for a baseball game) and sgp are the primary market. Never put a primary and a resale source in one series. It does not apply to demand. One of vs, tp, tm, tmr, gt, sg, sh, mlb, sgp.
render (boolean): Include a chart image ahead of the data. Set false for the data only, a smaller answer.

How has the price of this concert moved over the last 90 days?

{ "event_id": "ev3rp4z4zhq1" }

Is demand for this game building or fading? Data only, no chart.

{ "event_id": "ev5t9h2w7k3c", "metric": "demand", "render": false }

What is left on the primary market for this show, and at what price?

{ "event_id": "ev8k2m4q7x1a", "source": "tm" }

With price and vs: one row per date, oldest first. median_price and the middle half of prices (p25_price to p75_price) are averages across that date; lowest_price and lowest_aip_price are its low. An aip price is all-in, what the buyer pays. Each row also carries listings_min, listings_max, tickets_min, tickets_max and percent_remaining.
With price and any other source: source, meta and series, a list of date, floor, median, p25, p75, listings and tickets, with no image. meta.mapped false means the event has no link to that source.
With demand: one row per date with snapshot_date, interest and sales. Each is a level over a recent window, not a count for that date: read the change from one date to the next as momentum, and never report a value as tickets bought that day.
days_missing lists the dates in the span with no row: treat each as a gap and never fill it in. event_name, local_date and venue_name name the event, so a chart legend reads a name, not an id.
A chart image comes first unless render is false. rows is empty when the event has no history.

Reads only: it changes nothing.
Each call spends one MCP request.
Every plan reads the full vs series and demand. The Pro plan and above include tp; the Max plan and above include tm, tmr, gt, sg, sh, mlb and sgp. A source your plan does not include is refused with a plan_required error.
Demand history starts on 2026-07-17, so long demand ranges are short for now.
The Max plan and above include events that have already taken place.
An input the metric does not take, like source with demand, is refused by name.