Antalya Transfers

Server Details

Quote and request private airport transfers in Antalya, Turkey. Operator confirms each request.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 25 days
Last Tested: 2026-11-06 21:00
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4.6/5.0

Scored 2026-10-15 14:55 across 4 tools

Disambiguation5/5

Each of the four tools targets a distinct action on the transfer-request lifecycle: quote (read-only pricing), create (write), status (read-only lookup), and cancel (destructive). The descriptions explicitly cross-reference each other (e.g. 'use get_price_quote instead', 'use get_request_status first') so an agent can route unambiguously.

Naming Consistency5/5

All tools follow a strict snake_case verb_noun pattern: get_price_quote, create_transfer_request, get_request_status, cancel_transfer_request. Verb style is consistent (get/create/cancel) and the resource noun is predictable.

Tool Count5/5

Four tools map cleanly onto the core lifecycle (quote → request → status → cancel) with no redundancy. Each tool earns its place and the surface is neither thin nor bloated.

Completeness4/5

Quote, creation, status lookup and cancellation cover the main customer-facing flow, and confirmation is exposed via get_request_status. The only gap is modifying an existing request (time/passengers/vehicle), which is deliberately delegated to the operator and requires cancel + re-create rather than a dedicated update tool.

Available Tools

4 tools

cancel_transfer_requestCancel a pending transfer requestA

DestructiveIdempotent

Inspect

Use this only when the customer has explicitly asked to cancel their transfer request and you have the booking reference returned by create_transfer_request and the email used for it. Cancels a request that is still pending or assigned, tells the operator (WhatsApp/email) and emails the customer a cancellation notice. Calling it again for an already-cancelled request is harmless and returns cancelled=true without notifying anyone again. Destructive and sends real messages: never call it to explore, to "test", or because the customer is merely unsure or wants to change details. Do not use for a request the operator has already confirmed (it is refused: the customer must contact the operator), for changing time/passengers/vehicle (contact the operator), or for refunds. Use get_request_status to check the current state first if unsure.

Name	Required	Description
`reason`	No	Optional short reason given by the customer
`reference`	Yes	Booking reference, e.g. AT-20260605-0001
`customerEmail`	Yes	Email address used when the request was submitted

Output Schema

Name	Required	Description
`status`	Yes
`message`	Yes
`cancelled`	Yes	true: the request is cancelled
`reference`	Yes
`alreadyCancelled`	No	true when it had been cancelled before this call (no new notification sent)
`operatorNotified`	No

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only flag destructive/openWorld/idempotent; the description goes well beyond them by disclosing downstream side effects (operator notified via WhatsApp/email, customer emailed a cancellation notice), the exact idempotency behavior (returns cancelled=true without re-notifying), and the refusal path for operator-confirmed requests.

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 preconditions and 'never call it to test/explore' warning are front-loaded, and every sentence carries operational weight. It is dense and a bit long, 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?

Given an output schema exists, return values need no explanation, and the description still covers side effects, idempotency, refusal cases, and the correct fallback tool. An agent has everything needed to invoke it safely.

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%, so the schema already documents reference, customerEmail, and the optional 200-char reason. The description reinforces that customerEmail must be the address used at submission, but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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+resource (cancels a pending/assigned transfer request) and names the exact prerequisites: the booking reference returned by create_transfer_request plus the submission email. It clearly separates itself from siblings by pointing to create_transfer_request and get_request_status by name.

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 when-to-use (customer asked to cancel and you hold the reference/email), explicit when-not (never to explore or test, not for unsure customers, not for confirmed requests, not for changes or refunds), and names the alternative tool to check state first. Nothing is left to inference.

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

create_transfer_requestSubmit transfer request (pending operator confirmation)AInspect

Use this only after the customer has chosen a route, time and vehicle and has given their name, email and phone, and explicitly asked to send the request. Submits a transfer REQUEST that is stored as pending and reviewed by the operator, who confirms the ride and final price by email/WhatsApp. This does NOT confirm a booking, assign a driver or take payment — never tell the customer the ride is confirmed. Writes data: do not call it to explore prices (use get_price_quote) and do not retry on success. Pass idempotencyKey to make retries safe: the same key for the same customer returns the original reference (duplicate=true) and never creates a second request; to change details, cancel and submit a new request with a new key. Without a key, repeating identical details also returns the original request. At most 5 requests per phone number per day. Capacity is checked: parties larger than the vehicle are rejected with a suggested vehicle.

