Skip to main content
Glama

Precellence Service — Paris chauffeur prices

Get a quote — Precellence Service (Paris chauffeur)

obtenir_devis
Read-onlyIdempotent

Prices including VAT, per vehicle, for a private chauffeur trip in Paris and the Île-de-France region (airports, stations, hotels, addresses), or for hourly chauffeur hire, computed by the Precellence Service website pricing engine. Returns one price per vehicle class (or "on_request" with a clear reason), and a pre-filled booking link (booking_url) to the website. This tool does NOT book and does NOT take any payment: the traveller books and pays on the website only, where the same price is recomputed and then guaranteed. No card details are used or needed by this tool. Addresses are plain text, ideally the full postal address with the postcode (e.g. "15 avenue Montaigne, 75008 Paris"); a station, airport or terminal name also works. Date and time are Paris local time. A well-known Paris place ("Place de l'Opéra", palaces and 5-star hotels such as the "Ritz"), a street with its city or postcode, an arrondissement alone ("Paris 13", "75013": its town hall), a city alone or a published destination alone ("Lyon", "Reims") gives a price with exact_address_required (address_estimate): the website asks for the exact address before payment; price_is_estimate is true only when that price may still change with the exact address, false for a fixed price (Paris ↔ CDG / Orly, Paris ↔ Lyon). A name shared by several places ("Valence", "Saint-Denis", "La Rochelle", "13e arrondissement", a street found in several cities) returns status "on_request", reason "address_ambiguous" and the candidates (each reason.candidates[].value can be sent back as from / to); the tool never picks one by default. Shared server limits: 30 computed quotes per minute and 5000 units per day for all users; identical requests within 10 minutes return the same cached answer. Fair use: The automatic quote (public API and MCP server) is free and shared by all assistants. To keep it free, address and route computations are capped each month for all assistants together, and bursts are limited (60 computed quotes per minute per IP address for the API, 30 per minute for the whole MCP server). Always answered, even at the monthly limit: trips between a Paris address with a postcode (75001 to 75020, 75116) and an airport, a main Paris railway station, Disneyland, La Défense or Versailles, which have a fixed price. The places of the tariff (airports, stations, destinations) are recognised by their name, and French addresses with a postcode are located with the Base Adresse Nationale (IGN Géoplateforme, Licence Ouverte). At the monthly limit: a normal answer, not an error, with status "quota_reached", a plain-language message, the pre-filled booking link (booking_url) and, when the trip has a fixed price, that price. On a burst: HTTP 429 (API) or JSON-RPC error -31429 (MCP), with the waiting time (Retry-After) and the same link. What to do: give the full postal address with the postcode (for example "15 avenue Montaigne, 75008 Paris") rather than a hotel name, then send the traveller to booking_url: the website computes the exact price at once. A block is never an outage: the website and the booking link always work. FR : devis TTC par véhicule, sans réservation ni paiement (lien booking_url vers le site). AR : عرض سعر شامل الضريبة لكل سيارة، دون حجز أو دفع (رابط booking_url إلى الموقع). ES : presupuesto con IVA por vehículo, sin reserva ni pago (enlace booking_url al sitio web).

Input Schema

NameRequiredDescriptionDefault
toNoDrop-off, as text, same advice as "from". Required unless type is "hourly".
paxNoNumber of passengers, 1 to 7.
dateYesPickup date, Paris, YYYY-MM-DD.
fromYesPickup, as text: full postal address with the postcode (number, street, postcode, city) — best —, or a station, airport or terminal name; a hotel name alone may need a paid lookup (see fair use).
langNoLanguage of messages and of the booking link. One of the 7 website languages: fr, en, ar, es, tr, ru, zh. Texts exist in fr, en, ar, es; tr, ru, zh get English texts (field "lang" of the answer = language served). Names read from the tariff (classes, zones, destinations) that have no version in the language served are given in English and flagged by "name_lang". Booking link: booking form in fr, en, ar, es; English booking form for tr, ru, zh.fr
timeYesPickup time, Paris local time, HH:MM (9:30 and 9h30 accepted).
typeNo"oneway" (transfer, default) or "hourly" (chauffeur hire; "to" not needed).oneway
classNoVehicle class to pre-select in the booking link (business = Mercedes E-Class, electric = Mercedes EQE, first = Mercedes S-Class, van = Mercedes V-Class, ev = Mercedes EQV; special = on request).
durationNoHours, 3 to 12, required when type is "hourly".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses the free-of-charge shared quota model, the exact limits (30 computed quotes/minute, 5000 units/day, 60/minute per IP), that identical requests within 10 minutes return a cached answer, and that a monthly cap yields a normal status "quota_reached" answer while a burst yields HTTP 429 / JSON-RPC -31429 with Retry-After. It also clarifies that no card details are used, that prices are recomputed and guaranteed on the website, and that price_is_estimate is false for fixed routes such as Paris ↔ CDG/Orly/Lyon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense block that buries key routing guidance inside a long fair-use and legal-attribution passage (Base Adresse Nationale, IGN Géoplateforme, Licence Ouverte). Several points are repeated near-verbatim — the postal-address example "15 avenue Montaigne, 75008 Paris" appears twice, and "free and shared by all assistants" is restated three times. The multilingual one-line summaries at the end are useful but add further bulk to an already over-long definition.

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 9-parameter pricing tool with no output schema, the description covers everything an agent needs: input formatting, ambiguity and estimate outcomes, quota and burst failure modes, and the explicit guarantee that the site and booking link still work when a call is blocked. Nothing material about correct invocation is missing.

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 baseline is 3. The description does add some meaning the schema lacks, notably how ambiguous place names such as "Valence" or "Saint-Denis" surface candidates that can be echoed back as from/to, and that date/time are Paris local time. Since the per-field semantics (class mapping, lang fallback, hourly duration) are already fully spelled out in the schema, the added value is modest above baseline.

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 opening states a concrete verb and resource ("Prices including VAT, per vehicle, for a private chauffeur trip in Paris and the Île-de-France region ... or for hourly chauffeur hire") and sharply draws the boundary "This tool does NOT book and does NOT take any payment". The only gap against a 5 is that the sibling voir_conditions is never named, so the distinction from it is left implicit.

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 operative guidance: send a full postal address with postcode rather than a hotel name, then route the traveller to booking_url. It also explains the handling paths (ambiguous addresses return candidates to resend as from/to; approximate addresses return exact_address_required). It stops short of telling the agent when to prefer a different tool, since voir_conditions is never mentioned.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources