swarmtix_tickets_summary

Returns the headline ticket counts for one scheduled date of an event: how many tickets were put on sale, how many have sold, and how many have been checked in.

When you would reach for it

• A door check before opening — sold against checked-in, for the date you are about to run.
• A one-number answer when the full analytics record would be more than the question needs.
• Reserved-seating events, where the counts come from the seat map rather than from ticket-type inventory and this tool picks the right query for you.

For a whole event, and for revenue, use swarmtix_analytics_event — it aggregates across every date when you omit eventDate, which is the behaviour people expect from this one.

Scope

orders:read

It counts what has been sold, which is commercial information about orders rather than about the event's setup — so it sits with the order tools rather than under events:read. It returns no names and no email addresses.

Parameters

Example call

{
  "name": "swarmtix_tickets_summary",
  "arguments": {
    "event": "spring-summit-2026",
    "eventDate": "2c9a7f31-4d88-4f6a-b0e1-5a7c3d9e2f41"
  }
}

What comes back

{
  "eventId": "8f14e45f-ceea-467a-9c3d-1b2a5f6e7d80",
  "eventDateId": "2c9a7f31-4d88-4f6a-b0e1-5a7c3d9e2f41",
  "ticketsOnSale": 250,
  "ticketsSold": 182,
  "ticketsCheckedIn": 0
}

Three fields, and only three. The record behind this tool has seventeen, but this query fills in three of them; the other fourteen come back as zero and null. Publishing them would report every event as having earned nothing rather than as not having been asked.

What happens when you call it

1. The event identifier is resolved and the ownership checks run.
2. eventDate is parsed if given. If it is absent, an empty date id is used — and downstream that means "the earliest date", not "all dates".
3. The event row is read to find out whether it uses reserved seating. That flag picks between two entirely different queries, and passing the wrong one returns a wrong-shaped answer rather than an error, so it is taken from the event rather than accepted as an argument.
4. The counts are fetched and three fields are returned.

Troubleshooting

The numbers are lower than the event's real totals

You omitted eventDate on a multi-day event, so you are looking at the earliest date. Pass a date id, or use swarmtix_analytics_event for the event as a whole.

The missing eventDateId in the response is the tell: when it is absent, the counts describe the earliest date.

"eventDate is not valid: it is not an id. Expected an event date id (a GUID) from the event dates tool, or nothing for every date."

eventDate must be a date id from swarmtix_event_dates_list, not a calendar date. An unparseable value is refused rather than ignored, because silently falling back would answer a different question with a number that looks like the answer to yours.

"Event not found, or this connection does not have access to it."

The event does not exist, or it belongs to a different organisation than this connection covers.

ticketsCheckedIn is 0 during an event that is clearly running

Check-in is recorded when a ticket is scanned. If the door is not scanning, the count stays at zero — the MCP catalog has no check-in tool, so nothing here can have changed it.

"This connection is not authorized for orders:read. Reconnect and grant it to use this tool."

Reconnect and approve orders:read.

Use cases

• Door briefing — one line: on sale, sold, checked in, for today's date
• Per-day comparison on a multi-day run, one call per date id
• Sell-through — ticketsSold against ticketsOnSale
• Post-event no-show rate — sold against checked in