GC Airport Transfers

by com.gc-airporttransfers

Overview Discussions Admin

Server Details

GC & Brisbane airport + cruise transfers: quotes, availability; pay by emailed link. OAuth.

Ownership verified

Status: Healthy
Uptime: 26.5% over 75 days
OAuth: Works in Glama
Last Tested: 2026-10-31 11:30
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-27 14:45 across 4 tools

Disambiguation4/5

Each tool targets a distinct step in the booking flow: availability, pricing, business information, and booking requests. There is minor overlap because get_service_info includes pricing information while get_quote provides exact fares, but the descriptions explicitly direct agents to use get_quote for prices.

Naming Consistency5/5

All tool names follow a clear verb_noun pattern in snake_case: check_availability, get_quote, get_service_info, and request_booking. The convention is predictable and readable throughout.

Tool Count5/5

Four tools are well matched to the narrow scope of an airport transfer booking service. Each tool has a clear role in the customer journey and no tool feels redundant.

Completeness3/5

The surface covers information, availability, quotes, and booking requests, which supports the main customer flow. However, there is no tool to retrieve booking status, modify a request, or cancel a booking, leaving parts of the booking lifecycle uncovered.

Available Tools

4 tools

check_availabilityCheck availabilityA

Read-only

Inspect

Date/time bookability only — not prices (use get_quote for fares). Checks the operator's live settings (after-hours window, days off and blocked dates, optionally per vehicle). Times outside standard hours are bookable as after-hours requests (surcharge may apply); same-day should phone. Not a driver calendar: the operator confirms every booking.

