Ticker: Live Event Ticket Market

List Event Alert Matches

list_matches

Read-only

Lists Matches: the events that entered the account's Views (saved event filters), newest first, each with its delivery_status. Pass view_id for one View's Matches with a summary of the View, or match_id for one Match in full, with the event's numbers frozen when it entered. Use it to review alert history or to check whether an alert went out: read delivery_status, never a timestamp, for whether an email was sent. For what a View would send, use get_view_alert_preview.

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": "list_matches"
  }
}

Input Schema

Name	Required	Description
`page`	No	The page to read, from 1. Default 1.
`sort`	No	matched_at, the one order a page of Matches takes.
`limit`	No	Matches per page. Default 20, at most 100.
`order`	No	By matched_at. Default newest first.
`since`	No	ISO 8601 timestamp; only matches at/after this. Default: 7 days ago.
`view_id`	No	Only this View's Matches (an id from list_views), with a summary of the View.
`event_id`	No	Only the Matches of this event, by its Ticker event id.
`match_id`	No	The match id (from list_matches' match_id field).
`delivery_status`	No	DELIVERY TRUTH: read `delivery_status`, never infer delivery from a timestamp: 'sent' = an alert email actually carried this Match; 'not_sent' = terminally dropped and never sent (see `delivery_reason`, e.g. muted_view, locked_view, email_digests_off (the owner turned alert emails off), view_disabled); 'pending' = not processed yet, may still be sent; 'not_applicable' = was never eligible for an alert email (a baseline Match, or a View that delivers only to alert destinations). `notified_at` is non-null ONLY when delivery_status is 'sent'; `consumed_at` is when the Match was claimed whatever the outcome. NEVER report a Match as delivered unless delivery_status is 'sent'. Only Matches in this delivery state. Use 'sent' for "which alert emails actually went out" and 'not_sent' for "what was dropped, and why"; do NOT infer either from a timestamp. Note: the 'not_applicable' filter matches baseline Matches only; destination-only Views are labeled not_applicable on the row but are not selected by this filter.
`include_snapshot`	No	Inline the full frozen snapshot (event + event_analytics + performer_analytics) on every row. Heavy: a page can exceed the tool result token cap. Read one Match in full with match_id instead.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 2, 2026

addedInput schema / properties / event_id / description

Added value: +"Only the Matches of this event, by its Ticker event id."

changedInput schema / properties / include_snapshot / description

Previous value: -"Inline the full frozen snapshot (event + event_analytics + performer_analytics) on every row. Heavy: a page can exceed the tool result token cap. Prefer the compact default + get_match for drill-down."New value: +"Inline the full frozen snapshot (event + event_analytics + performer_analytics) on every row. Heavy: a page can exceed the tool result token cap. Read one Match in full with match_id instead."

addedInput schema / properties / limit / description

Added value: +"Matches per page. Default 20, at most 100."

addedInput schema / properties / order

Added value: +{
+  "description": "By matched_at. Default newest first.",
+  "enum": [
+    "asc",
+    "desc"
+  ],
+  "type": "string"
+}

addedInput schema / properties / page / description

Added value: +"The page to read, from 1. Default 1."

addedInput schema / properties / sort

Added value: +{
+  "description": "matched_at, the one order a page of Matches takes.",
+  "enum": [
+    "matched_at"
+  ],
+  "type": "string"
+}

addedInput schema / properties / view_id / description

Added value: +"Only this View's Matches (an id from list_views), with a summary of the View."

Changed5 schema fields changedOct 15, 2026

changedInput schema / properties / delivery_status / description

Previous value: -"Only Matches in this delivery state. Use 'sent' for \"which alert emails actually went out\" and 'not_sent' for \"what was dropped, and why\"; do NOT infer either from a timestamp. Note: the 'not_applicable' filter matches baseline Matches only; destination-only Views are labeled not_applicable on the row but are not selected by this filter."New value: +"DELIVERY TRUTH: read `delivery_status`, never infer delivery from a timestamp: 'sent' = an alert email actually carried this Match; 'not_sent' = terminally dropped and never sent (see `delivery_reason`, e.g. muted_view, locked_view, email_digests_off (the owner turned alert emails off), view_disabled); 'pending' = not processed yet, may still be sent; 'not_applicable' = was never eligible for an alert email (a baseline Match, or a View that delivers only to alert destinations). `notified_at` is non-null ONLY when delivery_status is 'sent'; `consumed_at` is when the Match was claimed whatever the outcome. NEVER report a Match as delivered unless delivery_status is 'sent'. Only Matches in this delivery state. Use 'sent' for \"which alert emails actually went out\" and 'not_sent' for \"what was dropped, and why\"; do NOT infer either from a timestamp. Note: the 'not_applicable' filter matches baseline Matches only; destination-only Views are labeled not_applicable on the row but are not selected by this filter."

removedInput schema / properties / include_snapshot / default
```
Removed value: -false
```
removedInput schema / properties / limit / default
```
Removed value: -20
```

addedInput schema / properties / match_id

Added value: +{
+  "description": "The match id (from list_matches' match_id field).",
+  "format": "uuid",
+  "type": "string"
+}

removedInput schema / properties / page / default
```
Removed value: -1
```

Changed2 schema fields changedOct 10, 2026

removedInput schema / properties / limit / maximum
```
Removed value: -100
```

changedInput schema / properties / since / description

Previous value: -"ISO 8601 timestamp; only matches at/after this."New value: +"ISO 8601 timestamp; only matches at/after this. Default: 7 days ago."

Changed2 schema fields changedOct 3, 2026

changedInput schema / properties / delivery_status / description

Previous value: -"Only Matches in this delivery state. Use 'sent' for \"which alert emails actually went out\" and 'not_sent' for \"what was dropped, and why\" — do NOT infer either from a timestamp. Note: the 'not_applicable' filter matches baseline Matches only; destination-only Views are labelled not_applicable on the row but are not selected by this filter."New value: +"Only Matches in this delivery state. Use 'sent' for \"which alert emails actually went out\" and 'not_sent' for \"what was dropped, and why\"; do NOT infer either from a timestamp. Note: the 'not_applicable' filter matches baseline Matches only; destination-only Views are labeled not_applicable on the row but are not selected by this filter."

changedInput schema / properties / include_snapshot / description

Previous value: -"Inline the full frozen snapshot (event + event_analytics + performer_analytics) on every row. Heavy — a page can exceed the tool result token cap. Prefer the compact default + get_match for drill-down."New value: +"Inline the full frozen snapshot (event + event_analytics + performer_analytics) on every row. Heavy: a page can exceed the tool result token cap. Prefer the compact default + get_match for drill-down."

First observedOct 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered; the description adds real behavioral context on top — the match-modes (view_id returns a View summary, match_id returns one Match in full with frozen numbers) and the warning that include_snapshot can exceed the tool result token cap. It stops short of describing the row shape or how paging metadata comes back, so it is strong but not exhaustive.

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 definition, then the mode guidance, then the sibling pointer — a sensible order with no filler. It is somewhat dense, and the delivery_status explanation is largely duplicated from the schema, but every sentence still carries operative information for the caller.

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?

With 10 optional parameters and no output schema, the description does the important work: it defines what a Match is, what each mode returns, and how to interpret delivery outcomes. It leaves the full row shape (other than delivery_status and the optional snapshot) and pagination response format unstated, which is a modest gap for a list tool with no output schema.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the mode-switching behavior of view_id vs match_id and what each returns, which the schema only hints at per-parameter. It says nothing about event_id, since, sort, order, page or limit, leaving those entirely to the schema.

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 ('Lists Matches'), then defines the domain term — events that entered the account's Views — and the ordering ('newest first'), which no sibling covers. It also names the near-miss sibling (get_view_alert_preview) so the agent can separate the two without reading either schema.

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 both when-to-use cases ('review alert history', 'check whether an alert went out') and an explicit alternative with its selection condition ('For what a View would send, use get_view_alert_preview'). It further prescribes the correct field to read for delivery (delivery_status, never a timestamp), which is guidance an agent would otherwise get wrong.

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?