Ticker: Live Event Ticket Market

Get Event Seller Activity

get_event_sellers

Read-only

Returns anonymous seller data for one event: how much of its inventory the largest sellers hold, how lettered sellers moved hour by hour, and chosen sellers' prices and listings. No seller is named; a letter is an arrival order, not a rank, and matches the event page. Use it when the person asks how concentrated an event's inventory is or how its largest sellers price and list.

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

Input Schema

Name	Required	Description
`view`	No	now (default): concentration: active sellers, top shares, hhi and coverage. series: the lettered sellers hour by hour, up to 720 hours. options: the letters that can be chosen, each seller that reached 10 live listings over the range, with its peak. market: chosen sellers' prices and listings over time and per section. aggregate: their prices alone. sections: their listings per section alone.
`hours`	No	How many of the most recent hours to return. Default 168, maximum 720.
`range`	No	How far back the series reads. Default 7d.
`sellers`	No	Seller letters, `["A", "C"]`.
`currency`	No	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.
`event_id`	Yes	The event to read.
`sections`	No	Optional section keys, the section_key of `get_event_sections` rows (e.g. ["108","FLOOR-10"]).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

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."

Changed1 schema field changedNov 4, 2026

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."

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / view / description

Previous value: -"now (default): concentration. series: sellers hour by hour. market: chosen sellers' prices."New value: +"now (default): concentration: active sellers, top shares, hhi and coverage. series: the lettered sellers hour by hour, up to 720 hours. options: the letters that can be chosen, each seller that reached 10 live listings over the range, with its peak. market: chosen sellers' prices and listings over time and per section. aggregate: their prices alone. sections: their listings per section alone."

changedInput schema / properties / view / enum

Previous value: -[
-  "now",
-  "series",
-  "market"
-]New value: +[
+  "now",
+  "series",
+  "options",
+  "market",
+  "aggregate",
+  "sections"
+]

Changed1 schema field changedOct 28, 2026

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

Changed2 schema fields changedOct 27, 2026

removedInput schema / properties / section_ids

Removed value: -{
-  "description": "Optional section ids, as `get_event_sections` keys them.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedInput schema / properties / sections

Added value: +{
+  "description": "Optional section keys, the section_key of `get_event_sections` rows (e.g. [\"108\",\"FLOOR-10\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

AddedOct 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add semantics — and it does: seller identity is anonymized, a letter is an arrival-order label rather than a ranking, and the letters align with the event page. Those are non-obvious interpretive facts an agent would otherwise get wrong. It does not describe response shape or the different payloads per view mode, but the schema's view enum covers that.

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?

Three sentences, front-loaded with the return content and then the trigger condition, with no filler. The anonymity caveat is placed where it matters — immediately after the data summary — rather than buried. Slightly dense but every clause carries information.

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 7-parameter, multi-mode read tool with no output schema, the description plus the richly documented schema cover what an agent needs to call it correctly. The one gap is that the description does not signal that the six view modes return structurally different payloads, leaving that entirely to the schema's view enum text.

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 description coverage is 100%, so the schema already documents view modes, hours bounds, range defaults, seller letters, currency conversion, and section keys in detail. The description adds only the framing that sellers are referenced by letter, without new syntax or format guidance beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 — 'Returns anonymous seller data for one event' — and enumerates the concrete contents: top-seller inventory share, hour-by-hour movement of lettered sellers, and chosen sellers' prices and listings. That scope is distinct enough from get_event_analytics and get_event_sections for an agent to choose correctly, though no sibling is named explicitly.

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?

It gives a clear positive trigger: 'Use it when the person asks how concentrated an event's inventory is or how its largest sellers price and list.' That is a genuine usage condition rather than an implied one. It stops short of naming exclusions or the alternative tool for adjacent questions (e.g. seat-level or section-level queries), which keeps it from a 5.

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?