Côte Privée: private driver in Burgundy

Exact price for a trip

quote

Read-onlyIdempotent

The exact price the booking page charges for one service, or a whole trip (items: one total, one deposit), the page of the priced service to cite (url; pricesUrl: every price) and a link that opens the booking page filled in (time, guests and bags too). Wine day: option and stops; a day too short for its stops is priced as the one they need (optionRaised). Driver: hours (and stops), or to from Beaune or from; returnTrip: the driver waits up to 3 h; returnLater: back later (2 rides). Transfer: route (its id, its page slug such as lyon-beaune, or a name such as "Lyon airport"), or from and to. A Mercedes adds its supplement per day of service; over 4 guests, the V-Class (carRaised). resolved: what each name became (an unknown place or route is an error with candidates); alternatives: cheaper products for the same job; availability: with date.

Input Schema

Name	Required	Description
`to`	No	A place id or name, or event:<id>.
`car`	No	polestar (included), eclass (4 guests) or vclass (7): the Mercedes on request, a supplement per day of service.
`date`	No
`from`	No	Start of a driver trip, or of a transfer to another place; airfields by ICAO code.
`lang`	No	ar: Arabic notes, data in English.
`time`	No	Pickup (a transfer to Beaune: the arrival).
`hours`	No	Driver by the hour.
`items`	No	Several services (at most 6), each with the fields above.
`notes`	No	For the driver: estates to visit, child seats…
`route`	No	A transfer route, by id or page slug (lyon (lyon-beaune), paris (paris-beaune), dijon (dijon-beaune), geneva (geneva-beaune), creusot (le-creusot-tgv-beaune), lfsd (dijon-airport-beaune), lfgj (dole-jura-airport-beaune)) or by name ("Lyon airport", "Dijon-Bourgogne", "Dole"): a transfer to or from Beaune (creusot: Le Creusot TGV; lfsd, lfgj: the airports).
`stops`	No	Places of a wine day, or of the driver by the hour.
`guests`	No	4 in the Polestar 2 or the E-Class, 7 in the V-Class.
`option`	No	Wine day: half 4 h, full 8 h, long 12 h.
`luggage`	No	Bags.
`service`	No
`extraHours`	No	Wine day; default what its stops need.
`returnTrip`	No	Driver: back the same day, the driver waiting. Transfer: a trip back another day.
`returnLater`	No	Driver: back later the same day (two rides).

Output Schema

Name	Required	Description	Default
`car`	Yes
`url`	Yes
`date`	No
`fits`	No
`time`	No
`drive`	No
`price`	Yes
`title`	Yes
`guests`	Yes
`option`	No
`balance`	No
`bookUrl`	Yes
`deposit`	Yes
`details`	Yes
`luggage`	No
`service`	Yes
`currency`	Yes
`notFound`	Yes
`resolved`	Yes
`services`	No
`carRaised`	No
`maxGuests`	Yes
`pricesUrl`	Yes
`extraHours`	No
`perVehicle`	Yes
`alternatives`	No
`availability`	No
`optionRaised`	No
`servicePrice`	Yes
`tastingsIncluded`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedOct 27, 2026

changedInput schema / properties / route / description

Previous value: -"Transfer to or from Beaune (creusot: Le Creusot TGV; lfsd, lfgj: airports)."New value: +"A transfer route, by id or page slug (lyon (lyon-beaune), paris (paris-beaune), dijon (dijon-beaune), geneva (geneva-beaune), creusot (le-creusot-tgv-beaune), lfsd (dijon-airport-beaune), lfgj (dole-jura-airport-beaune)) or by name (\"Lyon airport\", \"Dijon-Bourgogne\", \"Dole\"): a transfer to or from Beaune (creusot: Le Creusot TGV; lfsd, lfgj: the airports)."

removedInput schema / properties / route / enum

Removed value: -[
-  "lyon",
-  "paris",
-  "dijon",
-  "geneva",
-  "creusot",
-  "lfsd",
-  "lfgj"
-]

addedInput schema / properties / route / maxLength
```
Added value: +120
```

addedOutput schema / properties / pricesUrl

Added value: +{
+  "format": "uri",
+  "type": "string"
+}

addedOutput schema / properties / services / items / properties / url
```
Added value: +{
+  "format": "uri",
+  "type": "string"
+}
```

changedOutput schema / properties / services / items / required

Previous value: -[
-  "service",
-  "title",
-  "details",
-  "servicePrice"
-]New value: +[
+  "service",
+  "title",
+  "details",
+  "servicePrice",
+  "url"
+]

addedOutput schema / properties / url

Added value: +{
+  "format": "uri",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "service",
-  "title",
-  "details",
-  "price",
-  "servicePrice",
-  "car",
-  "currency",
-  "perVehicle",
-  "guests",
-  "maxGuests",
-  "deposit",
-  "tastingsIncluded",
-  "resolved",
-  "notFound",
-  "bookUrl"
-]New value: +[
+  "service",
+  "title",
+  "details",
+  "price",
+  "servicePrice",
+  "car",
+  "currency",
+  "perVehicle",
+  "guests",
+  "maxGuests",
+  "deposit",
+  "tastingsIncluded",
+  "resolved",
+  "notFound",
+  "url",
+  "pricesUrl",
+  "bookUrl"
+]

First observedOct 27, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Beyond readOnly/idempotent annotations, the description discloses concrete behavior: totals and deposits for items, generated booking links, optionRaised when stops exceed a day, carRaised for groups over four, resolved-name errors with candidates, cheaper alternatives, and availability with a date. These are meaningful behavioral details that help an agent understand outcomes.

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

Conciseness3/5

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

All the information is relevant, but it is delivered as a dense run-on block with semicolons and parenthetical clauses. It is front-loaded with the core pricing purpose, yet the structure makes it harder to parse than necessary.

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?

For an 18-parameter tool with multiple service modes, output schema, and annotations, the description covers the main modes and important edge behaviors. It is mostly complete, though it could more explicitly connect service selection to required field combinations.

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 high at 89%, so the baseline is 3, but the description adds real meaning for many parameters: returnTrip versus returnLater semantics, route slug/name forms, service-specific field requirements, and raised-option/car behavior. Some terms remain terse, but overall it meaningfully supplements the schema.

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 specific pricing task: the exact price the booking page charges for one service or a whole trip. It is clear what resource is being priced, but it does not explicitly distinguish itself from siblings such as get_prices or check_availability, so sibling differentiation is missing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives service-specific conditions: wine day needs option and stops, driver needs hours or route, transfer needs route or from/to. However, it never explicitly says when to use this tool instead of get_prices, check_availability, or other siblings, so usage is only implied.

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

All Côte Privée: private driver in Burgundy 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?