What's Up In: local events

Get what one What's Up In city covers: how many upcoming events it lists and for which dates, when its data was last published, how many sources feed it, and upcoming events per category, topic, neighborhood and town. Call it before searching a city to pick valid category, topic, neighborhood and town values, or to tell a user what that city covers; it returns counts only, no events (use search_events or list_upcoming for those, list_cities for every city at once). No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.

Get the full listing for one upcoming event by the `id` that search_events or list_upcoming returned, passing the same `city` it came from: title, dates, venue, price (all-in, or "See tickets"), the original listing (`link`), every source that lists it and first_seen / last_seen / last_fetched dates. Ids stay the same while an event is listed; a past or removed event returns an error, so search again. (search_across_cities results carry `on_site` links instead.) No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.

List every city What's Up In covers, with its site, its own MCP endpoint, its status (live or beta) and how many travel-worthy events it indexes now. Call it to find valid `city` values for search_events, list_upcoming, get_event and get_city, or names for search_across_cities' `cities`; for one city's neighborhoods, topics and event counts use get_city. Takes no arguments; the list changes only when a city launches. No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.

Browse the next N days of events in one What's Up In city, day by day, with no search words. `by_day` counts every match per date, and when more events match than `limit` the rows are spread evenly across the days, so each day is represented. Use it for overviews like "what's happening in <city> this week"; for search words, free-only, a town or exact from/to dates use search_events, and for one event's details get_event. Optional filters: one category or topic, and a place: `neighborhood` keeps events inside a named area (radius_km widens it past the boundary), `near` ranks events by distance from a place or "lat,lon" within radius_km. get_city lists valid neighborhood names. No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.

Search upcoming travel-worthy events in every What's Up In city at once: where an artist, band, comedian or team is playing, which cities have a festival, conference or expo, big arena shows, games and races. Only events worth a trip are indexed (named performers, festivals, conferences/expos, arena shows, games, races), not every local listing: for everything in one city (small gigs, classes, meetups) use search_events with its city. Give a `query`, at least one of `kinds`, or a place. Each result names its city and links to the original listing (`link`) and the event on that city's site (`on_site`); `searched` says which cities were included and how fresh each is. No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.

Search every upcoming event in one What's Up In city by words, dates, price, topic or place: music, dance, AI/tech, arts, comedy, food, sports, classes, volunteering, street fairs. Use it whenever the question has search words, a date range ("this weekend": from/to), free-only, a town or an area; for a day-by-day overview of the next few days with no search words use list_upcoming, and for an artist, festival or conference in several cities use search_across_cities. Words in `query` match the title, venue, performers, organizer or tags at the start of a word, singular or plural, with common synonyms; by default all must match, with match "any" (or | / commas between them) any one does; a misspelled word is read as the closest word the events use, and `search` in the result says how the query was read. Dates are the city's local dates. Results come earliest first, at most `limit`; `count` says how many matched in total, so narrow the search rather than paging. Each event has its original listing (`link`) and an `id` for get_event. No sign-in; each client gets 30 calls a minute and 2,500 event rows an hour.