Gulf cross-border private transfers: routes, per-vehicle prices, border steps, booking inquiries
Scored across 4 tools
Each tool clearly targets a distinct step in the customer journey: search_routes for discovery, get_route_details for one route's details, list_travel_guides for editorial content, and create_inquiry for booking requests. Descriptions explicitly cross-reference which tool to use for adjacent needs, leaving little room for misselection.
All four names follow a clean verb_noun pattern: search_routes, get_route_details, list_travel_guides, create_inquiry. The resource nouns are descriptive and consistent with the domain.
Four tools is well-scoped for a narrow private-transfer booking surface, with one tool per lifecycle stage and no redundant variants. Nothing feels missing at the naming level or excessive.
Discovery, detail retrieval, guide content and inquiry creation are covered, but there is no way to check an inquiry's status, modify or cancel it after creation, or check vehicle availability directly. The WhatsApp handoff is a reasonable workaround, but the tools leave an agent at a dead end after create_inquiry.
Sends a booking request to the Platinumride team. Use it only after the customer has chosen a route and agreed to the Terms of Service (https://platinumride.com/terms). Do not use it for browsing or quotes; use search_routes and get_route_details for that. Each call sends a new inquiry and is not idempotent, so never call it twice for the same request. Limit: 3 inquiries per connection every 10 minutes. Returns an inquiry reference and a WhatsApp follow-up link to share with the customer. This is not a confirmed booking: the team confirms availability and the final price.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Required. Travel date as YYYY-MM-DD, e.g. '2026-12-20'. Must be today or later in UAE time. | |
| time | No | Optional. Preferred local pickup time in 24-hour HH:MM, e.g. '07:30'. | |
| notes | No | Optional. Free text for the team: children and child seats, extra stops, special luggage, return trip or other requests. | |
| luggage | No | Optional. Number of large suitcases, 0 to 30. Helps the team pick a vehicle. | |
| language | No | Optional. Follow-up language: 'en' (English, default) or 'ar' (Arabic). | |
| routeSlug | Yes | Required. Exact route slug from search_routes or get_route_details, e.g. 'dubai-to-riyadh-private-transfer'. | |
| passengers | Yes | Required. Total passengers including children, 1 to 7. | |
| vehicleTier | No | Optional. Tier name from the route's price tiers, e.g. 'Premium SUV'. Case-insensitive. Omit if the customer has not chosen. | |
| customerName | Yes | Required. Customer's full name, one line. | |
| agreedToTerms | Yes | Required. true only if the customer has read and agreed to the Terms of Service at https://platinumride.com/terms. The inquiry is rejected otherwise. | |
| customerEmail | No | Customer email address. Give this or customerWhatsApp (at least one is required). | |
| pickupAddress | No | Optional. Pickup address, hotel or airport. Add the flight number for airport pickups. | |
| dropoffAddress | No | Optional. Drop-off address, hotel or airport. | |
| customerWhatsApp | No | WhatsApp number with country code in E.164 format, no spaces, e.g. '+971501234567'. Give this or customerEmail (at least one is required). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, but the description goes well beyond them: it warns that the call is non-idempotent, quantifies the rate limit as 3 per 10 minutes per connection, describes the return payload (inquiry reference plus WhatsApp follow-up link), and clarifies that the inquiry is not a confirmed booking with availability and final price pending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose leads, then constraints, then return behavior, then the caveat that it is not a confirmed booking. Every sentence carries distinct information with no repetition of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter mutation tool with no output schema, the description covers the safety profile, rate limit, idempotency, expected response, and the key business caveat that confirmation is manual. Nothing an agent needs in order 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including the required five and the email/WhatsApp alternation is already documented in the schema. The description adds only indirect guidance, that routeSlug should come from search_routes or get_route_details and that terms agreement is a precondition, which is useful but marginal beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource up front: "Sends a booking request to the Platinumride team." It also draws a clear boundary against the siblings search_routes and get_route_details, so an agent can distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit preconditions are given (customer has chosen a route and agreed to the Terms of Service), explicit exclusions are given (not for browsing or quotes, use search_routes and get_route_details instead), and a hard usage constraint follows (never call twice for the same request, max 3 per 10 minutes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details for one route. Needs a slug from search_routes. If you do not have a slug, call search_routes first. Returns per-vehicle price tiers (indicative 'from' prices in local currency and approx. AED; the team confirms the final price), travel time and distance, border crossings and car-change steps, capacities, inclusions, FAQs and booking links. An unknown or invalid slug returns an error saying no route was found. Call create_inquiry when the customer wants to book.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Exact route slug as returned by search_routes, e.g. 'dubai-to-muscat-private-transfer'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, but the description adds behavior the annotations cannot express: an unknown or invalid slug returns a "no route was found" error, and price tiers are indicative 'from' prices pending team confirmation. The data caveat on pricing is exactly the kind of trust context an agent needs before quoting numbers to a customer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and prerequisite before the return-value inventory, and every sentence carries information. The long enumeration of returned fields (price tiers, travel time, border crossings, car-change steps, capacities, inclusions, FAQs, booking links) is slightly list-heavy but substitutes for a missing output schema, so it largely earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so thoroughly, including pricing caveats, error behavior, and the booking handoff. For a single-parameter read tool with full schema coverage, nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter is already documented with an example, so the baseline is 3. The description adds provenance (the slug must come from search_routes) and failure semantics for a bad slug, which is real meaning beyond the schema, though it does not add format or normalization guidance beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Returns full details for one route") and immediately scopes it to a single route identified by a slug, which cleanly separates it from search_routes (many results) and create_inquiry (booking). An agent can identify the tool's job without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the prerequisite explicitly ("Needs a slug from search_routes") and gives a fallback instruction ("If you do not have a slug, call search_routes first"). It also names the downstream sibling with its trigger condition: "Call create_inquiry when the customer wants to book." Both when-to-use and when-to-switch are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all of Platinumride's published travel guides (currently 13) in one response, with no pagination or filtering. Each entry has a title, cities, route slug and page URL. Pass a guide slug to get that guide's full text, sections and FAQs. Use it for questions about driving time, border documents and what to expect on the road. For prices and booking, use search_routes and get_route_details instead.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional. Guide slug from the list, e.g. 'dubai-to-muscat-travel-guide'. Omit to list all guides. An unknown slug returns an error. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/idempotentHint, it discloses non-obvious behavior: the entire set of 13 guides returns in a single unpaginated response, each entry contains title, cities, route slug and page URL, and a slug request produces full text, sections and FAQs. With no output schema present, this return-shape disclosure is exactly what the description must carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each doing distinct work: scope, return contents, slug mode, then usage and alternatives. Front-loaded with the listing behavior and closed with the sibling routing, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete enough to select and invoke correctly: scope, return shape, alternative tools and slug behavior are all covered. A small residual gap is that the error case for an unknown slug lives only in the schema, not the description, but nothing blocking is missing for a one-parameter read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining what passing a slug actually yields (that guide's full text, sections and FAQs) rather than just restating the field name. The error behavior for an unknown slug is disclosed in the schema rather than the description, so it is not double-counted here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (lists published travel guides), quantifies scope (currently 13), and explicitly rules out pagination and filtering. It also clarifies the dual mode — bare call lists, slug call returns full guide text — and names the siblings it is not (search_routes, get_route_details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use cases ('questions about driving time, border documents and what to expect on the road') plus an explicit exclusion routing pricing and booking to search_routes and get_route_details. The omit-vs-pass slug condition is also spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First step for any trip question. Finds Platinumride private transfer routes when the user names cities, countries, airports (e.g. DXB, RUH) or Arabic city names. Full sentences and common typos are fine. Returns matching routes with summary info: slug, travel time, distance, border crossings, indicative per-vehicle 'from' prices and booking links. For full price tiers, border steps and timing of one route, call get_route_details with a returned slug. Call create_inquiry once the customer wants to book. If nothing matches, the route list is empty and suggestions are returned. Then try another city spelling or ask the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text origin and destination query, a full sentence is fine, e.g. 'Dubai to Muscat with kids', 'Dubai airport to Oman' or 'دبي إلى الرياض'. | |
| to | No | Destination city, airport code or Arabic name, e.g. 'Muscat', 'MCT'. | |
| from | No | Origin city, airport code or Arabic name, e.g. 'Dubai', 'DXB', 'دبي'. | |
| limit | No | Maximum number of results, from 1 to 100. Defaults to 25. | |
| internationalOnly | No | Optional. true returns only routes that cross a border. Omit for all routes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/idempotent profile, and the description adds real substance beyond them: the exact summary fields returned (slug, travel time, distance, border crossings, per-vehicle 'from' prices, booking links) and the empty-result behavior with suggestions. It also states that full sentences and common typos are tolerated, which is behavioral tolerance not visible in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary routing statement, then value, then next steps, then failure handling — a sensible order with little filler. Some overlap between the description's mention of Arabic names and the per-parameter schema text is mildly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does it, listing the summary fields per route. Tool complexity is low (five optional params) and the failure mode, alternatives, and downstream steps are all covered, leaving no obvious gap for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: natural-language queries and misspellings are acceptable inputs, and Arabic transliterations are supported. It does not explain when to prefer the combined `q` field over the structured `from`/`to` pair, which keeps it below a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Finds Platinumride private transfer routes") and narrows the input shape the tool expects: cities, countries, airport codes like DXB/RUH, and Arabic city names. The opening line "First step for any trip question" positions it distinctly from get_route_details and create_inquiry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the two alternative paths and their trigger conditions: get_route_details with a returned slug for full price tiers, and create_inquiry once the customer wants to book. It also handles the no-match case ("try another city spelling or ask the customer"), so the agent has a complete decision tree.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_inquiry14 fields changedInput schema / properties / agreedToTerms / descriptionPrevious value: -"Whether the customer has read and agreed to the Terms of Service at https://platinumride.com/terms. Must be true."New value: +"Required. true only if the customer has read and agreed to the Terms of Service at https://platinumride.com/terms. The inquiry is rejected otherwise."Input schema / properties / customerEmail / descriptionPrevious value: -"Customer email address. At least one email or WhatsApp number is required."New value: +"Customer email address. Give this or customerWhatsApp (at least one is required)."Input schema / properties / customerName / descriptionPrevious value: -"Customer's full name."New value: +"Required. Customer's full name, one line."Input schema / properties / customerWhatsApp / descriptionPrevious value: -"Customer WhatsApp number in E.164 format, e.g. '+971501234567'. At least one WhatsApp number or email is required."New value: +"WhatsApp number with country code in E.164 format, no spaces, e.g. '+971501234567'. Give this or customerEmail (at least one is required)."Input schema / properties / date / descriptionPrevious value: -"Travel date in YYYY-MM-DD format, today or later in UAE time."New value: +"Required. Travel date as YYYY-MM-DD, e.g. '2026-12-20'. Must be today or later in UAE time."Input schema / properties / dropoffAddress / descriptionPrevious value: -"Drop-off address."New value: +"Optional. Drop-off address, hotel or airport."Input schema / properties / language / descriptionPrevious value: -"Customer's preferred language for follow-up."New value: +"Optional. Follow-up language: 'en' (English, default) or 'ar' (Arabic)."Input schema / properties / luggage / descriptionPrevious value: -"Number of large suitcases."New value: +"Optional. Number of large suitcases, 0 to 30. Helps the team pick a vehicle."Input schema / properties / notes / descriptionPrevious value: -"Additional trip details for the Platinumride team."New value: +"Optional. Free text for the team: children and child seats, extra stops, special luggage, return trip or other requests."Input schema / properties / passengers / descriptionPrevious value: -"Number of passengers, 1 to 7."New value: +"Required. Total passengers including children, 1 to 7."Input schema / properties / pickupAddress / descriptionPrevious value: -"Pickup address, hotel or airport, optionally including a flight number."New value: +"Optional. Pickup address, hotel or airport. Add the flight number for airport pickups."Input schema / properties / routeSlug / descriptionPrevious value: -"Route slug, e.g. 'dubai-to-riyadh-private-transfer'."New value: +"Required. Exact route slug from search_routes or get_route_details, e.g. 'dubai-to-riyadh-private-transfer'."Input schema / properties / time / descriptionPrevious value: -"Preferred pickup time, e.g. '07:30'."New value: +"Optional. Preferred local pickup time in 24-hour HH:MM, e.g. '07:30'."Input schema / properties / vehicleTier / descriptionPrevious value: -"Optional vehicle tier name available on the route, e.g. 'Premium SUV'. Matching is case-insensitive."New value: +"Optional. Tier name from the route's price tiers, e.g. 'Premium SUV'. Case-insensitive. Omit if the customer has not chosen."get_route_details1 field changedInput schema / properties / slug / descriptionPrevious value: -"Route slug, e.g. 'dubai-to-muscat-private-transfer'."New value: +"Exact route slug as returned by search_routes, e.g. 'dubai-to-muscat-private-transfer'."list_travel_guides1 field changedInput schema / properties / slug / descriptionPrevious value: -"Optional guide slug identifying the guide whose full content is returned, e.g. 'dubai-to-muscat-travel-guide'."New value: +"Optional. Guide slug from the list, e.g. 'dubai-to-muscat-travel-guide'. Omit to list all guides. An unknown slug returns an error."search_routes1 field changedInput schema / properties / internationalOnly / descriptionPrevious value: -"Whether results are limited to routes with a border crossing."New value: +"Optional. true returns only routes that cross a border. Omit for all routes."search_routes1 field changedInput schema / properties / q / descriptionPrevious value: -"Free-text origin and destination query, e.g. 'DXB to Riyadh' or 'دبي إلى الرياض'."New value: +"Free-text origin and destination query, a full sentence is fine, e.g. 'Dubai to Muscat with kids', 'Dubai airport to Oman' or 'دبي إلى الرياض'."create_inquiryget_route_detailslist_travel_guidessearch_routesPrivate airport & cruise transfers: Gold Coast, Brisbane, Byron Bay (Queensland). Quotes + bookings.
Fixed prices, conditions and booking links for airport transfers in Alanya and Antalya, Türkiye.
Fixed-price quotes and bookings for private airport transfers: Gold Coast, Brisbane, Byron Bay.
Private airport rides from Montego Bay (MBJ) to Jamaican hotels and villas, plus tours
Add one secure layer between your agents and this server.
