Read-only search of upcoming local events in US cities: music, comedy, AI/tech, arts, food, sports.
Scored across 5 tools
Each tool has a distinct scope: get_event fetches by id, list_cities enumerates coverage, list_upcoming browses next N days in one city, search_events keyword-searches one city, and search_across_cities fans out across all cities for travel-worthy events. The main overlap is between list_upcoming and search_events, both scoped to a single city, but descriptions differentiate them by time-window browsing vs. keyword query.
All names follow a clean snake_case verb_noun pattern: get_event, list_cities, list_upcoming, search_events, search_across_cities. Verbs consistently lead and the resource/scope is clear in each name.
Five tools is well-matched to a read-only local-events discovery server, and each tool earns its place: detail lookup, city enumeration, two scoped searches, and one cross-city search. No redundant or filler tools.
The read-only discovery surface is solid: city coverage, per-city and cross-city search, time-window browsing, and single-event detail with provenance. Minor gaps exist around explicit category/topic enumeration or cross-city event detail, but core workflows are fully covered for the stated purpose.
Look up one upcoming event by the id search_events or list_upcoming returned, with its source link and first_seen / last_seen / last_fetched dates.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 12-character event id | |
| city | Yes | Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context — that the record includes a source link and first_seen / last_seen / last_fetched timestamps — which is valuable given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then packs id provenance and returned fields without a wasted word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read tool with no output schema, the description covers the lookup key's origin and enumerates what comes back, which is what an agent needs to call and interpret it. It could still note behavior when the id is stale or the event has passed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (id format, city enumeration all documented), so the baseline is 3. The description adds provenance semantics for `id` by tying it to the outputs of search_events and list_upcoming, which the schema does not state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (look up) and resource (one upcoming event), scoped to a single record retrieved by `id`, and tells the agent where that id comes from (search_events or list_upcoming). An agent can distinguish this from list_upcoming/search_events without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the workflow prerequisite: the `id` must come from a prior search_events or list_upcoming call. It does not state explicit exclusions or say when to prefer a sibling over this tool (e.g., what to do if the event is no longer upcoming), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cities What's Up In covers, each with its site, its own MCP endpoint, and how many travel-worthy events it currently indexes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the full safety profile is covered by structured data. The description adds nothing behavioral beyond that — no indication of whether the city set is static or grows, whether entries refresh, or any rate/size limits — though for a fixed-catalog read there is little behavior left to disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the resource and then specifies the payload contents; every clause carries information and none is redundant. No boilerplate, no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, describing the shape of each returned entry (site, MCP endpoint, event count) is the key missing piece and the description supplies it. Annotations cover safety, and there are no parameters, so the remaining gap is minor: it never states that returned cities are the valid inputs for the sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and the description correctly does not invent any. Nothing in the schema needs further explanation, and there is no risk of misusing input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (the cities the service covers) and enumerates what each entry contains: site, MCP endpoint, and indexed event count. That is well beyond a tautology and lets an agent distinguish this catalog tool from the event-oriented siblings (get_event, list_upcoming, search_events). It loses a point only because the operation is expressed as a noun phrase rather than a verb, leaving 'list' to be inferred from the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus search_across_cities, list_upcoming, or the other siblings, and no mention that this is the natural discovery step for obtaining valid city identifiers. The usage context is inferable but never stated, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The next N days of events in one What's Up In city, optionally one category, topic or place. by_day counts every match per date; over limit, the rows shown are spread across the days.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list. | |
| days | No | Window in days (default 7) | |
| near | No | Events within radius_km of a place in the city: a neighborhood, a town, a venue name, or "lat,lon". Results get distance_km, nearest first within each day. | |
| limit | No | Max rows (default 50) | |
| topic | No | ||
| category | No | ||
| radius_km | No | Distance for near (default 1.5, max 50), or how far neighborhood reaches past its boundary (default 0) | |
| neighborhood | No | Only events in this neighborhood or town of the city, e.g. 'Capitol Hill', 'Silver Lake', 'Cambridge'. Events whose venue isn't mapped can't be placed and are left out (place.unplaced_events counts them). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful behavior about how rows are spread across days when `limit` is exceeded, but the `by_day` clause references something not present as a parameter nor explained as output, adding ambiguity rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with scope then behavior. Little waste, though the orphaned `by_day` clause spends words on an unexplained concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-param read-only list tool with no output schema, the description covers scope and the key limit/date-spreading behavior plus sibling routing context. The dangling `by_day` reference and unaddressed near/radius interaction are minor remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% with enums and constraints already documented. The description echoes category/topic/place and adds the meaningful limit-spreading rule, but does not clarify the schema-ambiguous `radius_km` dual role (near-radius vs neighborhood padding) or the optional-narrowing interaction between near/neighborhood/topic/category.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource ('list upcoming events') scoped to 'one What's Up In city' with optional category/topic/place filters, which implicitly distinguishes it from search_across_cities. The scope is legible without opening the schema, though the stray reference to `by_day` (not a parameter) slightly muddies the otherwise clean statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'In one city' implies the contrast with search_across_cities, but there is no explicit when-to-use rule or named alternative. The agent must infer that get_event is for a single event and search_across_cities spans cities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search upcoming travel-worthy events across every What's Up In city at once (Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo): where an artist, band, comedian or team is playing, which cities have a festival, conference or expo, big arena shows, 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, use search_events with its city. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD, optional | |
| from | No | YYYY-MM-DD, default today | |
| near | No | "lat,lon": only events within radius_km of it, with distance_km. (search_events also takes place names.) Unmapped venues are left out (place.unplaced_events). | |
| kinds | No | Only these kinds: act = named performers; festival = festival; major = major local festival; conference = conference / expo; big_show = arena or amphitheater show; game = sports game (any level); pro_game = professional sports game (MLB, NFL, NBA, NHL, MLS, WNBA, NWSL); race = race. | |
| limit | No | Default 50 | |
| query | No | An artist, band, comedian, team, festival or conference name, or words to match in titles/performers/venues, e.g. 'Khruangbin', 'Oktoberfest', 'AI summit'. Optional when `kinds`, `neighborhood` or `near` is given. | |
| cities | No | Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. Default: all. | |
| radius_km | No | Radius for near (default 10, max 200) | |
| trip_only | No | Only events worth a special trip (multi-day festivals, festivals on a city's watchlist, arena/amphitheater shows, multi-day conferences, full-distance races). Default: true when there is no query, false when searching a name. | |
| neighborhood | No | Only events in this neighborhood or town (whole words, e.g. 'Silver Lake', 'South End', 'Pasadena'). Events whose venue isn't mapped can't be placed and are left out; place.unplaced_events counts them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond them: the trip-worthy indexing filter, and the returned `link`, `on_site` and `searched` (freshness) fields. It still does not discuss pagination limits or rate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the search_events alternative are front-loaded, which is good. However, the full 23-city list is enumerated in the prose even though the `cities` parameter schema already lists it verbatim, which is redundant bulk that dilutes the otherwise tight sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 optional parameters, no output schema, and no annotations exposing behavior, the description does well by naming return fields and the freshness signal. Missing only edge-case behavior (empty results, limits) that an agent would want for a broad multi-city search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including the enum-typed `kinds` and the near/neighborhood caveats is already documented in the schema. The description mainly restates the trip_only/coverage semantics rather than adding parameter-level detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (upcoming travel-worthy events) with explicit scope (across every city at once), and names the sibling it is not (search_events for a single city). The kinds of events indexed are enumerated, so an agent can distinguish it from search_events without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to search_events when everything in one city is needed, and clarifies the inclusion criterion (only trip-worthy events, not every local listing). It gives strong positive guidance but does not state other exclusions or fallbacks (e.g., when a city returns nothing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search every upcoming event in one What's Up In city (Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo): music, dance, AI/tech, arts, comedy, food, sports, classes, volunteering, street fairs. Use it for "what's on in this weekend", "free comedy near " and the like. All words in query must match title/location/performers/organizer/tags. Dates are the city's local dates, YYYY-MM-DD. Each event links to its original listing (link) and carries an id for get_event.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Latest date, YYYY-MM-DD (default: none) | |
| city | Yes | Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list. | |
| free | No | Only free events | |
| from | No | Earliest date, YYYY-MM-DD (default: today) | |
| near | No | Events within radius_km of a place in the city: a neighborhood, a town, a venue name, or "lat,lon". Results get distance_km, nearest first within each day. | |
| town | No | Only events in this town or city within the metro, e.g. 'Oakland', 'Pasadena' (case-insensitive) | |
| limit | No | Max results (default 25) | |
| query | No | Free text, e.g. 'salsa', 'hackathon', 'street fair', an artist or venue | |
| topic | No | Topic, e.g. comedy, film, food_drink, sports, talks, classes, markets, outdoors | |
| category | No | Scored category | |
| radius_km | No | Distance for near (default 1.5, max 50), or how far neighborhood reaches past its boundary (default 0) | |
| neighborhood | No | Only events in this neighborhood or town of the city, e.g. 'Capitol Hill', 'Silver Lake', 'Cambridge'. Events whose venue isn't mapped can't be placed and are left out (place.unplaced_events counts them). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral content: query is AND-matched across title/location/performers/organizer/tags, dates are interpreted in the city's local timezone, and results carry `link` and an `id` usable with get_event. It does not mention pagination or result ordering beyond the distance note, but the added semantics are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and trigger examples are front-loaded and the prose is dense with useful detail. The main waste is the full 23-city enumeration, which is duplicated verbatim in the `city` schema description and consumes a large share of the text; the topic/category keyword lists are likewise partly redundant with the enums.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, one required, no output schema, and a closed-world read, the description supplies what an agent needs: scope, trigger phrasing, query semantics, date semantics, and the shape of returned identifiers. Defaults (limit 25, from=today, radius_km 1.5) are left to the schema, which documents them, so this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a 3 is the baseline. The description goes beyond it by defining the matching semantics of `query` (all words must match across five specific fields) and clarifying that from/to are local city dates in YYYY-MM-DD. That is genuine added meaning, not restatement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (every upcoming event) with an explicit scope qualifier ('in one What's Up In city'), which cleanly separates it from the sibling search_across_cities. The list of event domains (music, comedy, sports, volunteering, etc.) further pins down what the index contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger phrases ('what's on in <city> this weekend', 'free comedy near <neighborhood>'), which tell the agent exactly which user utterances this tool answers. It stops short of naming when NOT to use it or pointing to list_upcoming / search_across_cities as alternatives, so routing between siblings still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_event1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."list_upcoming1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."search_across_cities1 field changedInput schema / properties / cities / descriptionPrevious value: -"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. Default: all."New value: +"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. Default: all."search_events1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Miami, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."get_event1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."list_upcoming1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."search_across_cities1 field changedInput schema / properties / cities / descriptionPrevious value: -"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. Default: all."New value: +"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. Default: all."search_events1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Cleveland, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Pittsburgh, Portland, Tokyo. list_cities has the full list."get_event1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Dallas-Fort Worth, DC, Honolulu, New York, Philadelphia, Portland. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."list_upcoming1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Dallas-Fort Worth, DC, Honolulu, New York, Philadelphia, Portland. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."search_across_cities1 field changedInput schema / properties / cities / descriptionPrevious value: -"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Dallas-Fort Worth, DC, Honolulu, New York, Philadelphia, Portland. Default: all."New value: +"Only these cities (names or slugs): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. Default: all."search_events1 field changedInput schema / properties / city / descriptionPrevious value: -"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Dallas-Fort Worth, DC, Honolulu, New York, Philadelphia, Portland. list_cities has the full list."New value: +"Which city (name or slug): Boston, Chicago, Los Angeles, Orange County, Sacramento, San Diego, San Francisco, Seattle, Cancún, Dallas-Fort Worth, DC, Denver, Detroit, Honolulu, Mexico City, Nashville, New York, Philadelphia, Phoenix, Portland, Tokyo. list_cities has the full list."list_upcoming1 field changedInput schema / properties / limitAdded value: +{
+ "description": "Max rows (default 50)",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "integer"
+}get_eventlist_citieslist_upcomingsearch_across_citiessearch_eventsRead-only search of upcoming SF Bay Area events: AI/tech, dance, music, arts, food, fitness.
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
Local US events: trivia, libraries, markets and gigs, with VenuNite links and ticket handoffs.
Search upcoming public events in Israel by date, city, region or category. Read-only; no API key.
Add one secure layer between your agents and this server.