Name	Required	Description
`date`	Yes	YYYY-MM-DD
`time`	Yes	HH:MM 24h
`vehicle`	No	sedan \| carnival \| maxi \| eqb \| v300 (optional; checks that vehicle's days off)

Output Schema

Name	Required	Description
`note`	Yes
`reason`	Yes
`status`	Yes
`unavailable_vehicles`	No

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond them: live operator settings are consulted, after-hours results may carry a surcharge, same-day requires a phone call, and the operator confirms every booking. These are operational nuances an agent cannot infer from annotations alone.

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 scoping constraint ('not prices') is front-loaded in the first clause, followed by the mechanism, edge-case behavior, and a final clarifying exclusion. Dense but every sentence adds decision-relevant information; no filler.

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?

With an output schema present, return values need not be explained, and annotations cover safety. The description still supplies everything needed to call correctly: what is checked, what is not checked (prices, driver calendar), the after-hours path, same-day handling, and the confirmation model.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (date as YYYY-MM-DD, time as HH:MM 24h, vehicle with enum-like values), so the schema carries parameter meaning. The description adds only light context ('optionally per vehicle' — checks that vehicle's days off), which largely restates the schema's vehicle description. Baseline 3 is appropriate.

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 precise verb+resource ('check availability') and immediately scopes it to 'Date/time bookability only — not prices', explicitly naming the sibling get_quote for fares. It also clarifies the domain (operator live settings: after-hours, days off, blocked dates, optionally per vehicle), so an agent can distinguish it from get_quote, get_service_info, and request_booking without opening any 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?

Gives explicit routing: use get_quote for fares, phone for same-day, and notes that outside-hours times are still bookable as after-hours requests (surcharge may apply). It also excludes a plausible misread ('not a driver calendar') and states that the operator confirms every booking, so the agent knows this is an inquiry, not a reservation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_quoteGet a fixed-price quoteA

Read-only

Inspect

Exact per-vehicle prices from the live fixed price list — airport transfers (OOL/BNE) and Brisbane Cruise Terminal runs (use "Brisbane Cruise Terminal" or "Pinkenba" as the place). Supports optional return trips (trip=return + return_date/return_time); return totals use the operator native return discount. Deterministic — never estimates. If match is "none", give the customer the phone number instead of guessing.

Name	Required	Description
`to`	Yes	Drop-off place, e.g. "Gold Coast Airport" or a suburb (alias: dropoff)
`pax`	No	Passengers 1-16 (filters vehicles; 12-16 returns the two-vehicle Carnival+Maxi combination priced as a total). Groups over 16 return match "none" with contact details - do not quote them a price.
`date`	No	YYYY-MM-DD (optional)
`from`	Yes	Pick-up place, e.g. "Broadbeach" or "OOL" (alias: pickup)
`time`	No	HH:MM 24h (optional; flags after-hours surcharge)
`trip`	No	one_way (default) or return. When return, also send return_date and return_time.
`flight`	No	Flight number (optional; prefills the booking form)
`pickup`	No	Alias for from (same meaning as request_booking.pickup)
`dropoff`	No	Alias for to (same meaning as request_booking.dropoff)
`luggage`	No	Large bags (optional; filters vehicles and prefills the booking form)
`return_date`	No	YYYY-MM-DD return pick-up date (optional; implies trip=return)
`return_time`	No	HH:MM 24h return pick-up time (optional; implies trip=return)

Output Schema

Name	Required	Description
`to`	No
`code`	No
`from`	No
`trip`	No
`email`	No
`error`	No
`match`	No
`phone`	No
`route`	No
`terms`	No
`reason`	No
`return`	No
`max_pax`	No
`message`	No
`options`	No
`suggest`	No
`website`	No
`book_url`	No
`currency`	No
`surcharges`	No
`retry_after`	No
`valid_as_of`	No
`unavailable_note`	No
`unavailable_vehicles`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly=true, destructive=false, openWorld=true, so the safety profile is covered; the description adds real behavioral detail on top — determinism (never estimates), that return totals apply the operator's native return discount, and what to do when no match is found. It doesn't discuss price validity windows or the shape of a 'match: none' response, which would have pushed it higher.

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?

Front-loaded with the core promise (exact prices, live list, deterministic) before edge-case handling. The long em-dash-laden first sentence packs several distinct concerns (regions, place naming, returns, discounts) and could be split, but no sentence is filler.

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 read-only, 12-parameter quote tool with full schema descriptions and an output schema, the description covers what the schema cannot: determinism, region scope, return-trip pricing behavior, and the no-match protocol. Nothing needed to invoke it correctly is missing.

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 100%, so baseline is 3, but the description adds meaning the schema lacks: the accepted place strings for the cruise terminal ('Brisbane Cruise Terminal' or 'Pinkenba') and the trip=return + return_date/return_time pairing convention. That is genuine semantic guidance beyond the parameter docs.

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 (exact per-vehicle prices from the live fixed price list) plus the scope it covers: OOL/BNE airport transfers and Brisbane Cruise Terminal runs. The 'deterministic — never estimates' clause separates it from any fuzzy availability/enquiry sibling without needing to open a schema.

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 clear conditions for use (fixed-price airport and cruise terminal transfers, optional return trips) and an explicit fallback for the negative case: 'If match is "none", give the customer the phone number instead of guessing.' It stops short of naming check_availability or request_booking as alternatives when a quote isn't the right call, so routing between siblings is left partly implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_service_infoService informationA

Read-only

Inspect

Full business facts: fleet, pricing list, policies, service area, contact details. Use this before answering questions about GC Airport Transfers.

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the content scope but does not describe return format, freshness, or any access limitations; with annotations carrying the behavioral burden, this is adequate but not rich.

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?

Two compact sentences with the content scope front-loaded and the usage directive immediately after. Every phrase contributes useful information and there is no filler.

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?

For a parameterless informational tool with strong annotations and no output schema, the description sufficiently enumerates what the agent will receive. It would be stronger with a note on return structure or freshness, but it is complete enough to call correctly.

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?

The tool has zero parameters, so there is no parameter semantics to document. The baseline for parameterless tools is 4, and nothing here contradicts or complicates that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the resource as full business facts and enumerates the categories returned: fleet, pricing, policies, service area, and contact details. It is distinguishable from the transactional siblings by being informational, though it does not explicitly name alternatives.

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 a clear usage directive: 'Use this before answering questions about GC Airport Transfers.' It does not explicitly list exclusions or name sibling tools, but the context of answering business questions is well established.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_bookingRequest a bookingAInspect

Lodge a booking REQUEST for any fixed-price route — airport or cruise terminal. It is created as pending; the operator confirms and the customer receives a payment link by email. No payment happens through this tool. Confirm all details with the customer first.

Name	Required	Description
`pax`	Yes	Passengers 1-16. Over 16 cannot be booked online - give the customer the phone number.
`date`	Yes	YYYY-MM-DD (at least 1 hour ahead; same-day: phone instead)
`name`	Yes	Customer full name
`time`	Yes	HH:MM 24h
`email`	Yes	Customer email (receives acknowledgement + payment link)
`notes`	No	Anything else, e.g. child seats with ages (optional)
`phone`	Yes	Customer phone
`flight`	No	Flight number (optional, enables free flight tracking)
`pickup`	Yes	Pick-up place
`dropoff`	Yes	Drop-off place
`sandbox`	No	Not supported: true is refused (this endpoint has no test mode; a request creates a real booking). Omit it.
`vehicle`	No	sedan \| carnival \| maxi \| eqb (Mercedes EQB luxury SUV, up to 3) \| v300 (Mercedes V300 luxury van, up to 6) - auto-upgraded if too small for pax

Output Schema

Name	Required	Description
`ok`	No
`code`	No
`error`	No
`errors`	No
`lodged`	No
`status`	No
`message`	No
`request`	No
`sandbox`	No
`vehicle`	No
`duplicate`	No
`price_aud`	No
`reference`	No
`amount_aud`	No
`payment_url`	No

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description explains the real workflow: the request is created as pending, the operator confirms it, the customer receives a payment link by email, and no payment happens through the tool. That is exactly the behavioral context an agent needs before invoking a non-read-only booking action.

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?

Three compact sentences, front-loaded with the core action and followed by the key workflow caveats. Every sentence contributes useful information with no filler.

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 12-parameter mutation tool with a full schema and an output schema, the description supplies the essential workflow, pending-state behavior, payment boundary, and customer-confirmation requirement. Nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all 12 parameters are already well documented in the input schema, including pax limits, date rules, and vehicle options. The description adds the fixed-price/airport-or-cruise route restriction, but otherwise does not elaborate on parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 — 'Lodge a booking REQUEST' — and scopes it to fixed-price airport or cruise-terminal routes. That is clearly distinct from a quote or availability check, though it does not explicitly name the sibling tools it differs from.

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?

It gives clear context: use this for fixed-price routes, expect a pending request rather than a confirmed booking, and confirm details with the customer first. It does not explicitly say when to use check_availability or get_quote instead, so the alternative-routing guidance is only implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 27, 2026

Changedget_quote9 fields changed

addedInput schema / properties / flight

Added value: +{
+  "description": "Flight number (optional; prefills the booking form)",
+  "type": "string"
+}

addedInput schema / properties / luggage

Added value: +{
+  "description": "Large bags (optional; filters vehicles and prefills the booking form)",
+  "type": "integer"
+}

addedInput schema / properties / return_date

Added value: +{
+  "description": "YYYY-MM-DD return pick-up date (optional; implies trip=return)",
+  "type": "string"
+}

addedInput schema / properties / return_time

Added value: +{
+  "description": "HH:MM 24h return pick-up time (optional; implies trip=return)",
+  "type": "string"
+}

addedInput schema / properties / trip

Added value: +{
+  "description": "one_way (default) or return. When return, also send return_date and return_time.",
+  "type": "string"
+}

addedOutput schema / properties / options / items / properties / outbound_aud
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / options / items / properties / return_aud
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / return

Added value: +{
+  "properties": {
+    "date": {
+      "type": "string"
+    },
+    "match": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "route": {
+      "type": "object"
+    },
+    "time": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / trip

Added value: +{
+  "enum": [
+    "one_way",
+    "return"
+  ],
+  "type": "string"
+}

1 tool updateOct 27, 2026

Changedget_quote4 fields changed

addedInput schema / properties / dropoff

Added value: +{
+  "description": "Alias for to (same meaning as request_booking.dropoff)",
+  "type": "string"
+}

changedInput schema / properties / from / description

Previous value: -"Pick-up place, e.g. \"Broadbeach\" or \"OOL\""New value: +"Pick-up place, e.g. \"Broadbeach\" or \"OOL\" (alias: pickup)"

addedInput schema / properties / pickup

Added value: +{
+  "description": "Alias for from (same meaning as request_booking.pickup)",
+  "type": "string"
+}

changedInput schema / properties / to / description

Previous value: -"Drop-off place, e.g. \"Gold Coast Airport\" or a suburb"New value: +"Drop-off place, e.g. \"Gold Coast Airport\" or a suburb (alias: dropoff)"

3 tool updatesOct 26, 2026

Changedcheck_availability1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "note": {
+      "type": "string"
+    },
+    "reason": {
+      "type": "string"
+    },
+    "status": {
+      "enum": [
+        "bookable",
+        "after_hours_request",
+        "not_bookable",
+        "call_us"
+      ],
+      "type": "string"
+    },
+    "unavailable_vehicles": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "status",
+    "reason",
+    "note"
+  ],
+  "type": "object"
+}

Changedget_quote1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "anyOf": [
+    {
+      "required": [
+        "match"
+      ]
+    },
+    {
+      "required": [
+        "error"
+      ]
+    },
+    {
+      "required": [
+        "code",
+        "message"
+      ]
+    }
+  ],
+  "description": "The live fixed-price list result, passed through from the booking site. match fixed_route = options carries per-vehicle prices; none / blocked / unavailable = no price, give the customer the contact details or message. If the quote service itself refused (e.g. rate limit) the object carries error instead of match.",
+  "properties": {
+    "book_url": {
+      "type": "string"
+    },
+    "code": {
+      "type": "string"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "email": {
+      "type": "string"
+    },
+    "error": {
+      "type": "string"
+    },
+    "from": {
+      "type": "string"
+    },
+    "match": {
+      "enum": [
+        "fixed_route",
+        "none",
+        "blocked",
+        "unavailable"
+      ],
+      "type": "string"
+    },
+    "max_pax": {
+      "type": "integer"
+    },
+    "message": {
+      "type": "string"
+    },
+    "options": {
+      "items": {
+        "properties": {
+          "combo": {
+            "type": "boolean"
+          },
+          "label": {
+            "type": "string"
+          },
+          "max_pax": {
+            "type": "integer"
+          },
+          "per": {
+            "enum": [
+              "vehicle",
+              "total"
+            ],
+            "type": "string"
+          },
+          "price_aud": {
+            "type": "number"
+          },
+          "vehicle": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "vehicle",
+          "label",
+          "max_pax",
+          "price_aud",
+          "per"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "phone": {
+      "type": "string"
+    },
+    "reason": {
+      "type": "string"
+    },
+    "retry_after": {
+      "type": "integer"
+    },
+    "route": {
+      "properties": {
+        "airport": {
+          "type": "string"
+        },
+        "from": {
+          "type": "string"
+        },
+        "to": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "suggest": {
+      "type": "string"
+    },
+    "surcharges": {
+      "items": {
+        "properties": {
+          "applies": {
+            "type": "boolean"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "applies"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "terms": {
+      "type": "string"
+    },
+    "to": {
+      "type": "string"
+    },
+    "unavailable_note": {
+      "type": "string"
+    },
+    "unavailable_vehicles": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "valid_as_of": {
+      "type": "string"
+    },
+    "website": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedrequest_booking1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Lodged: ok true with the booking reference, status awaiting_payment and the payment link the customer also receives by email (duplicate true = the same request was already lodged in the last 10 minutes; nothing new was created). Sandbox connections: status sandbox_not_lodged, lodged false.",
+  "properties": {
+    "amount_aud": {
+      "type": "number"
+    },
+    "code": {
+      "type": "string"
+    },
+    "duplicate": {
+      "type": "boolean"
+    },
+    "error": {
+      "type": "string"
+    },
+    "errors": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "lodged": {
+      "type": "boolean"
+    },
+    "message": {
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "payment_url": {
+      "type": "string"
+    },
+    "price_aud": {
+      "type": "number"
+    },
+    "reference": {
+      "type": "string"
+    },
+    "request": {
+      "properties": {
+        "date": {
+          "type": "string"
+        },
+        "dropoff": {
+          "type": "string"
+        },
+        "pax": {
+          "type": "integer"
+        },
+        "pickup": {
+          "type": "string"
+        },
+        "time": {
+          "type": "string"
+        },
+        "vehicle": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "sandbox": {
+      "type": "boolean"
+    },
+    "status": {
+      "type": "string"
+    },
+    "vehicle": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

3 tool updatesOct 26, 2026

Changedcheck_availability1 field changed

addedInput schema / properties / vehicle

Added value: +{
+  "description": "sedan | carnival | maxi | eqb | v300 (optional; checks that vehicle's days off)",
+  "type": "string"
+}

Changedget_quote1 field changed

changedInput schema / properties / pax / description

Previous value: -"Passengers 1-11 (filters vehicles)"New value: +"Passengers 1-16 (filters vehicles; 12-16 returns the two-vehicle Carnival+Maxi combination priced as a total). Groups over 16 return match \"none\" with contact details - do not quote them a price."

Changedrequest_booking3 fields changed

changedInput schema / properties / pax / description

Previous value: -"Passengers 1-11"New value: +"Passengers 1-16. Over 16 cannot be booked online - give the customer the phone number."

changedInput schema / properties / sandbox / description

Previous value: -"true = create a TEST booking that never reaches the operator and sends no emails. For integration testing only."New value: +"Not supported: true is refused (this endpoint has no test mode; a request creates a real booking). Omit it."

changedInput schema / properties / vehicle / description

Previous value: -"sedan | carnival | maxi (auto-upgraded if too small for pax)"New value: +"sedan | carnival | maxi | eqb (Mercedes EQB luxury SUV, up to 3) | v300 (Mercedes V300 luxury van, up to 6) - auto-upgraded if too small for pax"

4 tool updatesAug 17, 2026
- First observedcheck_availability
- First observedget_quote
- First observedget_service_info
- First observedrequest_booking

Related MCP Connectors

CGC Airport Transfers A
au.com.cgctransfers
Fixed-price quotes and bookings for private airport transfers: Gold Coast, Brisbane, Byron Bay.
Travel & Transportation Location Services E-commerce & Retail
41
https://cgctransfers.com.au/wp-json/cgc-gateway/v1/mcp
Airport Pickups London AOAuth
com.airport-pickups-london
Get date-specific quotes and book private UK airport and cruise-port transfers through your AI assistant. Compare vehicle options, validate flights, retrieve bookings, amend details and cancel with customer confirmation. No registration required to start, subject to service limits; optional API-key and OAuth access for registered integrations. Transfer fares are payable separately and cancellation conditions apply. Live demo and connection instructions: https://ai.airport-pickups-london.com/ Technical documentation: https://mcp.airport-pickups-london.com/docs
E-commerce & Retail Travel & Transportation
113
https://mcp.airport-pickups-london.com/mcp
Arrumou Neural BOAuth
io.github.brunoreisportela
Manage vacation rentals, bookings, calendars and operations with OAuth and action approvals.
Calendar Management Real Estate Travel & Transportation
731
https://app.arrumou.com/mcp
flightclawOAuth
com.flightclaw
Search ~300 airlines and book flights with a checkout link. OAuth sign-in by email code.
Travel & Transportation E-commerce & Retail
178
https://mcp.flightclaw.com/mcp

Related MCP Servers

Airport Pickups London MCP
mfy-apl
A
license
Not graded
quality
D
maintenance
Enables AI agents to get fixed-price quotes and book London airport transfers, with flight validation and inter-agent communication via A2A protocol.
Updated 8 months ago (2026-03-11 22:27 UTC)
MIT
Tripyana London Chauffeurofficial
Travel & Transportation
tripyana
A
license
Not graded
quality
D
maintenance
Fixed London chauffeur prices for AI agents: Heathrow/Gatwick/Stansted/Luton and cruise-port transfers, hourly and full-day hire, private day trips, Heathrow VIP meet & greet, plus pre-filled booking links. Public remote endpoint, no API key.
Updated 11 days ago (2026-10-20 16:54 UTC)
MIT
Hreyfill
Travel & Transportation Location Services
axelpaul
A
license
Not graded
quality
C
maintenance
Lets MCP clients calculate taxi fare quotes, review upcoming and past bookings, fetch receipts, driver images and trip routes, check nearby taxis and live trip status, and resolve addresses or directions with a Google Maps key. Read tools are available by default, while booking, cancellation, payment and profile changes stay opt-in and require an explicit boolean confirmation.
Updated 4 days ago (2026-10-27 21:37 UTC)
MIT
INTUIMCP
Travel & Transportation Workplace & Productivity App Automation
hasseibbuildix-sys
F
license
Not graded
quality
D
maintenance
MCP server for Intui.travel fleet carriers that reads orders, tracks confirmations, cancellations, and modifications, and syncs live to Google Sheets.
Updated 3 months ago (2026-08-15 14:31 UTC)
-