Name	Required	Description
`pets`	No	Pets travelling (the operator confirms whether they can be carried)
`notes`	No	Extra instructions for the operator (hotel address, special needs)
`luggage`	No	Large suitcases
`language`	No	Customer language code, e.g. en, ru, de, tr
`childSeats`	No	Child seats required
`passengers`	Yes	Total passengers including children
`scheduledAt`	Yes	ISO 8601 date-time of pickup in Antalya local time, e.g. 2026-11-20T10:00:00+03:00. If no timezone is given, Antalya time (UTC+3) is assumed. For arrivals use flight landing time plus ~30 minutes.
`vehicleType`	Yes	Vehicle class; must fit passengers, luggage and child seats
`customerName`	Yes	Full name of the lead passenger
`flightNumber`	No	Flight number without spaces, e.g. TK2548
`customerEmail`	Yes	Where the reference and confirmation are sent
`customerPhone`	Yes	International format with country code, e.g. +905551234567
`pickupAddress`	Yes	Pickup place, e.g. "Antalya Airport (AYT) Terminal 2"
`dropoffAddress`	Yes	Drop-off place or hotel name with its area
`idempotencyKey`	No	Optional. A unique value (e.g. a UUID) you generate once per customer request and reuse on every retry. A retry with the same key and same customer email/phone returns the original reference with duplicate=true and creates nothing, even if other fields changed.

Output Schema

Name	Required	Description
`status`	Yes	New requests are pending. With duplicate=true this is the original request's current status. Only operatorConfirmed=true means the ride is confirmed.
`message`	Yes
`duplicate`	No	true: no new request was created; the original is returned
`reference`	No	Booking reference for get_request_status
`priceStatus`	No
`estimatedPrice`	No
`operatorConfirmed`	Yes	false: this is a request, not a confirmed ride

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only give a generic safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds what those cannot: the request lands in pending operator review, the operator confirms ride and final price by email/WhatsApp, no ride is confirmed, a 5-per-phone-per-day rate limit, server-side capacity rejection with a suggested larger vehicle, and detailed duplicate/idempotency semantics including duplicate=true. This is exactly the supplementary behavioral context annotations cannot carry.

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 highest-stakes constraint ('this does NOT confirm a booking — never tell the customer the ride is confirmed') and otherwise highly dense. It runs long and the idempotency paragraph overlaps substantially with the idempotencyKey property description, which is the only real redundancy.

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 15-parameter, 8-required write tool with an output schema and only generic annotations, the description covers usage preconditions, side effects, confirmation semantics, failure modes (capacity, rate limit) and retry safety. Nothing an agent needs before calling it is absent; return values are covered by the output schema.

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 the per-field baselines are already documented (including the idempotencyKey contract). The description still adds cross-parameter meaning not in any field: vehicleType must fit passengers/luggage/childSeats or the request is rejected with a counter-suggestion, and that a wrong-looking time or new details must be handled by cancelling and resubmitting with a fresh key.

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+resource ('Submits a transfer REQUEST') and immediately delimits scope: pending operator review, not a confirmed booking, no driver assignment, no payment. That framing cleanly separates it from siblings like get_price_quote, cancel_transfer_request and get_request_status without needing their 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?

Explicit preconditions ('only after the customer has chosen a route, time and vehicle and has given their name, email and phone, and explicitly asked'), explicit exclusions ('do not call it to explore prices — use get_price_quote', 'do not retry on success'), and an explicit alternative for pricing. Both the when and the when-not are named.

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

get_price_quoteGet airport transfer price quoteA

Read-onlyIdempotent

Inspect

Use this when a traveller asks how much a private airport transfer costs between Antalya Airport (AYT) and Antalya-area destinations (Konyaaltı, Antalya city/Kaleiçi, Lara, Belek, Side, Alanya, Kemer, Kaş) or between those resorts. Returns a fixed-price estimate in EUR, whether the party fits the chosen vehicle, and a suggested vehicle if not. Read-only: it does not create a request or reserve anything. Do not use for flights, car rental, tours, or destinations outside the Antalya region. If a route has no fixed price, priced=false and the operator quotes it.

