travel

search_events

Read-onlyIdempotent

Searches concerts, sports, theater, comedy and other live events in a city from a start date, from our ticketing partners, with an optional end date, category (music, sports, arts, theater, family, comedy) and keyword such as an artist, team or show. Results include venue, date and time, price range and, where the source gives one, a link to the event page. Searching does not reserve anything or charge anyone.

Input Schema

Name	Required	Description
`city`	Yes
`place`	No	The exact place of this trip stop: the `place` an earlier search for the trip returned, or the candidate the person picked when a search asked which place they meant. Searches given the same place cover the same place.
`airport`	No	Optional three-letter IATA code of the airport the person flies into, when known. Only used to tell same-named cities apart.
`country`	No	Optional ISO 3166 two-letter country code of the city (for example FR), when known. Tells same-named cities apart.
`date_to`	No
`keyword`	No
`category`	No
`date_from`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 19, 2026

addedInput schema / properties / place / properties / arrival_airports

Added value: +{
+  "description": "The airports to fly this place by, best first, as a search returned them. Pass them back unchanged.",
+  "items": {
+    "properties": {
+      "iata": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "iata"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedInput schema / properties / place / properties / extent_km

Added value: +{
+  "description": "The size of a region or island, as a search returned it.",
+  "type": "number"
+}

addedInput schema / properties / place / properties / gateway_airport

Added value: +{
+  "description": "The one airport a wide search flies this place by, as a search returned it.",
+  "type": "string"
+}

addedInput schema / properties / place / properties / kind

Added value: +{
+  "description": "What the place is, as a search returned it. Pass it back unchanged: a town, region or island has its hotels searched around it.",
+  "enum": [
+    "city",
+    "town",
+    "region",
+    "island"
+  ],
+  "type": "string"
+}

addedInput schema / properties / place / properties / radius_km

Added value: +{
+  "description": "The hotel search radius for this place, as a search returned it.",
+  "type": "number"
+}

Changed1 schema field changedOct 15, 2026

addedInput schema / properties / place

Added value: +{
+  "description": "The exact place of this trip stop: the `place` an earlier search for the trip returned, or the candidate the person picked when a search asked which place they meant. Searches given the same place cover the same place.",
+  "properties": {
+    "airports": {
+      "description": "IATA codes of the airports serving the place.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "city": {
+      "type": "string"
+    },
+    "country": {
+      "description": "ISO 3166-1 alpha-2 code (territories use their own, e.g. PR).",
+      "type": "string"
+    },
+    "label": {
+      "description": "How to name the place to the person, e.g. 'Birmingham, GB'.",
+      "type": "string"
+    },
+    "latitude": {
+      "type": "number"
+    },
+    "longitude": {
+      "type": "number"
+    },
+    "region": {
+      "description": "State or region, or empty.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "country",
+    "latitude",
+    "longitude"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 14, 2026

addedInput schema / properties / airport

Added value: +{
+  "description": "Optional three-letter IATA code of the airport the person flies into, when known. Only used to tell same-named cities apart.",
+  "type": "string"
+}

addedInput schema / properties / country

Added value: +{
+  "description": "Optional ISO 3166 two-letter country code of the city (for example FR), when known. Tells same-named cities apart.",
+  "type": "string"
+}

First observedMay 11, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description only needs to add context — and it does: results come from ticketing partners, include venue, date/time, price range and sometimes an event link, and no reservation or charge occurs. It does not disclose result limits or pagination, which is the remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the verb and resource before the optional filters and the return-content summary. The closing non-reservation sentence is short and load-bearing in a booking-oriented tool set; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates what a result contains (venue, date and time, price range, event link when available), which an agent otherwise could not know. Combined with the safety statement and filter coverage, it is nearly complete; only result volume/pagination behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 38%, and the description compensates well for the undocumented fields: date_from is framed as the start date, date_to as an optional end date, keyword as 'an artist, team or show', and category is given an explicit value list (music, sports, arts, theater, family, comedy) that the schema itself lacks entirely. The remaining parameters (place, airport, country) carry their own rich schema descriptions, so little is left ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (searches) and a clearly bounded resource (concerts, sports, theater, comedy and other live events in a city from a start date), plus the data source (ticketing partners). An agent can distinguish this from search_hotels, search_flights, search_dining and search_activities 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is explicit: a city plus a start date, with optional end date, category and keyword for narrowing. It also closes the loop on a common agent question by stating that searching neither reserves nor charges, implying the booking tools are a separate step. It stops short of naming a sibling (e.g. search_activities) or stating exclusions, so no explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All travel tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?