Skip to main content
Glama

Get a fixed-price quote

get_quote
Read-only

Exact fixed prices for a transfer between two locations, straight from the live booking engine. Per vehicle, AUD, GST and tolls included, locked at booking, no surge. If the route has no fixed price the response says so — never estimate a figure yourself. Every quote without stops includes book_url (and one per vehicle in book_urls): a pre-filled booking page the customer completes, accepts terms and pays on. Give the customer that link exactly as returned, utm tags included, so the booking is attributed to an AI assistant; pass date, time, passengers, return leg, luggage, child seats and flight here so the link carries them. With a date, closures are checked first: on Christmas Day (25 December) or inside a blackout window the response is available:false with the closure message and no prices. fares_aud are always ONE-WAY fares; with return_date the quote adds return_totals_aud, the whole return trip per vehicle (outbound plus the return leg at the booking form's return discount) — quote that for a return, never the one-way fare. If the return starts or ends somewhere else (in to one hotel, back from another), add return_pickup and/or return_dropoff: each trip is then priced at its own fare and the return discount comes off the cheaper trip, exactly as the booking form does. Stops on the way (up to 4 each way): add stops, and return_stops for the way back on a return. The booking form adds the detour through them, charged by the extra distance and the same for every vehicle, and the quote gives totals_aud (one way) or return_totals_aud (a return) with the stops in: quote those. A quote with stops has no book_url (the booking form's links can't carry stops yet): book it with request_booking.

Input Schema

NameRequiredDescriptionDefault
paxNoTotal passengers including children. With pax the quote lists only the vehicles that take the whole group, as the booking engine does: groups of 8 or more get the two-vehicle options and the VW Crafter (up to 11 passengers, one van for the whole group).
bagsNoLarge bags
dateNoTravel date YYYY-MM-DD (goes into book_url; closures are checked)
timeNoPickup time HH:MM, 24h, Queensland time (goes into book_url)
carryNoCarry-on bags
seatsNoChild seats as {index: qty}; index 0 rear-facing (0-3y), 1 forward-facing (6m-3y), 2 harnessed booster (3-6y), 3 booster with adult belt (6y+). $35 each.
stopsNoOptional: stops on the way (drop someone off, a shop, a second hotel), in order, up to 4. Each a street address (number and street, suburb) or a hotel or venue name with its suburb, never just a suburb. The booking form adds the detour through them, charged by the extra distance and the same for every vehicle. On a return these are the stops on the way there. Leave out for none.
flightNoFlight number, e.g. JQ430
pickupYesPickup suburb, hotel or airport
dropoffYesDrop-off suburb, hotel or airport
vehicleNoChosen vehicle: sedan | carnival | carnival_rav4 | two_carnivals | crafter | crafter_trailer (sets book_url; book_urls has all)
oversizedNoOversized luggage (surfboards, golf clubs, prams)
return_dateNoReturn leg date YYYY-MM-DD, if a return: adds return_totals_aud (the whole return trip per vehicle)
return_timeNoReturn leg pickup time HH:MM
return_stopsNoOptional, with return_date: stops on the way back, in order, up to 4, same rules as stops. Not copied from stops: leave out for no stops on the way back.
return_pickupNoOptional, with return_date: where the return trip picks up, if not the first trip's drop-off (e.g. a different hotel). Defaults to the first trip reversed.
return_dropoffNoOptional, with return_date: where the return trip drops off, if not the first trip's pickup. Defaults to the first trip reversed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / return_stops
      Added value: +{
      +  "description": "Optional, with return_date: stops on the way back, in order, up to 4, same rules as stops. Not copied from stops: leave out for no stops on the way back.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 4,
      +  "type": "array"
      +}
    • addedInput schema / properties / stops
      Added value: +{
      +  "description": "Optional: stops on the way (drop someone off, a shop, a second hotel), in order, up to 4. Each a street address (number and street, suburb) or a hotel or venue name with its suburb, never just a suburb. The booking form adds the detour through them, charged by the extra distance and the same for every vehicle. On a return these are the stops on the way there. Leave out for none.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 4,
      +  "type": "array"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / return_dropoff
      Added value: +{
      +  "description": "Optional, with return_date: where the return trip drops off, if not the first trip's pickup. Defaults to the first trip reversed.",
      +  "type": "string"
      +}
    • addedInput schema / properties / return_pickup
      Added value: +{
      +  "description": "Optional, with return_date: where the return trip picks up, if not the first trip's drop-off (e.g. a different hotel). Defaults to the first trip reversed.",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / return_date / description
      Previous value: -"Return leg date YYYY-MM-DD, if a return"New value: +"Return leg date YYYY-MM-DD, if a return: adds return_totals_aud (the whole return trip per vehicle)"
  4. Changed2 schema fields changed
    • changedInput schema / properties / date / description
      Previous value: -"Travel date YYYY-MM-DD (goes into book_url)"New value: +"Travel date YYYY-MM-DD (goes into book_url; closures are checked)"
    • changedInput schema / properties / pax / description
      Previous value: -"Total passengers including children. With pax the quote lists only the vehicles that take the whole group, as the booking engine does: groups of 8 or more get the two-vehicle options and the VW Crafter (one van for 8-11)."New value: +"Total passengers including children. With pax the quote lists only the vehicles that take the whole group, as the booking engine does: groups of 8 or more get the two-vehicle options and the VW Crafter (up to 11 passengers, one van for the whole group)."
  5. Changed2 schema fields changed
    • changedInput schema / properties / pax / description
      Previous value: -"Total passengers including children"New value: +"Total passengers including children. With pax the quote lists only the vehicles that take the whole group, as the booking engine does: groups of 8 or more get the two-vehicle options and the VW Crafter (one van for 8-11)."
    • changedInput schema / properties / vehicle / description
      Previous value: -"Chosen vehicle: sedan | carnival | carnival_rav4 | two_carnivals (sets book_url; book_urls has all)"New value: +"Chosen vehicle: sedan | carnival | carnival_rav4 | two_carnivals | crafter | crafter_trailer (sets book_url; book_urls has all)"
  6. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With annotations declaring readOnlyHint=true and openWorldHint=false, the description adds rich behavioral context: pricing rules (AUD, GST, tolls, no surge), return handling (fares_aud one-way, return_totals_aud for full return, return discount logic), stops handling (detour pricing, no book_url with stops), closure handling (Christmas Day, blackout windows), and the importance of using the returned book_url with utm tags. This goes well beyond 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.

Conciseness4/5

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

The description is long but front-loaded with the core purpose and packed with relevant information. Every sentence contributes something useful, though the dense paragraph could be better structured with bullet points for readability. No redundant statements, but the length is near the upper limit for conciseness.

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?

Given the complexity (17 parameters, nested objects) and the absence of an output schema, the description covers key return values (fares_aud, return_totals_aud, totals_aud, book_url, book_urls, available) and behavioral nuances. It does not fully describe the complete response structure (e.g., per-vehicle details), leaving some gaps, but it is sufficient for an agent to invoke the tool correctly and interpret the main outcomes.

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 description coverage is 100%, so parameter meanings are already well-documented. The description adds value by explaining interactions: how return_date adds return_totals_aud, how return_pickup/return_dropoff affect pricing on returns, and how stops generate totals_aud or return_totals_aud without a book_url. This exceeds the baseline of 3 by clarifying parameter effects beyond individual definitions.

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 opens with a specific verb and resource: 'Exact fixed prices for a transfer between two locations, straight from the live booking engine.' It clearly distinguishes the tool from request_booking by noting that quotes with stops must be booked via request_booking. An agent can tell this is the tool for getting fixed-price transfer quotes.

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?

The description gives clear context for use: pass various trip details to get a book_url, and use request_booking for booking when stops are present. However, it does not explicitly state when to use this tool versus check_availability or get_service_info, leaving some ambiguity about alternatives.

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