Antalya Transfers

Get airport transfer price quote

get_price_quote

Read-onlyIdempotent

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

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."

First observedOct 13, 2026

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.

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?