Skip to main content
Glama

Event Escapes

by com.eventescapes
OverviewDiscussionsAdmin

create_payment_link

Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesWhat to book, in order. Each item is one hotel room, one ticket line, or one experience.
agent_nameNoName of the AI assistant making the booking, e.g. 'Meta Muse' or 'Claude'. Recorded with the booking.
promo_codeNoPromo code supplied by the customer, exactly as given.
attendee_namesNoEVENT tickets for more than one attendee: comma-separated full names, when a previous result asked for them.
customer_emailYesCustomer's email address, exactly as the customer confirmed it. The receipt and booking confirmations are sent here.
customer_phoneNoCustomer's mobile in E.164 (+61..., +1...), if known.
accept_new_priceNotrue to accept a price change reported by a previous result, once the customer has agreed to the new total.
attendee_detailsNoAttendee 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_consentYesRequired. The customer's own words asking to book these items (e.g. 'yes book the Marriott and 2 tickets').
residency_countryNoCustomer's country of residence, if stated (hotel prices vary by residency).
customer_last_nameYesLead traveller's last name.
total_confirmationNoOnly when a previous result asked for it (large orders): the customer's own words confirming the stated total.
customer_first_nameYesLead traveller's first name.
agent_terms_acceptedYesRequired, 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_quoteNoRequired 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / promo_code / description
      Previous 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / promo_code / description
      Previous 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."
  3. Changed4 schema fields changed
    • addedInput schema / properties / agent_name
      Added value: +{
+  "description": "Name of the AI assistant making the booking, e.g. 'Meta Muse' or 'Claude'. Recorded with the booking.",
+  "maxLength": 80,
+  "type": "string"
+}
    • addedInput schema / properties / agent_terms_accepted
      Added 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"
+}
    • addedInput schema / properties / total_confirmation
      Added 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"
+}
    • changedInput schema / required
      Previous 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"
+]
  4. Changed14 schema fields changed
    • changedInput schema / properties / accept_new_price / description
      Previous 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."
    • changedInput schema / properties / attendee_details / description
      Previous 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."
    • changedInput schema / properties / attendee_names / description
      Previous 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."
    • changedInput schema / properties / customer_consent / description
      Previous 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')."
    • changedInput schema / properties / customer_email / description
      Previous 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."
    • changedInput schema / properties / details_confirm_quote / description
      Previous 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."
    • changedInput schema / properties / items / items / properties / breakfast / description
      Previous value: -"HOTEL: true only if the customer asked for breakfast included."New value: +"HOTEL: true for a rate with breakfast included."
    • changedInput schema / properties / items / items / properties / check_in / description
      Previous value: -"HOTEL: YYYY-MM-DD, the customer's date."New value: +"HOTEL: check-in date, YYYY-MM-DD."
    • changedInput schema / properties / items / items / properties / check_out / description
      Previous value: -"HOTEL: YYYY-MM-DD."New value: +"HOTEL: check-out date, YYYY-MM-DD."
    • changedInput schema / properties / items / items / properties / modality_code / description
      Previous value: -"EXPERIENCE: option code if the tool listed options."New value: +"EXPERIENCE: option code, when a previous result listed options."
    • changedInput schema / properties / items / items / properties / quantity / description
      Previous value: -"EVENT: number of tickets. Ask the customer, never assume."New value: +"EVENT: number of tickets the customer wants."
    • changedInput schema / properties / items / items / properties / session_code / description
      Previous value: -"EXPERIENCE: time slot code if the tool listed options."New value: +"EXPERIENCE: time slot code, when a previous result listed options."
    • changedInput schema / properties / items / items / properties / ticket_id / description
      Previous 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."
    • changedInput schema / properties / promo_code / description
      Previous value: -"Promo code only if the customer gave one, exactly as typed."New value: +"Promo code supplied by the customer, exactly as given."
  5. Added

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/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 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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Event Escapes toolsInspect
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