Skip to main content
Glama

Feminiq Rides: Amsterdam chauffeur (female driver)

Send a booking request

request_booking
DestructiveIdempotent

Sends the quoted ride as a booking request. Call ONLY after the customer has seen the quoted total and how they pay, and has explicitly approved it and accepted the Terms (https://www.feminiqrides.nl/terms.html). Send exactly the same ride fields as the get_quote call plus its unchanged quoteToken and the customer's contact details. Nothing is charged now. The customer first gets an email with a Confirm link (valid 24 hours); after that click Feminiq Rides confirms personally and emails a SumUp payment request. Returns groupId and groupToken; pass them as joinGroup {groupId, groupToken} on further rides so they are confirmed and paid together (the result says grouped true or false). Repeating the identical call does not create a second booking.

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": {
      "type": "<type>",
      "car": "<car>",
      "date": "<date>",
      "time": "<time>",
      "passengers": "<passengers>",
      "quoteToken": "<quoteToken>",
      "name": "<name>",
      "email": "<email>",
      "phone": "<phone>",
      "acceptedTerms": "<acceptedTerms>"
    },
    "name": "request_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.
nameYes
timeYesLocal time in Europe/Amsterdam, between 04:00 and 20:00.
typeYes
emailYes
notesNo
phoneYesCustomer's phone number, with country code (for example +31 6 1234 5678).
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.
directionNoFixed routes only: to or from Schiphol.
joinGroupNoOptional. Adds this ride to an earlier request so the customer pays for all of them with ONE payment request. Pass the groupId and groupToken that request_booking returned for the earlier request, as {groupId, groupToken} ({id, token} also works). The result says grouped true or false; false means the ride stands alone (see joinRefused) and gets its own Confirm link and payment request.
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).
acceptedTermsYesMust be an explicit act by the customer after reading the Terms & Conditions. Agents must not set this on a customer's behalf without their consent.
ticketServiceNoTours only: attraction ticket purchase assistance, requires 28 days' notice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • 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."
    • changedInput schema / properties / joinGroup / description
      Previous value: -"Optional. Adds this ride to the request group of an earlier ride, so the owner approves them together and the customer receives ONE payment request (the sum of each ride's 25%, or full price where chosen). Use the `groupId` and `groupToken` returned for the earlier request. It is ignored (the ride stands alone) when the token or email does not match, or once any ride of the group has been approved."New value: +"Optional. Adds this ride to an earlier request so the customer pays for all of them with ONE payment request. Pass the groupId and groupToken that request_booking returned for the earlier request, as {groupId, groupToken} ({id, token} also works). The result says grouped true or false; false means the ride stands alone (see joinRefused) and gets its own Confirm link and payment request."
    • addedInput schema / properties / joinGroup / properties / groupId
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / joinGroup / properties / groupToken
      Added value: +{
      +  "type": "string"
      +}
    • removedInput schema / properties / joinGroup / required
      Removed value: -[
      -  "id",
      -  "token"
      -]
    • 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.6/5.0
Behavior4/5

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

Goes well beyond annotations: nothing is charged at request time, an email Confirm link valid 24 hours precedes manual confirmation, then a SumUp payment request follows, and repeating the identical call does not duplicate the booking (concretizing idempotentHint). It does not explain what the destructiveHint actually risks (e.g. whether an accepted confirmation can be withdrawn), which is the one behavioral gap against a 5.

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?

Six tightly packed sentences with the safety precondition front-loaded right after the purpose statement; each sentence carries a distinct fact (precondition, field parity, payment flow, grouping, idempotency). It is dense but not padded, though it reads as one long run-on that could be split for scannability.

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 26-parameter destructive mutation with no output schema, the description covers the full lifecycle: approval gate, contact details, confirm-email step, payment timing, returned groupId/groupToken, and grouping on subsequent rides. What remains undocumented is delegated to a schema with 77% coverage and detailed error codes.

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 77%, and the description adds real meaning on top: quoteToken must be passed unchanged and binds the approved fare and 15-minute expiry, ride fields must match the get_quote call exactly, and joinGroup takes the previously returned groupId/groupToken. It leaves the ride-field parameters themselves to the schema, which already documents them well.

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 ('Sends the quoted ride as a booking request') and ties it to the get_quote output, which separates it cleanly from siblings like get_quote and change_booking. An agent knows exactly what this tool produces 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?

Explicit precondition chain: call ONLY after the customer has seen the quoted total and payment method, explicitly approved, and accepted the Terms. It also names the prerequisite call (get_quote) and the follow-up mechanism (joinGroup with returned groupId/groupToken), 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