Antalya Transfers

Submit transfer request (pending operator confirmation)

create_transfer_request

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 14, 2026

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"
+]

First observedOct 13, 2026

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.

All Antalya Transfers tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?