Name	Required	Description
`luggage`	No	Number of large suitcases (optional)
`childSeats`	No	Number of child seats needed (optional)
`passengers`	Yes	Total passengers including children
`scheduledAt`	No	Optional pickup time. ISO 8601 date-time of pickup in Antalya local time, e.g. 2026-11-20T10:00:00+03:00. If no timezone is given, Antalya time (UTC+3) is assumed. If omitted a daytime price is returned; pickups 22:00–06:00 cost +30%.
`vehicleType`	No	Optional: if omitted the smallest vehicle that fits the party is quoted. Capacity: sedan 3 pax/2 large bags; minivan 8 pax/6 large bags; vip_sedan 3 pax/2 large bags; minibus 16 pax/12 large bags; bus 50 pax/50 large bags.
`pickupAddress`	Yes	Pickup place: "Antalya Airport (AYT)", a resort area or a hotel name, e.g. "Rixos Premium Belek".
`dropoffAddress`	Yes	Drop-off place, same format as pickupAddress, e.g. "Kemer".

Output Schema

Name	Required	Description
`note`	Yes
`route`	No
`priced`	Yes	false when this route has no fixed price; the operator will quote it
`capacity`	No
`currency`	Yes
`priceCents`	No
`assumptions`	No	Defaults applied for missing optional inputs
`vehicleType`	No
`estimatedPrice`	No	Formatted EUR price, e.g. "€80.00"
`nightSurchargeApplied`	No	+30% for pickups 22:00–06:00 Antalya time

TDQS

A4.3/5.0

Behavior4/5

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

Annotations confirm read-only/idempotent, and the description reinforces 'does not create a request or reserve anything'. It also explains fallback behavior (priced=false) and night surcharge. However, it doesn't cover rate limits, auth needs, or exact output shape beyond a high-level summary.

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-loads the primary use case and includes a clear 'Do not use' clause. Slightly dense but every sentence contributes; minor verbosity around destination lists.

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 an output schema exists and annotations cover safety, the description appropriately focuses on scope, return semantics (fit, suggested vehicle), and fallback pricing. It omits some edge cases (e.g., how child seats affect vehicle fit) but is complete enough 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 the schema already documents all parameters, including enums, capacities, and the night surcharge note. The description adds little parameter-specific syntax beyond confirming EUR and fixed-price behavior.

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 (get a price quote for a private airport transfer) and scopes it to the Antalya region. It clearly distinguishes itself from siblings like create_transfer_request and cancel_transfer_request by being read-only and quoting only.

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?

Explicitly states when to use it (traveller asks about cost between AYT and listed destinations), and when not to use it (flights, car rental, tours, destinations outside Antalya). It also notes that unpriced routes return priced=false and are operator-quoted.

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

get_request_statusCheck transfer request statusA

Read-onlyIdempotent

Inspect

Use this when the customer asks whether their transfer request was confirmed, assigned or cancelled. Requires the booking reference returned by create_transfer_request and the email used for the request. Read-only. pending means the operator has not confirmed yet; only operatorConfirmed=true means the ride is confirmed. Do not use to create or change a request.

Name	Required	Description	Default
`reference`	Yes	Booking reference, e.g. AT-20260605-0001
`customerEmail`	Yes	Email address used when the request was submitted

Output Schema

Name	Required	Description
`status`	Yes
`reference`	Yes
`priceStatus`	No
`scheduledAt`	No
`pickupAddress`	No
`statusMeaning`	Yes
`dropoffAddress`	No
`estimatedPrice`	No
`operatorConfirmed`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' mostly restates structured data. What the description adds beyond annotations is meaningful domain semantics: 'pending means the operator has not confirmed yet; only operatorConfirmed=true means the ride is confirmed', which the agent could not derive 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?

Three tight sentences, front-loaded with the usage trigger followed by prerequisites and exclusions. No filler and nothing repeated from the schema or annotations beyond a one-word safety restatement.

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?

An output schema exists, so return values need not be described, and the description supplies the one thing the schema cannot: how to interpret status values (pending vs operatorConfirmed). Prerequisites, inputs and exclusion of write behavior are all present for a 2-parameter read tool.

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%, so both parameters are already documented in the schema, and that establishes a baseline of 3. The description adds only the provenance of `reference` (returned by create_transfer_request) and clarifies the email is the one used at submission time — useful but marginal, with no format or matching-rule detail 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?

