Skip to main content
Glama

book_meetgreet

Create a secure payment link for a VIP Meet & Greet booking, with optional transfer combo. Available locations: CDG, Orly, Gare de Lyon — Meet & Greet is NO LONGER offered at Gare du Nord (do not quote or book it there). M&G prices are FIXED (CDG/Orly 250€ base for 2 pax + 50€/extra, Gare de Lyon 350€ + 75€/extra) — do NOT call get_quote for the M&G part. Some event dates carry a supplement (e.g. Paris Air Show): the mg_price returned here is the amount actually charged for pickup_date. A connection (service_type='connection': arrival flight → connecting departure flight with fast-track between terminals) is billed as TWO M&G services = the location price ×2 (e.g. CDG 2 pax = 500€). For a combo with a transfer (e.g. CDG M&G + transfer to a hotel), call get_quote first for the transfer leg and pass the resulting quote_id + vehicle_id in transfer. If lead time is below the minimum (12h before pickup), returns LEAD_TIME_TOO_SHORT — the caller must fall back to manual notification instead of retrying. lead_time_override=true bypasses the 12h minimum ONLY after Sylvain has explicitly confirmed greeter availability for this exact request (WhatsApp admin approval 'mg ok'); never set it on your own initiative. A 90-minute floor always applies. If flight cannot be validated, returns FLIGHT_NOT_FOUND — ask the customer to re-confirm the flight number, or set flight_unverified=true with manual_airline + manual_origin to force-accept.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bagsNoNumber of bags (used for vehicle sizing when combo transfer).
emailYesClient email — used for booking confirmation and Stripe receipt.
phoneYesClient phone with country code.
adultsYesNumber of adults (min 1).
channelNoCaller channel identifier for observability (whatsapp, chatbot, mcp-direct, ...).
childrenNoNumber of children (in addition to adults).
locationYesM&G location. cdg/orly = airport, gare_de_lyon = train station. Gare du Nord is no longer available.
terminalNoTerminal number (airports only, e.g. '2E', '3').
transferNoOptional combo: bundles a private transfer in the same Stripe Checkout session. Generates 2 line items + 2 Zeplan bookings (M&G + transfer).
last_nameYesClient last name.
train_pnrNoTGV reservation reference (PNR). Required when location is gare_de_lyon.
first_nameYesClient first name.
train_seatNoTrain seat number(s). Required for train stations.
pickup_dateYesYYYY-MM-DD format.
pickup_timeYesHH:MM in Paris time. For arrivals this is the flight/train arrival time; for departures the time the greeter meets the client.
train_coachNoTrain coach number. Required for train stations.
service_typeNoarrival (pickup at airport/station), departure (drop-off + greeter for check-in), connection (transit: arrival flight → connecting departure flight; billed as 2 M&G services = location price ×2).arrival
flight_numberYesFlight number for airports (AF1234) or train/Eurostar number for stations.
manual_originNoRequired if flight_unverified=true. Departure city as stated by the client.
manual_airlineNoRequired if flight_unverified=true. The airline name as stated by the client.
additional_infoNoFree-text notes (special requests, tail number for private aviation, etc.).
idempotency_keyNoOptional UUID for safe retries. Same key returns the same payment_url for 24h.
flight_unverifiedNoSet true only if the client confirmed the flight after AeroDataBox couldn't validate it. Requires manual_airline + manual_origin.
lead_time_overrideNoBypass the 12h minimum lead time. ONLY when Sylvain has explicitly approved this exact booking after manually confirming greeter availability ('mg ok' admin flow) — never on client insistence. Hard 90-minute floor.
manual_arrival_timeNoOptional. Local arrival time as stated by the client.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / transfer / properties / transfer_pickup_time / description
      Previous value: -"HH:MM — time the chauffeur picks up the client AFTER the greeter has escorted them out. Usually 30-60min after the greeter_time (pickup_time)."New value: +"HH:MM — for an ARRIVAL: the scheduled landing time, same as the greeter time (pickup_time); the chauffeur waits for the greeter to bring the client out (waiting included). For a DEPARTURE: the car pickup time at the client's address, before the greeter time at the airport."
  2. Changed4 schema fields changed
    • changedInput schema / properties / lead_time_override / description
      Previous value: -"Bypass the 12h minimum lead time. ONLY when Sylvain has explicitly approved this exact booking after manually confirming greeter availability ('mg ok' admin flow) — never on client insistence. Refused for gare_du_nord; hard 90-minute floor."New value: +"Bypass the 12h minimum lead time. ONLY when Sylvain has explicitly approved this exact booking after manually confirming greeter availability ('mg ok' admin flow) — never on client insistence. Hard 90-minute floor."
    • changedInput schema / properties / location / description
      Previous value: -"M&G location. cdg/orly = airport, gare_du_nord/gare_de_lyon = train station."New value: +"M&G location. cdg/orly = airport, gare_de_lyon = train station. Gare du Nord is no longer available."
    • changedInput schema / properties / location / enum
      Previous value: -[
      -  "cdg",
      -  "orly",
      -  "gare_du_nord",
      -  "gare_de_lyon"
      -]New value: +[
      +  "cdg",
      +  "orly",
      +  "gare_de_lyon"
      +]
    • changedInput schema / properties / train_pnr / description
      Previous value: -"Eurostar / TGV reservation reference (PNR). Required when location is gare_du_nord or gare_de_lyon."New value: +"TGV reservation reference (PNR). Required when location is gare_de_lyon."
  3. Changed1 schema field changed
    • addedInput schema / properties / lead_time_override
      Added value: +{
      +  "description": "Bypass the 12h minimum lead time. ONLY when Sylvain has explicitly approved this exact booking after manually confirming greeter availability ('mg ok' admin flow) — never on client insistence. Refused for gare_du_nord; hard 90-minute floor.",
      +  "type": "boolean"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / service_type / description
      Previous value: -"arrival (pickup at airport/station), departure (drop-off + greeter for check-in), connection (transit)."New value: +"arrival (pickup at airport/station), departure (drop-off + greeter for check-in), connection (transit: arrival flight → connecting departure flight; billed as 2 M&G services = location price ×2)."
  5. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond annotations by disclosing fixed pricing tiers, event-date supplements, connection billing (×2), the 12h minimum with a hard 90-minute floor, the LEAD_TIME_TOO_SHORT and FLIGHT_NOT_FOUND error behaviors, and the admin-approval gate on lead_time_override. Annotations only cover the safety profile, so this added operational context is genuinely valuable.

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?

Dense single paragraph, front-loaded with purpose and pricing before routing and error handling. Every sentence carries operational information — no filler or restated field names.

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?

For a 25-parameter mutation tool with nested objects and no output schema, the description covers pricing, location exclusions, error codes, fallbacks, retry/idempotency implications, and override governance. Nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the connection service_type is billed as two services, the transfer object requires a prior get_quote quote_id/vehicle_id, and lead_time_override's precondition is spelled out. Only the pickup_time arrival/departure distinction is already fully covered by the schema.

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+resource+artifact: 'Create a secure payment link for a VIP Meet & Greet booking, with optional transfer combo.' It distinguishes itself from siblings by explicitly telling the agent not to call get_quote for the M&G leg, only for the transfer leg.

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?

Rich routing guidance: when to use get_quote (transfer combo only), which locations are valid vs forbidden (Gare du Nord no longer offered), when lead_time_override is permissible, and the exact fallback when the 12h minimum is unmet. Alternatives and preconditions are stated explicitly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources