Skip to main content
Glama

Jet Cab AMS: Amsterdam & Schiphol chauffeur

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
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
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.
directionNoFixed routes only: to or from Schiphol.
meetGreetNoOptional €25 arrivals-area name card; only for direction=from.
driverNameNo
passengersYes
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.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description still adds substantive behavior: a quoteToken valid for 15 minutes, the specific figures returned (total, online deposit), no email or payment side effects, and the fact that driver availability is not verified. That is real disclosure beyond the annotation set, consistent with openWorldHint for a live-priced quote.

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?

Four dense sentences, each carrying distinct load: scope, return value and token lifetime, per-type parameter requirements, and the zone-error fallback. Constraints are front-loaded before the type-specific detail.

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?

Strong for a 20-param tool with a nested returnTrip object and no output schema: it states the returned fields and token lifetime so the agent knows what a success looks like. Minor gaps remain — optional params like lang, notes, driverName and flight are left entirely to the schema, and the downstream use of quoteToken is never stated.

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?

With 20 parameters and a discriminator field, the schema alone requires only five; the description supplies the conditional requirement matrix tying type=fixed/custom/tour to their respective parameter sets. It also explains the address_zone failure mode and the zone-pricing behavior of `address`, which the schema only gestures at.

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 and resource plus explicit negative scope: "Exact price and rule check for one ride (no booking, no email, no payment)." That negative framing cleanly separates it from request_booking and change_booking in the sibling set, and the closing "Does not check driver availability" further bounds what the agent should expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives conditional usage per type ("fixed needs routeId, direction and address; custom needs pickup and dropoff; tour needs tourIds and pickup") and a concrete fallback path ("error address_zone means quote a custom ride instead"). It does not explicitly name request_booking as the follow-up tool for actually booking, leaving the agent to infer the quote-then-book relationship from the "no booking" phrasing.

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