Ticker: Live Event Ticket Market

Event Section Counts

get_event_sections_live

Read-only

Open seats per section of one event from the seat log. view now (the default): each section right now, with the lowest, median and highest price, capacity and what left the resale market. view at: every section's open count at a past moment, up to 90 days back; call it twice and subtract to see where seats went. view series: one section over up to 7 days, in 5m or 1h steps; only the newest point's prices are exact. view ga: each general admission section's open count over time; added and removed are changes, not sales. Use get_event_sections for prices over 7 days and get_event_seats for single seats. Replaces get_event_sections_at, get_event_section_series and get_event_ga_history.

Input Schema

TableJSON Schema

Name	Required	Description
`at`	No	The instant to read the house at, ISO 8601. Defaults to now.
`view`	No	now (default), at (a past moment), series (one section over time), ga (general admission over time).
`limit`	No	now: sections returned when `sections` is omitted, default 60. ga: points per page, default 200.
`since`	No	Oldest point to include, ISO 8601. Defaults to 24 hours ago.
`width`	No	Instead of pages: the shape of the whole history in one answer, as the first, last, lowest and highest point of each of `width` equal slices of time from the section's first observation to now. At most four points a slice. Use it for the shape of a busy section, which can hold tens of thousands of changes.
`all_in`	No	Adds each section's lowest, median and highest price after fees and whether the lowest is an estimate. On by default; false returns the prices before fees alone.
`bucket`	No	Point size: 5m for the last few hours, 1h for days. `open_count` is exact at every bucket. THE PRICES ARE NOT: they are exact on the newest bucket only; on every earlier bucket they are the seats open now valued at the prices recorded for that bucket, an approximation. Never present an earlier bucket's price as the price at that time.
`cursor`	No	next_cursor from the previous page, for newer points. A page after the first carries the points alone.
`section`	No	series: the section's ticket code, e.g. "104" (required). ga: a general admission section's code, to add its exact points.
`event_id`	Yes	The event to read.
`sections`	No	Only these sections, by ticket code (e.g. ["104","FL2"]). Omit for the whole house.
`occurrence`	No	0 unless the event lists the code twice, as `sections` shows. `section` and `occurrence` together name one section.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

changedInput schema / properties / all_in / description

Previous value: -"Adds each section's lowest price after fees and whether it is an estimate. On by default; false returns the prices before fees alone."New value: +"Adds each section's lowest, median and highest price after fees and whether the lowest is an estimate. On by default; false returns the prices before fees alone."

Changed11 schema fields changedOct 15, 2026

removedInput schema / properties / all_in / default
```
Removed value: -true
```

addedInput schema / properties / at

Added value: +{
+  "description": "The instant to read the house at, ISO 8601. Defaults to now.",
+  "format": "date-time",
+  "type": "string"
+}

addedInput schema / properties / bucket

Added value: +{
+  "description": "Point size: 5m for the last few hours, 1h for days. `open_count` is exact at every bucket. THE PRICES ARE NOT: they are exact on the newest bucket only; on every earlier bucket they are the seats open now valued at the prices recorded for that bucket, an approximation. Never present an earlier bucket's price as the price at that time.",
+  "enum": [
+    "5m",
+    "1h"
+  ],
+  "type": "string"
+}

addedInput schema / properties / cursor

Added value: +{
+  "description": "next_cursor from the previous page, for newer points. A page after the first carries the points alone.",
+  "minLength": 1,
+  "type": "string"
+}

removedInput schema / properties / limit / default
```
Removed value: -60
```

changedInput schema / properties / limit / description

Previous value: -"Cap on sections returned when `sections` is omitted. The widest events draw 650 sections; `sections_total` is always the true count."New value: +"now: sections returned when `sections` is omitted, default 60. ga: points per page, default 200."

addedInput schema / properties / occurrence

Added value: +{
+  "description": "0 unless the event lists the code twice, as `sections` shows. `section` and `occurrence` together name one section.",
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / section

Added value: +{
+  "description": "series: the section's ticket code, e.g. \"104\" (required). ga: a general admission section's code, to add its exact points.",
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / since

Added value: +{
+  "description": "Oldest point to include, ISO 8601. Defaults to 24 hours ago.",
+  "format": "date-time",
+  "type": "string"
+}

addedInput schema / properties / view

Added value: +{
+  "description": "now (default), at (a past moment), series (one section over time), ga (general admission over time).",
+  "enum": [
+    "now",
+    "at",
+    "series",
+    "ga"
+  ],
+  "type": "string"
+}

addedInput schema / properties / width

Added value: +{
+  "description": "Instead of pages: the shape of the whole history in one answer, as the first, last, lowest and highest point of each of `width` equal slices of time from the section's first observation to now. At most four points a slice. Use it for the shape of a busy section, which can hold tens of thousands of changes.",
+  "maximum": 2000,
+  "minimum": 50,
+  "type": "integer"
+}

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / all_in / description

Previous value: -"Adds each section's lowest price after fees and whether it is an estimate. On by default; false returns the list prices alone."New value: +"Adds each section's lowest price after fees and whether it is an estimate. On by default; false returns the prices before fees alone."

Changed1 schema field changedOct 10, 2026
- removedInput schema / properties / limit / maximum
```
Removed value: -650
```

Changed2 schema fields changedOct 7, 2026

changedInput schema / properties / all_in / default
```
Previous value: -falseNew value: +true
```

changedInput schema / properties / all_in / description

Previous value: -"True adds each section's lowest price after fees and whether it is an estimate."New value: +"Adds each section's lowest price after fees and whether it is an estimate. On by default; false returns the list prices alone."

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare a safe read (readOnlyHint, non-destructive, non-open-world); the description adds genuinely non-obvious behavior: prices are exact only on the newest bucket and are approximations on earlier buckets ('Never present an earlier bucket's price as the price at that time'), and for GA 'added and removed are changes, not sales'. It also discloses time-window limits (90 days, 7 days) and the existence of a seat log as the data source.

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 purpose, then view-by-view, then alternatives and deprecations; every clause carries routing or caveat information, so little is wasted. The density of semicolon-chained clauses makes it slightly harder to scan than a fully structured list, but it is not padded.

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 12-parameter tool with no output schema, the description covers modes, time ranges, defaults, price caveats and alternatives well enough to call it correctly. It stops short of describing the response shape (e.g. per-section fields, pagination envelope beyond `next_cursor`), which is the only material gap.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds meaning the schema alone does not: it explains what each enum value of `view` actually returns, the 90-day cap on `at`, the 7-day cap and step sizes for `series`, the dependency that `section` is required for `series`, and the semantics of `bucket` price approximation. It also clarifies the page/`width` trade-off in prose.

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?

Opens with a specific verb and resource ('Open seats per section of one event from the seat log') and then enumerates the four distinct views, so the agent knows exactly what each mode returns. It explicitly separates itself from get_event_sections and get_event_seats and names the three tools it replaces, which is precisely what an agent needs to disambiguate among the crowded sibling set.

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 when-to-use guidance per view ('view now: ... view at: every section's open count at a past moment, up to 90 days back', 'view series: one section over up to 7 days'), including the workaround of calling 'at' twice and subtracting. It also names alternatives with their selection conditions ('Use get_event_sections for prices over 7 days and get_event_seats for single seats').

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?