swarmtix_attendees_search

Finds the tickets one buyer holds for an event, looked up by the email address they bought with, newest date first. This is the "did Sarah get her ticket?" tool.

When you would reach for it

• A support question about one person, without paging through the whole attendee list.
• Confirming a purchase when a buyer says nothing arrived.
• Checking whether a ticket has already been scanned, before issuing a replacement.

Scope

attendees:read

Ticket barcodes and security codes are never returned. The rows this tool reads carry both in memory; the projection is what keeps them off the wire, and it will stay that way. An assistant that could produce a barcode could produce admission.

Parameters

email is matched exactly. There is no partial match and no fuzzy match: [email protected] will not find [email protected] if that is what was typed at checkout, and it will not find a similar address.

Example call

{
  "name": "swarmtix_attendees_search",
  "arguments": {
    "event": "spring-summit-2026",
    "email": "[email protected]"
  }
}

What comes back

[
  {
    "index": 0,
    "eventId": "8f14e45f-ceea-467a-9c3d-1b2a5f6e7d80",
    "eventName": "Spring Summit 2026",
    "eventStart": "2026-11-05T10:00:00",
    "attendeeFirstName": "Sarah",
    "attendeeLastName": "Meyer",
    "buyerEmail": "[email protected]",
    "ticketType": "Workshop Add-on",
    "ticketCategory": "Free",
    "price": 0,
    "currency": "EUR",
    "currencySymbol": "€",
    "orderId": 184149,
    "timesScanned": 0
  },
  {
    "index": 1,
    "eventId": "8f14e45f-ceea-467a-9c3d-1b2a5f6e7d80",
    "eventName": "Spring Summit 2026",
    "eventStart": "2026-11-04T19:00:00",
    "attendeeFirstName": "Sarah",
    "attendeeLastName": "Meyer",
    "buyerEmail": "[email protected]",
    "ticketType": "General Admission",
    "ticketCategory": "Paid",
    "price": 45,
    "currency": "EUR",
    "currencySymbol": "€",
    "orderId": 184149,
    "timesScanned": 1
  }
]

Results come back newest scheduled date first, then by order, then by attendee name.

Cursors on this tool are positional

The reason is in the data rather than in the design. The query behind this tool does not select the sold ticket's id — every row arrives without one — so there is no stable key to resume from, and a key invented from the row's contents would collide for two identical tickets in the same order.

The practical consequence is the ordinary offset caveat: if the same buyer buys another ticket for the same event between two pages, every later row shifts by one, and you can see a row twice or miss one. That is bounded here in a way it would not be on an event-wide list, because the set being paged is one buyer's tickets for one event — usually a handful of rows, and usually all in the first page.

If it matters, raise limit so the whole result fits in one call.

What happens when you call it

1. The event identifier is resolved and the ownership checks run.
2. email is required and trimmed. An empty one is refused.
3. If eventDate was given, only that date is searched. If it was omitted, the event's dates are read and each one is searched in turn, and the results are combined. Omitting the date genuinely means every date here — the underlying lookup matches a date exactly, so a blank one would match nothing at all and return an empty list with no sign that the question was never asked.
4. The combined results are sorted newest date first, then by order, then by surname and first name.
5. One page is cut by position, projected to the fields above, and serialized.

Because step 3 searches date by date, an event with many dates makes many lookups on one call. That is normal; the result is the same.

Troubleshooting

The result is empty for someone you know bought a ticket

In order of likelihood:

• The address differs from the one used at checkout. The match is exact. Find them on swarmtix_orders_list and use the address on the order.
• They are an attendee, not the buyer. This tool searches by the buyer's address. A ticket bought for someone else is found under the purchaser's email.
• They bought for a different event. The search is scoped to the one event you named.

"email is not valid: it was empty. Expected the email address the buyer used at checkout."

The email argument was missing or blank.

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

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

A row appeared twice across two pages

The positional cursor — see above. The buyer bought again between the two calls. Raise limit so the result fits in a single page.

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

Reconnect and approve attendees:read.

Use cases

• "Did this person get their ticket?" — the whole tool in one question
• Checking for a duplicate purchase before issuing a refund in the dashboard
• Scan history — timesScanned before reissuing a ticket
• Multi-day attendance — which dates one buyer holds tickets for