Related Servers

Descriptions do a good job distinguishing organizer-side vs public vs consumer-side (eb_org_events vs eb_organizer_events vs eb_my_orders), but there are several near-parallel tools: three order listers (eb_my_orders, eb_org_orders, eb_event_orders), two attendee listers (eb_org_attendees, eb_event_attendees), and overlapping event fetchers (eb_event, eb_event_details, eb_search_events, eb_series_events). An agent must read carefully to pick correctly; boundaries exist but are not immediately obvious from names alone.

Almost everything follows a predictable eb_<scope>_<resource> snake_case pattern (eb_org_events, eb_event_attendees, eb_ticket_classes). A few tools deviate (eb_me, eb_healthcheck, eb_reference) but these are still readable and purposeful. Minor ordering variation (org_/event_ prefix placement) does not undermine consistency.

31 tools is above the heavy threshold and includes clear redundancy in the order- and attendee-listing families. The Eventbrite domain is broad, but the surface feels padded rather than tightly scoped for the read-only intent.

Read coverage is broad — profile, orgs, events, attendees, orders, tickets, venues, organizers, series, discounts, webhooks, reports, search, and a healthcheck. However, the surface is entirely read-only with no create/update/delete or check-in mutations, and webhooks/discounts are list-only, which is a notable gap for an Eventbrite management server.