Skip to main content
Glama

Jet Cab AMS: Amsterdam & Schiphol chauffeur

Change a booking

change_booking
Destructive

Changes an existing booking at the customer's request (date, time, address, pickup, drop-off, passengers, luggage, car, flight, notes). First call get_quote with the complete changed ride and get the customer's approval of the new price, then send the same ride fields with that quoteToken plus the bookingId and the customer's email. Requests not yet confirmed by the driver are updated at once (a request still waiting for the email confirmation is re-sent with a new link; an unpaid tour gets a new payment link). Confirmed or paid bookings are passed to Jet Cab AMS as a change request, which they confirm by email. The ride type (transfer, custom ride, tour) cannot change: cancel and book anew instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "bookingId": "<bookingId>",
      "email": "<email>",
      "quoteToken": "<quoteToken>",
      "type": "<type>",
      "car": "<car>",
      "date": "<date>",
      "time": "<time>",
      "passengers": "<passengers>"
    },
    "name": "change_booking"
  }
}

Input Schema

NameRequiredDescriptionDefault
carYesE-Class max 4, S-Class max 2, V-Class max 7 passengers.
dateYesLocal date in Europe/Amsterdam.
langNo
timeYesLocal time in Europe/Amsterdam, between 04:00 and 20:00.
typeYes
emailYesThe customer's email address used for the booking (proves it is their booking).
notesNo
flightNo
pickupNoRequired for custom rides and tours: agreed pickup address or hotel, preserved in review and confirmations.
addressNoFixed routes only: the non-airport pickup/drop-off address. The fare follows the route zone of the address (postcode first, then town name). An address whose Dutch postcode is in no fixed-route zone is refused with error code address_zone; book it as a custom ride.
dropoffNoRequired for custom rides: drop-off address.
routeIdNoFixed routes only; ids from /data/rates.json. The server reprices to the route the address belongs to.
tourIdsNoTours only; ids from /data/tours.json.
bookingIdYesThe bookingId returned by request_booking.
directionNoFixed routes only: to or from Schiphol.
meetGreetNoOptional €25 arrivals-area name card; only for direction=from.
driverNameNo
passengersYes
quoteTokenYesSigned token returned by POST /api/quote. Send unchanged only after the customer approves that quote's total and deposit. It binds the normalized journey, vehicle, passengers, options, fare, rules version and 15-minute expiry. HTTP 409 reviewRequired=true means obtain a new quote and renewed customer approval before retrying. Never supply your own price.
returnTripNoFixed rides only. Books the return leg as well: the opposite direction between the same address and Schiphol, with the same vehicle, passengers and luggage. It is priced as a second ride (plus the name-card fee when meetGreet is set on a return that starts at Schiphol). It must be at least one hour after the first ride, between 04:00 and 20:00, and not on a blocked date. Error codes: retour_type, retour, retour_datetime, retour_hours, retour_date_blocked, retour_order. The booking is stored as two linked bookings: the request id and `<id>-ret`.
luggageLargeNoLarge check-in suitcases. E-Class and S-Class take at most 2; more needs the V-Class (error code luggage).
luggageSmallNoPieces of hand luggage. E-Class and S-Class take at most 2; more needs the V-Class (error code luggage).
ticketServiceNoTours only: attraction ticket purchase assistance, requires 28 days' notice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructive, non-idempotent, and open-world behavior, and the description adds substantial context beyond them: quote-token binding and 15-minute expiry, 409 reviewRequired handling, immediate update for unconfirmed requests, AMS change-request handling for confirmed/paid bookings, and email confirmation. These details are consistent with 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.

Conciseness5/5

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

The description is dense but front-loaded, with each sentence covering workflow, side effects, or a hard constraint. That is appropriate for a 23-parameter mutation tool and avoids wasted prose.

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?

It covers prerequisites, side effects, and the alternative for ride-type changes, which is enough to invoke the tool correctly. With no output schema, it could say more about the response shape or returned identifiers, but the behavioral coverage is otherwise strong.

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 74% and the schema already documents many parameters, but the description adds important semantics for quoteToken (must come from get_quote after customer approval and binds the journey, fare, and expiry), bookingId/email as proof of ownership, and the requirement to send the same ride fields. It does not explain every optional parameter, but it adds meaningful meaning beyond 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 and resource ('Changes an existing booking') and enumerates the changeable fields. It also explicitly says the ride type cannot change and directs the agent to cancel and book anew, which distinguishes it from cancel_booking and request_booking.

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?

Gives an explicit sequence: first call get_quote with the complete changed ride and get customer approval, then send the same ride fields with quoteToken, bookingId, and email. It also names the alternative path for ride-type changes, leaving little to inference.

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