Skip to main content
Glama

Feminiq Rides: Amsterdam chauffeur (female driver)

Get a price for a ride

get_quote
Read-onlyIdempotent

Exact price and rule check for one ride (no booking, no email, no payment). Returns the total, any online deposit and a quoteToken valid for 15 minutes. Per type: fixed needs routeId, direction and address; custom needs pickup and dropoff; tour needs tourIds and pickup. Fixed fares only apply inside each route's zone: error address_zone means quote a custom ride instead. Does not check driver availability.

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>"
    },
    "name": "get_quote"
  }
}

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
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.
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
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. Changed4 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."
    • 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.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the quoteToken's 15-minute validity, that no booking/email/payment happens, and that driver availability is not checked. These are important behavioral traits that affect how an agent should interpret and use the result.

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 compact but information-dense, with the core purpose and return values front-loaded. Each sentence adds operational value: type requirements, zone errors, and the explicit limitation that availability is not checked.

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 rich schema, annotations, and 20 parameters, the description covers what the schema does not: the quote-only nature, token expiry, per-type required fields, fixed-zone error behavior, and absence of availability checks. No output schema exists, but the return shape is summarized sufficiently for this tool.

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 high at 80%, but the description adds crucial conditional semantics: fixed requires routeId, direction, and address; custom requires pickup and dropoff; tour requires tourIds and pickup. It also links address selection to route zones and the address_zone fallback, which is meaningful guidance 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?

The description states a specific verb and resource ('Exact price and rule check for one ride') and clearly distinguishes this from booking, email, and payment actions. It also explains what is returned (total, deposit, quoteToken) and the type-specific requirements, so the agent can identify the tool without opening sibling schemas.

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?

It explicitly says when to use this tool versus downstream actions by clarifying no booking, no email, and no payment occurs. It also provides concrete conditional guidance per ride type and an alternative when fixed fare zones fail with address_zone, plus notes that driver availability is not checked.

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