Paris private chauffeur: prices incl. VAT (airports, stations, Disneyland). Read-only, no booking.
Scored across 2 tools
Two tools with clearly separate purposes: obtenir_devis returns a priced quote with a booking link, while voir_conditions returns static service terms, vehicle classes and policies. There is no overlap in intent or expected inputs, so an agent cannot mistake one for the other.
Both names follow the same French verb_noun convention (obtenir_devis, voir_conditions), read-only in tone and consistent in language and style. No mixing of camelCase, snake_case or imperative/noun forms.
Two tools is minimal, but the server's scope is deliberately narrow: price quoting plus published terms, with booking and payment handled on the website by design. The surface is well-scoped rather than truncated, though a third helper (e.g. listing vehicle classes or destinations) would make it feel less thin.
The stated purpose — returning a VAT-inclusive price and the rules behind it — is fully covered, including ambiguity, quota and fixed-price edge cases handled inside obtenir_devis. The only gaps are optional conveniences (standalone lists of destinations/vehicle classes, or booking-status lookup), which are out of scope since booking happens on the website.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Drop-off, as text, same advice as "from". Required unless type is "hourly". | |
| pax | No | Number of passengers, 1 to 7. | |
| date | Yes | Pickup date, Paris, YYYY-MM-DD. | |
| from | Yes | Pickup, 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). | |
| lang | No | Language 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 |
| time | Yes | Pickup time, Paris local time, HH:MM (9:30 and 9h30 accepted). | |
| type | No | "oneway" (transfer, default) or "hourly" (chauffeur hire; "to" not needed). | oneway |
| class | No | Vehicle 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). | |
| duration | No | Hours, 3 to 12, required when type is "hourly". |
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.
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.
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.
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.
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.
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.
Service conditions of Precellence Service, generated from the tariff and rules in force: vehicle classes (passengers, luggage, minimum fare, hourly rate), fixed-price zones, long distance, hourly hire, options, waiting time, cancellation and refunds, booking notice, payment (website only), contacts and links. Read-only; no booking, no payment. FR : conditions du service. AR : شروط الخدمة. ES : condiciones del servicio.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of labels. 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent, and closed-world behavior, so the safety profile is covered. The description adds that the content is generated from the tariff and rules in force (implying the data is a snapshot that may change), and re-emphasizes read-only with no booking or payment. It omits details such as whether the content is cached or how often it refreshes, but for a static reference tool this is adequate beyond the annotations.
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 description is front-loaded with the purpose and a well-organized content list, and it ends with the read-only constraint. The trailing FR/AR/ES title translations are somewhat redundant with the schema's language support, but they are brief and could aid discovery. Overall efficient, with minor redundancy.
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 read-only reference tool with one optional parameter and no output schema, the description is complete: it states exactly which sections are covered, confirms no booking or payment occurs, and notes the content source. An agent has everything needed to decide to call it and to set expectations for the response.
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%, and the single lang parameter already documents the enum, fallback behavior, name_lang flag, and booking-link language handling. The description mentions FR/AR/ES title translations, which loosely relate to language, but adds no parameter syntax or behavior beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description names a specific resource (service conditions of Precellence Service) and enumerates the exact content covered: vehicle classes, zones, long distance, hourly hire, options, waiting time, cancellation, booking notice, payment, and contacts. It also states 'Read-only; no booking, no payment,' which directly distinguishes it from the sibling obtenir_devis. An agent can tell what this tool returns without opening 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?
The description provides clear usage context by framing the tool as a read-only reference for tariffs and rules, and by explicitly excluding booking and payment actions ('no booking, no payment'). It does not name obtenir_devis as the alternative for quotes or bookings, but the exclusion makes the boundary inferable. Clear context, though no explicit when-to-use sentence naming alternatives.
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.
obtenir_devisvoir_conditionsBook a private driver in Paris: live quotes, airport transfers, tours, VIP Meet & Greet. No auth.
Chauffeur privé et transferts aéroport à Paris (CDG, Orly, Beauvais) : prix fixes et réservation.
Private airport transfers & chauffeurs in Europe (Paris, Bucharest): live fixed prices and booking.
Fixed London chauffeur prices: airport & cruise transfers, hourly hire, day trips, booking links.
Add one secure layer between your agents and this server.
