booking

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

Name	Required	Description	Default
`bags`	No	Number of bags (used for vehicle sizing when combo transfer).
`email`	Yes	Client email — used for booking confirmation and Stripe receipt.
`phone`	Yes	Client phone with country code.
`adults`	Yes	Number of adults (min 1).
`channel`	No	Caller channel identifier for observability (whatsapp, chatbot, mcp-direct, ...).
`children`	No	Number of children (in addition to adults).
`location`	Yes	M&G location. cdg/orly = airport, gare_de_lyon = train station. Gare du Nord is no longer available.
`terminal`	No	Terminal number (airports only, e.g. '2E', '3').
`transfer`	No	Optional combo: bundles a private transfer in the same Stripe Checkout session. Generates 2 line items + 2 Zeplan bookings (M&G + transfer).
`last_name`	Yes	Client last name.
`train_pnr`	No	TGV reservation reference (PNR). Required when location is gare_de_lyon.
`first_name`	Yes	Client first name.
`train_seat`	No	Train seat number(s). Required for train stations.
`pickup_date`	Yes	YYYY-MM-DD format.
`pickup_time`	Yes	HH:MM in Paris time. For arrivals this is the flight/train arrival time; for departures the time the greeter meets the client.
`train_coach`	No	Train coach number. Required for train stations.
`service_type`	No	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).	arrival
`flight_number`	Yes	Flight number for airports (AF1234) or train/Eurostar number for stations.
`manual_origin`	No	Required if flight_unverified=true. Departure city as stated by the client.
`manual_airline`	No	Required if flight_unverified=true. The airline name as stated by the client.
`additional_info`	No	Free-text notes (special requests, tail number for private aviation, etc.).
`idempotency_key`	No	Optional UUID for safe retries. Same key returns the same payment_url for 24h.
`flight_unverified`	No	Set true only if the client confirmed the flight after AeroDataBox couldn't validate it. Requires manual_airline + manual_origin.
`lead_time_override`	No	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.
`manual_arrival_time`	No	Optional. Local arrival time as stated by the client.

TDQS

A4.9/5.0

Behavior5/5

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

Even though annotations already indicate this is a non-read-only, non-destructive mutation, the description goes far beyond by disclosing error codes (LEAD_TIME_TOO_SHORT, FLIGHT_NOT_FOUND), fixed pricing rules, the 12-hour lead time with override conditions (requiring explicit admin approval), and the 90-minute hard floor. This is directly useful behavioral context not available in annotations.

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?

The description is a single dense block but every sentence carries essential operational information. It is front-loaded with the core purpose. The lack of bullet points or section breaks makes it harder to digest quickly, but given the complexity (25 params, nested objects), this level of detail is justified.

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?

Given the tool's complexity (25 params, nested transfer object, multiple error modes, pricing rules), the description covers all critical aspects: location availability, pricing, connection billing, transfer combo flow, lead time handling, override conditions, and flight validation failure. There is no output schema, but the description still communicates return error codes, which is sufficient for successful invocation.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds crucial meaning beyond the schema: pricing formulas for M&G and connections, how transfer combos should be built (get_quote first, pass quote_id and vehicle_id), the semantics of pickup_time for departures, and the approval requirement for lead_time_override. This materially improves parameter understanding.

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?

The description opens with a specific action and resource: 'Create a secure payment link for a VIP Meet & Greet booking, with optional transfer combo.' It clearly distinguishes this from siblings like book_ride and get_quote by stating the purpose (booking M&G) and the optional combo. The scope (locations, exclusions) is also explicit.

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?

The description provides extensive when-to-use guidance: available locations, explicit exclusion of Gare du Nord, instruction to avoid get_quote for M&G, procedure for connection and transfer combos, and fallback behavior for lead time or flight validation errors. It clearly names alternatives (get_quote) and when to use them.

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

All booking tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: booking a ride, booking a meet & greet, getting a quote, listing vehicles, resolving flights/trains/locations, sending contact, etc. No two tools overlap in purpose or could be easily confused.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern, with verbs like 'book_', 'get_', 'resolve_', and 'send_' clearly indicating the action. There are no exceptions or mixed conventions.

Tool Count5/5

10 tools is well within the ideal 3-15 range and perfectly scoped for a chauffeur booking service. Each tool covers a necessary part of the workflow (quote, booking, location/flight/train resolution, vehicle info, policy, contact).

Completeness4/5

The core booking flow is well covered: resolve location/flight/train → get quote → book ride or meet & greet → send driver contact. However, there is no tool to cancel, update, or check the status of a booking, which requires external (Zeplan) access. This is a minor gap but workable for typical agent flows.

Resources

Need Help?