Search event travel: F1, MotoGP, soccer, NFL, tennis, concerts. Tickets + hotels + experiences.
Scored across 8 tools
Each tool targets a distinct resource and action: four searches cover non-overlapping inventory (events, experiences, hotels, packages), get_event_details is the single detail lookup, the two build_*_link tools are scoped to event vs package pages, and create_payment_link is the lone transactional tool. Descriptions actively disambiguate the boundaries, e.g. search_events explicitly says ticket-only inventory while packages come from search_packages.
All eight tools use a consistent snake_case verb_noun pattern (build_event_link, build_package_link, create_payment_link, get_event_details, search_events/experiences/hotels_near_event/packages). The search_* family is uniform and the build_* family parallels cleanly.
Eight tools is well-scoped for an event-and-travel booking funnel. Each tool earns its place: four distinct search domains, one detail lookup, two navigation link builders, and one payment/booking tool.
The search-to-link-to-payment funnel is fully covered, but the surface is asymmetric: get_event_details exists while there is no equivalent detail tool for packages, hotels, or experiences, and there is no way to retrieve or manage an existing booking after payment. These are minor, workable gaps given search results return rich data.
Generate a deep link to the Event Escapes event detail page. The user lands on a page where they can review ticket categories, see hotels near the venue (auto-loaded), and complete booking themselves. Optionally pass hotel_id to pin a recommended hotel at the top of the hotels-near-venue list. This does not make a reservation; it is a navigation link only. Package pages are linked by build_package_link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Event slug from search_events results. | |
| guests | No | Number of travellers as stated by the user. Optional, with no default: omit it when the number of travellers is unknown. | |
| check_in | No | Optional check-in date (YYYY-MM-DD) to pre-fill on the page. | |
| event_id | No | Event UUID from search_events results. | |
| hotel_id | No | Optional hotel ID from search_hotels_near_event. If provided, this hotel will be pinned to the top of the hotels-near-venue list on the event page. | |
| check_out | No | Optional check-out date (YYYY-MM-DD) to pre-fill on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond those flags: it describes what the user experiences on the landing page (review ticket categories, auto-loaded nearby hotels, self-booking), and clarifies that hotel_id pins a hotel at the top of the list. This is meaningful extra transparency.
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 description is four sentences, each earning its place: the purpose, the landing-page experience, the hotel_id behavior, and the explicit non-reservation caveat. It is front-loaded with the core verb and resource, then adds necessary context without 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?
For a link-generation tool with 100% schema coverage and no required parameters, the description is largely complete. It explains the outcome, the user-facing page, the optional hotel pinning, and that no reservation occurs. It does not mention the response format (the URL itself), but 'Generate a deep link' sufficiently implies the return value, and the annotations cover the safety profile.
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 is already documented in the schema. The description does repeat the hotel_id pinning behavior that the schema already states, adding little new semantic value. It does not introduce new meaning for guests, check_in, or check_out beyond what the schema provides, so the baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Generate a deep link to the Event Escapes event detail page.' It also distinguishes itself from the sibling by stating 'Package pages are linked by build_package_link,' so an agent can tell which tool handles which page type without inspecting schemas.
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 explicitly says this is a navigation link only and does not make a reservation, which tells the agent when not to use it for booking actions. It also names the alternative for package pages ('Package pages are linked by build_package_link'), giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deep link to a curated Event Escapes PACKAGE detail page (/packages/{slug}). Packages are hand-curated bundles of event tickets + hotel + experiences with savings vs DIY booking. Takes a package_id or slug returned by search_packages. This does not make a reservation: the user reviews tier, duration and guest selectors and books on the package page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Package slug from search_packages results. | |
| guests | No | Number of travellers as stated by the user. Optional, with no default. | |
| check_in | No | Optional check-in date (YYYY-MM-DD). | |
| check_out | No | Optional check-out date (YYYY-MM-DD). | |
| package_id | No | Package UUID from search_packages results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description corroborates this and adds meaningful behavior: no reservation is made and the user completes booking on the package page. It also reveals the output shape, a deep link to /packages/{slug}, which goes beyond the structured fields.
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?
Three sentences with no filler: the core action is front-loaded, followed by package context, data source, and the key non-reservation caveat. Nothing is repeated from the schema, and every sentence earns its place.
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?
This is a simple link-generator with full schema coverage and strong annotations. The description covers purpose, source of package identifiers, the either/or parameter selection, and the critical caveat that no reservation is made. An agent has everything needed to invoke it correctly.
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 the baseline is 3. The description adds useful provenance by noting that package_id or slug come from search_packages and are alternative inputs, helping the agent choose between them. The remaining optional parameters are already well-documented in the schema.
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 and resource: 'Generate a deep link to a curated Event Escapes PACKAGE detail page (/packages/{slug})'. This clearly distinguishes it from sibling tools like build_event_link and search_packages, and explicitly frames it as a link builder rather than a booking or search tool.
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?
Provides clear usage context: 'Takes a package_id or slug returned by search_packages', establishing input provenance and precedence. It also gives a strong when-not: 'This does not make a reservation: the user reviews ... and books on the package page.' It does not explicitly name alternatives like build_event_link, but the package-vs-event domain makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a booking cart and returns a secure payment URL the customer uses to pay. Locks live prices for up to 4 items (a hotel room from search_hotels_near_event, event tickets from search_events, or an experience from search_experiences, which comes back as a site link for the customer to complete) and returns an Event Escapes payment link for that exact total. Requires the customer's email, first and last name, and customer_consent: the customer's own words asking to book these items. This tool charges nothing: the customer pays on the payment page, and the card is only captured once every booking is confirmed. Returns status payment_link_ready with payment_url, or status action_required listing what is still needed (a ticket category, approval of a price change, or attendee details that some ticket suppliers require); calling again with the same items plus those fields continues the booking. Items stay in the customer's cart for 90 minutes across calls and one payment URL covers the whole cart. Each new payment URL expires the customer's previous unpaid one, and a payment URL expires after about 30 minutes. Event Escapes is the merchant of record. Requires agent_terms_accepted: true, the calling agent's acceptance of the Event Escapes AI Agent Terms (https://eventescapes.com/terms/ai-agents); every payment link is recorded with the agent, the customer's consent, the items and the total as booking evidence. Large orders also need total_confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | What to book, in order. Each item is one hotel room, one ticket line, or one experience. | |
| agent_name | No | Name of the AI assistant making the booking, e.g. 'Meta Muse' or 'Claude'. Recorded with the booking. | |
| promo_code | No | Promo code supplied by the customer, exactly as given. | |
| attendee_names | No | EVENT tickets for more than one attendee: comma-separated full names, when a previous result asked for them. | |
| customer_email | Yes | Customer's email address, exactly as the customer confirmed it. The receipt and booking confirmations are sent here. | |
| customer_phone | No | Customer's mobile in E.164 (+61..., +1...), if known. | |
| accept_new_price | No | true to accept a price change reported by a previous result, once the customer has agreed to the new total. | |
| attendee_details | No | Attendee details, when a previous result asked for them: one entry per attendee separated by ';', e.g. 'name=John Smith, dob=1985-03-04, passport=N1234567, nationality=Australia', with only the fields that result named. | |
| customer_consent | Yes | Required. The customer's own words asking to book these items (e.g. 'yes book the Marriott and 2 tickets'). | |
| residency_country | No | Customer's country of residence, if stated (hotel prices vary by residency). | |
| customer_last_name | Yes | Lead traveller's last name. | |
| total_confirmation | No | Only when a previous result asked for it (large orders): the customer's own words confirming the stated total. | |
| customer_first_name | Yes | Lead traveller's first name. | |
| agent_terms_accepted | Yes | Required, must be true: the calling agent accepts the Event Escapes AI Agent Terms (https://eventescapes.com/terms/ai-agents) and confirms it acts on this customer's instruction. | |
| details_confirm_quote | No | Required when attendee_details includes a passport or date of birth: the customer's confirmation that the details are correct, given after being told they cannot be changed later. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a destructive, non-idempotent, open-world write, and the description layers on substantial extra behavior: no charge at creation, card captured only after confirmation, 90-minute cart retention, ~30-minute URL expiry, new URLs invalidating previous unpaid ones, merchant of record, and recorded booking evidence. It also explains the action_required stall states.
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?
Long but dense and front-loaded: the outcome, the charge behavior, and the required inputs come first, followed by expiry/retry mechanics. Nearly every sentence carries operative detail, though the merchant-of-record and evidence sentences could be trimmed.
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, the description carries the return burden and does so by naming both statuses (payment_link_ready with payment_url, action_required with missing fields). Combined with the retry and expiry semantics, an agent has everything needed to invoke and recover from this call.
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 the baseline is 3; the description nonetheless adds meaning beyond the schema by tying items to their source tools, clarifying that customer_consent must be the customer's own words, and explaining that total_confirmation is only needed for large orders.
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 and resource ('Creates a booking cart and returns a secure payment URL') and immediately clarifies this tool does not charge. It is clearly distinguishable from the sibling search_* and build_* tools without opening the 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 names where items come from (search_hotels_near_event, search_events, search_experiences) and describes the required prerequisite consent artifacts. It also covers the continuation path ('calling again with the same items plus those fields continues the booking') so an agent knows how to handle an incomplete first call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for one event: title, venue, date and time, price range, description, and image gallery. Provide event_id (UUID) or slug from search_events results.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| currency | No | ||
| event_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which cover safety and side effects. The description adds value by disclosing what return fields the tool provides, which is not in annotations. It doesn't contradict annotations, and while it doesn't discuss error behavior, the read-only nature and idempotency reduce the need. The added return-content detail goes beyond annotations, so a 4 is appropriate.
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 description is two sentences, front-loaded with the core action and data scope, immediately followed by identifier instructions. Every word earns its place—no filler, no repetition of the title or annotations. This is an exemplary concise structure.
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, the description compensates by listing the key return fields (title, venue, date/time, price range, description, image gallery), which sets expectations for the response. It also clarifies the required identifiers. It doesn't cover currency or potential errors, but for a simple read-only lookup with strong annotations, the description is largely complete. A 4 reflects the minor 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 0% (no descriptions on properties), so the description carries the burden. It explains event_id and slug, including that they are alternatives (via 'or') and that slug comes from search_events, which is helpful. However, it entirely omits the 'currency' parameter, which is part of the schema with an enum. This partial coverage leaves a clear gap, so a 3 is fair.
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 clearly states the tool's purpose: 'Get full details for one event' and enumerates the specific fields returned (title, venue, date/time, price range, description, image gallery). This differentiates it from sibling tools like search_events (which lists events) and build_event_link (which builds links). The verb 'get' plus the resource 'full details for one event' make a specific and unambiguous purpose.
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 explicitly instructs to provide either event_id (UUID) or slug from search_events results, giving clear context on how to obtain valid inputs. It doesn't explicitly state when not to use this tool or name alternatives, but the guidance 'from search_events results' implies a workflow and distinguishes from searching. This is clear context without formal exclusions, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search upcoming sporting and music events bookable on Event Escapes. Covers F1, MotoGP, all major soccer leagues, NFL, NHL, MLB, NBA, tennis Grand Slams, rugby, cricket, golf, volleyball, boxing, MMA, horse racing, athletics, and major concerts. Filter by sport, city, country, or date range. Returns event inventory (tickets only); curated trip packages bundling tickets, hotel and experiences are returned by search_packages. Prices are estimates; the final price is set at checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| sport | No | ||
| country | No | ||
| date_to | No | ||
| currency | No | ||
| date_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context: results are 'upcoming' (time-bounded), returns only ticket inventory, and prices are estimates subject to change at checkout. This goes beyond what annotations provide, though it does not describe pagination or ordering 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 description is compact yet comprehensive, covering purpose, coverage, filters, return type, alternative, and a pricing caveat in a few sentences. It is front-loaded with the core purpose and well-organized, though slightly long for a tool description.
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, the description explains what is returned (event inventory, tickets only) and flags the price uncertainty. It also points to search_packages for fuller packages. Missing details like pagination or default limit are minor given the tool's simplicity and the presence of limit in the schema. It is sufficiently complete for an agent to call it correctly.
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 0%, so the description must compensate. It names the filter dimensions (sport, city, country, date range), which covers most parameters, but omits limit and currency. It does not explain the meaning of each parameter individually, leaving those two to the schema alone. The high-level filter mention is helpful but not exhaustive.
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 clearly states the tool searches upcoming sporting and music events bookable on Event Escapes. It enumerates the sports covered and explicitly differentiates from search_packages by noting this returns tickets only while packages are handled elsewhere. This distinguishes it from siblings like get_event_details and search_experiences.
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 gives direct guidance on when to use this tool (for tickets) and explicitly names search_packages as the alternative for curated packages. It also mentions filters and the estimate-vs-final-price caveat. It does not mention other siblings like search_experiences or search_hotels_near_event, but the primary alternative is covered clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find activities, tours, attractions, food experiences, and nightlife in a city (sourced from Hotelbeds). If no date range provided, defaults to next 7 days. Returns activity name, price, duration, image, and whether free cancellation is offered.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| limit | No | ||
| country | No | ||
| date_to | No | ||
| category | No | ||
| currency | No | ||
| date_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context: the default 7-day date window and the specific return fields (name, price, duration, image, free cancellation). This enriches the agent's understanding beyond the annotations.
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 description is three sentences, each adding distinct value: purpose, default behavior, and return data. No redundant or filler content; it is front-loaded and efficient.
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?
Without an output schema, the description compensates by listing return fields. It also explains the data source and default date logic. Remaining gaps (like parameter interplay) are minor given the schema provides formats and defaults, making the overall description sufficiently complete for the tool's complexity.
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?
With 0% schema description coverage, the description carries the burden of explaining parameters. It clarifies that 'city' is the target, indirectly maps categories (tours, attractions, food, nightlife) to the category enum, and explains the date-range default. However, it does not explain limit, country, or currency, leaving some parameters underspecified.
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 opens with 'Find activities, tours, attractions, food experiences, and nightlife in a city (sourced from Hotelbeds)', which clearly states the action and resource. This distinguishes it from sibling tools like search_events or search_hotels_near_event which focus on different domains.
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 clearly indicates this is for searching city-based experiences and notes the default date range behavior. While it doesn't explicitly name alternatives or exclusions, the scope is well-defined enough for an agent to infer when to use this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find hotels within walking or short-transit distance of an event venue. If no check_in/check_out provided, defaults to one night before through one night after the event (2-night stay). Returns nightly price, total cost, distance, transport mode (walk vs rideshare), and travel time to venue.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| limit | No | ||
| guests | No | ||
| check_in | No | ||
| currency | No | ||
| event_id | No | ||
| check_out | No | ||
| radius_km | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context beyond that: it explains the automatic 2-night stay default when no dates are provided and enumerates the specific return fields (nightly price, total cost, distance, transport mode, travel time). This exceeds annotation-only information, though it omits details like pagination or rate limits.
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 description is two sentences, front-loaded with the primary purpose, and includes essential behavioral and output information without redundant wording. Every clause adds value.
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?
Given 8 parameters and no output schema, the description covers the core purpose and return fields, making it adequate. However, it leaves many parameter meanings and usage exclusions unaddressed, so the agent still has to infer significant details. This is a clear gap for a tool of this complexity.
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?
With 0% schema description coverage and 8 parameters, the description must compensate. It explains the check_in/check_out default behavior and implies a radius via 'walking or short-transit distance', but it fails to explain event_id/slug, limit, guests, currency, and radius_km. This leaves most parameters semantically opaque to the agent.
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 uses the specific verb 'Find' and clearly identifies the resource as 'hotels near event venue'. It also specifies the scope (walking or short-transit distance) and lists the return fields, which distinguishes it from sibling tools like search_events or search_packages.
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 clearly implies when to use this tool—when hotel accommodations near an event are needed. It does not explicitly name alternatives or provide exclusions, but it provides clear context about default date behavior and output, which helps an agent decide on invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search hand-curated trip packages bundling event tickets + hotel + experiences with savings vs DIY booking. Packages live on dedicated /packages/ pages and include preview hotel, ticket category, and (sometimes) experience list. Filter by category (concerts, f1, world_cup, tennis, nfl, etc.), city, country, date range, or package type (single_event for one-day events; multi_event_city for multi-day city trips with multiple events). Returns complete trip recommendations; ticket-only inventory is returned by search_events. Prices include all package components.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter by destination city (e.g. 'London', 'New York'). | |
| limit | No | ||
| country | No | Filter by destination country name (e.g. 'England', 'USA', 'Spain'). Note: packages use country name, not ISO code. | |
| date_to | No | ||
| category | No | Package category. Common values: concerts (1000+ packages), f1 (Formula 1 race weekends), world_cup (FIFA World Cup 2026), tennis (Grand Slams), nfl, mlb, nba, nhl, epl/la_liga/serie_a/bundesliga (soccer leagues), city_multi (multi-event city trips), festivals. | |
| currency | No | ||
| date_from | No | ||
| package_type | No | single_event (one event) or multi_event_city (multiple events in one city trip). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context, such as that packages are hand-curated, live on dedicated /packages/ pages, include a preview hotel and ticket category, and that prices include all components. It also clarifies that results are 'complete trip recommendations'. This goes beyond the annotations without contradicting them.
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 description is a single dense paragraph that is front-loaded with the core purpose, then lists filters, and closes with a distinction from a sibling. It packs a lot of information without being verbose or repetitive. A slight improvement would be splitting into bullet points, but it is well-structured and efficient.
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?
Given the tool has 8 parameters, no output schema, and annotations that already cover safety, the description provides enough context for an agent to call it correctly: it explains what results look like ('complete trip recommendations'), that prices are inclusive, and routes ticket-only queries elsewhere. Missing details like pagination or return format are minor given the absence of an output schema and the tool's read-only nature.
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 50%; the schema describes city, country, category, and package_type, while the description adds context for date range and package type. However, the description does not clarify the semantics of limit (e.g., pagination or maximum results) or currency (e.g., conversion or display options). It adds some value but does not fully compensate for the uncovered parameters, so it meets the baseline of adequacy but not more.
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 states a specific verb ('Search') and a clear resource ('hand-curated trip packages bundling event tickets + hotel + experiences'), with a distinct value proposition ('savings vs DIY booking'). It explicitly differentiates from a sibling tool ('ticket-only inventory is returned by search_events'), making it immediately clear what this tool is for and not for.
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 explicitly names the alternative (search_events) and the condition that selects it ('ticket-only inventory'), which is a clear when-not-to-use directive. It also lists the available filters (category, city, country, date range, package type) with examples, providing practical guidance on when to invoke this tool. This is explicit and leaves no ambiguity.
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.
create_payment_link1 field changedInput schema / properties / promo_code / descriptionPrevious value: -"Not accepted at the moment: the link is created at full price and the customer can enter a code themselves at the website checkout."New value: +"Promo code supplied by the customer, exactly as given."create_payment_link1 field changedInput schema / properties / promo_code / descriptionPrevious value: -"Promo code supplied by the customer, exactly as given."New value: +"Not accepted at the moment: the link is created at full price and the customer can enter a code themselves at the website checkout."create_payment_link4 fields changedInput schema / properties / agent_nameAdded value: +{
+ "description": "Name of the AI assistant making the booking, e.g. 'Meta Muse' or 'Claude'. Recorded with the booking.",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / agent_terms_acceptedAdded value: +{
+ "description": "Required, must be true: the calling agent accepts the Event Escapes AI Agent Terms (https://eventescapes.com/terms/ai-agents) and confirms it acts on this customer's instruction.",
+ "type": "boolean"
+}Input schema / properties / total_confirmationAdded value: +{
+ "description": "Only when a previous result asked for it (large orders): the customer's own words confirming the stated total.",
+ "maxLength": 300,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "customer_email",
- "customer_first_name",
- "customer_last_name",
- "customer_consent",
- "items"
-]New value: +[
+ "customer_email",
+ "customer_first_name",
+ "customer_last_name",
+ "customer_consent",
+ "items",
+ "agent_terms_accepted"
+]build_event_link1 field changedInput schema / properties / guests / descriptionPrevious value: -"Number of travellers. ASK THE USER before passing this - do not assume a default. Only include if the user has explicitly stated how many people are travelling."New value: +"Number of travellers as stated by the user. Optional, with no default: omit it when the number of travellers is unknown."build_package_link1 field changedInput schema / properties / guests / descriptionPrevious value: -"Number of travellers. ASK THE USER before passing this - do not assume a default."New value: +"Number of travellers as stated by the user. Optional, with no default."create_payment_link14 fields changedInput schema / properties / accept_new_price / descriptionPrevious value: -"true only after the tool reported a price change AND the customer agreed to the new total."New value: +"true to accept a price change reported by a previous result, once the customer has agreed to the new total."Input schema / properties / attendee_details / descriptionPrevious value: -"Only when the tool asks: one entry per attendee separated by ';', e.g. 'name=John Smith, dob=1985-03-04, passport=N1234567, nationality=Australia'. Include only the fields the tool asked for."New value: +"Attendee details, when a previous result asked for them: one entry per attendee separated by ';', e.g. 'name=John Smith, dob=1985-03-04, passport=N1234567, nationality=Australia', with only the fields that result named."Input schema / properties / attendee_names / descriptionPrevious value: -"EVENT tickets for more than one attendee: comma-separated full names. The tool tells you if needed."New value: +"EVENT tickets for more than one attendee: comma-separated full names, when a previous result asked for them."Input schema / properties / customer_consent / descriptionPrevious value: -"REQUIRED. The customer's own words asking you to book these items (e.g. 'yes book the Marriott and 2 tickets')."New value: +"Required. The customer's own words asking to book these items (e.g. 'yes book the Marriott and 2 tickets')."Input schema / properties / customer_email / descriptionPrevious value: -"Customer's email, confirmed back to them letter-perfect. Receipt and confirmations go here."New value: +"Customer's email address, exactly as the customer confirmed it. The receipt and booking confirmations are sent here."Input schema / properties / details_confirm_quote / descriptionPrevious value: -"Required when attendee_details carries passport or date of birth: the customer's confirmation after you read the details back and warned they cannot be changed."New value: +"Required when attendee_details includes a passport or date of birth: the customer's confirmation that the details are correct, given after being told they cannot be changed later."Input schema / properties / items / items / properties / breakfast / descriptionPrevious value: -"HOTEL: true only if the customer asked for breakfast included."New value: +"HOTEL: true for a rate with breakfast included."Input schema / properties / items / items / properties / check_in / descriptionPrevious value: -"HOTEL: YYYY-MM-DD, the customer's date."New value: +"HOTEL: check-in date, YYYY-MM-DD."Input schema / properties / items / items / properties / check_out / descriptionPrevious value: -"HOTEL: YYYY-MM-DD."New value: +"HOTEL: check-out date, YYYY-MM-DD."Input schema / properties / items / items / properties / modality_code / descriptionPrevious value: -"EXPERIENCE: option code if the tool listed options."New value: +"EXPERIENCE: option code, when a previous result listed options."Input schema / properties / items / items / properties / quantity / descriptionPrevious value: -"EVENT: number of tickets. Ask the customer, never assume."New value: +"EVENT: number of tickets the customer wants."Input schema / properties / items / items / properties / session_code / descriptionPrevious value: -"EXPERIENCE: time slot code if the tool listed options."New value: +"EXPERIENCE: time slot code, when a previous result listed options."Input schema / properties / items / items / properties / ticket_id / descriptionPrevious value: -"EVENT: ticket category id. Omit to have the tool list the options."New value: +"EVENT: ticket category id. When omitted, the result lists the available categories."Input schema / properties / promo_code / descriptionPrevious value: -"Promo code only if the customer gave one, exactly as typed."New value: +"Promo code supplied by the customer, exactly as given."create_payment_linkbuild_event_linkbuild_package_linkget_event_detailssearch_eventssearch_experiencessearch_hotels_near_eventsearch_packagesSearch tours, attraction tickets, and holiday packages across 24 countries.
Search & compare prices for tours, activities and tickets across multiple providers.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Search and price Japan tours, tickets, ryokan, transfers, charter buses, helicopters, golf and eSIM.
Add one secure layer between your agents and this server.
