Skip to main content
Glama

Feminiq Rides: Amsterdam chauffeur (female driver)

Change a booking

change_booking
Destructive

Changes a ride request at the customer's request (date, time, address, pickup, drop-off, passengers, luggage, car, payment choice, 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. A request still waiting for the email confirmation is re-sent with a new link; a request Feminiq Rides has not confirmed yet is updated at once; a confirmed but unpaid request is withdrawn and requested anew: the customer must click the NEW Confirm link emailed to them within 24 hours, otherwise the ride is lost (she then confirms again and sends a new payment request). Needs a fresh quoteToken from get_quote for the changed ride; the quoteToken of the original request cannot be reused. Paid bookings are passed to Feminiq Rides as a change request, which she confirms by email. The ride type (transfer, ride on request, tour) cannot change: cancel and request 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
carYesBMW 5 Series Touring (bmw5) max 4 passengers, Mercedes V-Class (vclass) max 7 passengers.
dateYesLocal date in Europe/Amsterdam.
langNoLanguage of the emails the customer receives (the Confirm link, status and payment mails) and of the quote card. Use the customer's own language; default en.
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; a hotel or town named without a postcode is placed by a server-side lookup, and the selected route applies if that lookup fails). An address whose Dutch postcode is in no fixed-route zone is refused with error code address_zone; book it as a single ride.
dropoffNoRequired for custom rides: drop-off address.
paymentNoHow the customer pays once the ride is confirmed: deposit = a payment request for 25% of the price, rest on the day of the ride; full = a payment request for the full price. With a returnTrip both legs are confirmed together and paid with ONE payment request on these terms (the sum over the legs).deposit
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.
driverNameNoOptional. Name of a preferred driver, printed as "Driver: ..." in the customer's confirmation and calendar file. Leave it out unless the customer asks for a specific driver; it is not the passenger's name.
passengersYes
quoteTokenYesSigned token returned by POST /api/quote. Send unchanged only after the customer approves that quote's total and payment. It binds the normalized journey, vehicle, passengers, payment choice, return trip, 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.
returnTripNoAirport transfers (fixed) and custom rides only; tours fail with retour_type, and a value that is not an object fails with retour. Books the return leg as well, with the same vehicle, passengers and luggage: on a fixed route the opposite direction between the same address and Schiphol, priced as a second ride at the route price; on a custom ride from the drop-off back to the pickup, where the fare estimate covers both legs and is split evenly over them. The return must be at least one hour after the first ride (retour_order), between 04:00 and 20:00 (retour_hours), not on a blocked date (retour_date_blocked) and at most 2 years ahead (date_range); missing or invalid values fail with retour_date, retour_time or retour_datetime. There is no name card on either leg (meet_greet_unavailable). The request is stored as two linked bookings, bookingId and `<bookingId>-ret` (so bookingId may have at most 51 characters when a returnTrip is sent), confirmed together and paid with one payment request: 25% of the combined price of the legs, or all of it with payment=full.
luggageLargeNoLarge check-in suitcases. The BMW takes at most 3; more needs the V-Class (error code luggage).
luggageSmallNoPieces of hand luggage. The BMW takes at most 3; 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. Changed5 schema fields changed
    • changedInput schema / properties / bookingId / pattern
      Previous value: -"^[A-Za-z0-9_-]{8,80}$"New value: +"^[A-Za-z0-9_-]{8,55}$"
    • addedInput schema / properties / driverName / description
      Added value: +"Optional. Name of a preferred driver, printed as \"Driver: ...\" in the customer's confirmation and calendar file. Leave it out unless the customer asks for a specific driver; it is not the passenger's name."
    • addedInput schema / properties / lang / description
      Added value: +"Language of the emails the customer receives (the Confirm link, status and payment mails) and of the quote card. Use the customer's own language; default en."
    • changedInput schema / properties / payment / description
      Previous value: -"How the customer pays once the ride is confirmed: deposit = a payment request for 25% of the price, rest on the day of the ride; full = a payment request for the full price. With a returnTrip each leg gets its own payment request on these terms."New value: +"How the customer pays once the ride is confirmed: deposit = a payment request for 25% of the price, rest on the day of the ride; full = a payment request for the full price. With a returnTrip both legs are confirmed together and paid with ONE payment request on these terms (the sum over the legs)."
    • changedInput schema / properties / returnTrip / description
      Previous value: -"Airport transfers (fixed) and custom rides only; tours fail with retour_type, and a value that is not an object fails with retour. Books the return leg as well, with the same vehicle, passengers and luggage: on a fixed route the opposite direction between the same address and Schiphol, priced as a second ride at the route price; on a custom ride from the drop-off back to the pickup, where the fare estimate covers both legs and is split evenly over them. The return must be at least one hour after the first ride (retour_order), between 04:00 and 20:00 (retour_hours), not on a blocked date (retour_date_blocked) and at most 2 years ahead (date_range); missing or invalid values fail with retour_date, retour_time or retour_datetime. There is no name card on either leg (meet_greet_unavailable). The request is stored as two linked bookings, bookingId and `<bookingId>-ret` (so bookingId may have at most 76 characters), confirmed together and paid with one payment request: 25% of the combined price of the legs, or all of it with payment=full."New value: +"Airport transfers (fixed) and custom rides only; tours fail with retour_type, and a value that is not an object fails with retour. Books the return leg as well, with the same vehicle, passengers and luggage: on a fixed route the opposite direction between the same address and Schiphol, priced as a second ride at the route price; on a custom ride from the drop-off back to the pickup, where the fare estimate covers both legs and is split evenly over them. The return must be at least one hour after the first ride (retour_order), between 04:00 and 20:00 (retour_hours), not on a blocked date (retour_date_blocked) and at most 2 years ahead (date_range); missing or invalid values fail with retour_date, retour_time or retour_datetime. There is no name card on either leg (meet_greet_unavailable). The request is stored as two linked bookings, bookingId and `<bookingId>-ret` (so bookingId may have at most 51 characters when a returnTrip is sent), confirmed together and paid with one payment request: 25% of the combined price of the legs, or all of it with payment=full."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Goes well past the annotations by describing the three outcome branches of the state machine: pending-email requests are re-sent with a new link, unconfirmed requests are updated instantly, and confirmed-unpaid requests are withdrawn and re-requested with a 24-hour NEW Confirm link or the ride is lost. Paid bookings become a change request routed to Feminiq Rides. It does not state what the tool returns on success (booking id, status), which is a real gap given no output schema, hence 4 not 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Every sentence carries operational information, but the whole thing is one dense run-on paragraph that mixes preconditions, state-branch outcomes and the ride-type exclusion without any separation or formatting. Front-loading is decent (what it does comes first), but a reader must parse a wall of text to extract the workflow.

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?

Against a 23-parameter schema with a nested returnTrip object, no output schema and destructive/idempotent-false annotations, the description covers the quote-token lifecycle, the destructive withdrawal branch, the 24-hour confirmation deadline and the type-change exclusion. The remaining gap is the success response shape and the error paths it does not enumerate (only quote 409 is hinted at indirectly via the schema).

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 83%, so the baseline is 3; the description adds genuine constraints the schema does not enforce at the call site — the quoteToken must be freshly obtained from get_quote for the changed ride and the original request's token cannot be reused, and the 'same ride fields' must match the quoted journey. It does not add per-field meaning beyond that.

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?

Opens with a specific verb+resource ('Changes a ride request') and enumerates exactly which fields can change (date, time, address, pickup, drop-off, passengers, luggage, car, payment, flight, notes). It also draws the boundary against cancel_booking by stating the ride type cannot change and must be cancelled/re-requested instead.

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 pre-call sequence: first get_quote for the complete changed ride and obtain customer price approval, then send the same fields plus quoteToken, bookingId and email. It also states when not to use it (ride-type changes require cancel and re-request), so the alternative is named.

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