States a specific verb and resource ('check transfer request status') and frames it in terms of the customer question it answers (confirmed, assigned or cancelled). It also explicitly separates itself from the create/change siblings, so an agent can route 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 an explicit triggering condition ('when the customer asks whether their transfer request was confirmed, assigned or cancelled'), names where the required reference comes from (create_transfer_request), and states a negative constraint ('Do not use to create or change a request'). When-to-use and when-not-to-use are both covered.

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 14, 2026

Changedcreate_transfer_request5 fields changed

addedInput schema / properties / idempotencyKey

Added value: +{
+  "description": "Optional. A unique value (e.g. a UUID) you generate once per customer request and reuse on every retry. A retry with the same key and same customer email/phone returns the original reference with duplicate=true and creates nothing, even if other fields changed.",
+  "maxLength": 128,
+  "minLength": 8,
+  "pattern": "^[A-Za-z0-9_.:-]{8,128}$",
+  "type": "string"
+}

addedOutput schema / properties / duplicate

Added value: +{
+  "description": "true: no new request was created; the original is returned",
+  "type": "boolean"
+}

changedOutput schema / properties / priceStatus / enum

Previous value: -[
-  "indicative",
-  "operator_quote"
-]New value: +[
+  "indicative",
+  "final",
+  "operator_quote"
+]

changedOutput schema / properties / status / description

Previous value: -"Always pending: the operator has not confirmed yet"New value: +"New requests are pending. With duplicate=true this is the original request's current status. Only operatorConfirmed=true means the ride is confirmed."

changedOutput schema / properties / status / enum

Previous value: -[
-  "pending"
-]New value: +[
+  "pending",
+  "assigned",
+  "confirmed",
+  "in_progress",
+  "completed",
+  "cancelled"
+]

1 tool updateOct 13, 2026

Changedget_price_quote1 field changed

changedInput schema / properties / vehicleType / description

Previous value: -"Optional: if omitted the smallest vehicle that fits the party is quoted. Capacity: sedan 3 pax/2 large bags; minivan 6 pax/4 large bags; vip_sedan 3 pax/2 large bags; minibus 12 pax/8 large bags; bus 50 pax/50 large bags."New value: +"Optional: if omitted the smallest vehicle that fits the party is quoted. Capacity: sedan 3 pax/2 large bags; minivan 8 pax/6 large bags; vip_sedan 3 pax/2 large bags; minibus 16 pax/12 large bags; bus 50 pax/50 large bags."

1 tool updateOct 13, 2026
- Addedcancel_transfer_request
3 tool updatesOct 13, 2026
- First observedcreate_transfer_request
- First observedget_price_quote
- First observedget_request_status

Related MCP Connectors

AHM TransferA
com.ahmtransfer
Fixed prices, conditions and booking links for airport transfers in Alanya and Antalya, Türkiye.
Travel & Transportation E-commerce & Retail
41
https://ahmtransfer.com/mcp
CGC Airport TransfersA
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
GC Airport TransfersA
com.gc-airporttransfers
Private airport & cruise transfers: Gold Coast, Brisbane, Byron Bay (Queensland). Quotes + bookings.
Travel & Transportation E-commerce & Retail
41
https://gc-airporttransfers.com/wp-json/atb-gateway/v1/mcp
DaytripA
com.daytrip
Search, quote and book Daytrip private door-to-door car transfers in 130+ countries.
Travel & Transportation Location Services E-commerce & Retail
31
https://mcp.daytrip.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
MyDriverParis MCP Serverofficial
Travel & Transportation Location Services
mydriver-paris
A
license
A
quality
D
maintenance
Enables booking premium private chauffeur transfers in Paris and across Europe directly from AI agents. Provides tools to list vehicles, get quotes, book rides, and retrieve service information.
Updated 4 months ago (2026-07-13 21:21 UTC)
4
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 17 days ago (2026-10-20 16:54 UTC)
MIT
Tell & Goofficial
Travel & Transportation E-commerce & Retail
tell-and-go
A
license
Not graded
quality
C
maintenance
Lets any MCP-compatible AI agent search live resort inventory, request exact all-in quotes including transfers, and start real hotel bookings that the traveler completes on a hosted Stripe checkout.
Updated 4 days ago (2026-11-03 04:04 UTC)
MIT