Find car washes in France, check live slots, get exact prices and start a booking.
Scored across 8 tools
Each tool targets a distinct step: discovery (find_centers, search_available_slots), inspection (get_center_details, get_services), pricing (quote_booking), guidance (recommend_wash), and booking prep/retrieval (start_booking, get_booking). The main potential confusion is find_centers vs search_available_slots, since both resolve a location and return nearby centres, but their outputs (centres vs slots) clearly differ. No two tools genuinely do the same thing.
All eight names follow a clean verb_noun snake_case pattern (find_centers, get_booking, get_center_details, get_services, quote_booking, recommend_wash, search_available_slots, start_booking). The convention is applied uniformly with no camelCase or vague-verb deviations.
Eight tools is well-scoped for a car-wash discovery and booking-prep server. Each tool maps to a distinct stage of the customer journey and none feels redundant or trivial.
The core flow—find centres, inspect details/services, quote, check slots, prep a booking, and retrieve an owned booking—is covered end to end. Gaps exist around the booking lifecycle: no cancel, modify, or list-my-bookings operations, though the design deliberately hands confirmation/payment to Washlib.
Active car-wash centres near a place, nearest first, from the place as the customer names it (city, district, postal code or centre name). resolvedLocation reports how the place was understood.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Where the customer wants the wash: city, district, postal code or centre name, e.g. "Paris 16", "Levallois", "75017" | |
| radiusKm | No | Search radius in kilometres (default 20, max 50) | |
| serviceType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, so the bar is lower, and the description still adds real behavior: only active centres are returned, results are sorted nearest-first, and resolvedLocation explains location interpretation. It stops short of describing the returned record shape.
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?
Two short sentences, fully front-loaded: the sorting and filter behavior comes first, with the resolvedLocation note as a compact follow-up. No wasted words.
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 three-parameter, read-only discovery tool with no output schema, the description should say more about what comes back (record fields, pagination, limits). It covers ordering, the active filter, and one response field, but leaves the serviceType parameter and the result shape unexplained.
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 67%. The description reinforces the flexible location semantics (city, district, postal code or centre name), duplicating the schema's own text, but adds nothing for serviceType, whose fixed/mobile/home enum values are unexplained in both schema and description. Baseline 3 fits.
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+resource ('car-wash centres') with scope qualifiers: 'Active', 'near a place', 'nearest first'. This is clearly distinguishable from get_center_details or search_available_slots, though no sibling is named explicitly.
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?
Usage is implied by the description (find active centres near a place), and it hints that the location is 'the place as the customer names it', but it never states when to prefer this over siblings like get_center_details or what conditions exclude it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a booking the caller owns. Requires a Firebase phone-OTP token (Authorization: Bearer ); the booking is only returned when its phone number matches the verified caller.
| Name | Required | Description | Default |
|---|---|---|---|
| No | |||
| bookingId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the exact auth mechanism (Firebase phone-OTP Bearer idToken) and the access-control rule that a booking is only returned when its phone matches the verified caller. It doesn't cover failure modes (403 vs 404, rate limits), so it falls short of a 5.
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?
Two sentences, front-loaded with the action and immediately followed by the precondition that governs it. No filler or repetition of the title.
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?
Auth and ownership behavior are well covered, and no output schema exists so return values need not be described. However, the ambiguous optionality of email vs bookingId leaves an agent unsure how to actually invoke the call, which is the main remaining gap.
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 0% and neither the email nor bookingId parameter is explained in the description. Notably both parameters are optional (required: 0), and the description never clarifies whether lookup needs one, the other, or both — a gap the text should have closed.
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 ("Retrieve a booking") and scopes it to bookings the caller owns, which separates it cleanly from siblings like start_booking or quote_booking. An agent can identify the operation 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 ownership/auth framing implies this is for fetching an existing booking rather than creating one, but the description never explicitly states when to prefer it over siblings such as start_booking or quote_booking. No when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one centre: address, phone, opening hours (Paris time), upcoming closures, accepted payment methods (online / on site / card-only), free parking hours, whether it is open now and bookable today, and its vehicle price categories (s/m/l/xl/moto) with example models — prices depend on the category. Fields prefixed untrusted* are text written by the centre operator.
| Name | Required | Description | Default |
|---|---|---|---|
| centerSlug | Yes | Centre slug as returned by find_centers or search_available_slots |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description meaningfully adds that opening hours are in Paris time, that prices vary by category, and — most valuably — that fields prefixed 'untrusted*' are operator-written text, a genuine data-provenance disclosure beyond structured fields.
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 front-loaded sentence opens with the core purpose and then lists return fields; nearly every element earns its place given the absence of an output schema. It is dense and slightly run-on but not padded.
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?
With no output schema, the description appropriately compensates by enumerating return fields, timezone, price-category dependency, and untrusted-field provenance. The main gap is absent guidance on behavior when a slug is invalid or not found.
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% for the single centerSlug parameter, and the schema itself already explains its format and where to obtain it (find_centers/search_available_slots). The description adds nothing about the parameter, so the baseline 3 applies.
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+resource ('Details of one centre') and then enumerates exactly what is returned: address, phone, hours, closures, payment methods, parking, open/bookable status, and price categories. The singular 'one centre' implicitly contrasts with the discovery sibling find_centers, so an agent can distinguish it at a glance.
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?
Usage is only implied — the name and 'one centre' framing suggest a detail lookup after obtaining a slug, but the description never says when to use this versus find_centers or search_available_slots, nor any prerequisites. No exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the services a center offers with a starting price each. centerId is the numeric id from find_centers.
| Name | Required | Description | Default |
|---|---|---|---|
| centerId | Yes | Numeric center id as returned by find_centers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds one useful behavioral fact not in the annotations: the payload includes a starting price per service. It says nothing about ordering, pagination, or what happens for a center with no services.
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?
Two short sentences with zero filler; the capability statement is front-loaded and the parameter prerequisite follows. Nothing is repeated or padded.
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 must carry the return contract, and it only sketches it ('a starting price each') without indicating other service attributes, result shape, or ordering. Combined with the missing sibling differentiation, it is adequate but leaves gaps for a tool with no output schema.
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?
With one parameter at 100% schema description coverage, the baseline is 3. The description's note that centerId is 'the numeric id from find_centers' restates the schema's own parameter description almost verbatim, so it adds no meaning beyond the structured field.
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 (list) and resource (services offered by a center) plus the scope qualifier 'with a starting price each'. An agent can distinguish this from sibling tools like find_centers or get_center_details, though the boundary with get_center_details (which may also surface services) is never addressed.
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 second sentence tells the agent where the id comes from ('the numeric id from find_centers'), which is real prerequisite guidance. However, there is no statement of when this tool is preferable to get_center_details or other siblings, and no exclusions or call-ordering beyond the id source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact price of a basket of services at one centre for a vehicle category, as the booking will charge it: per-line prices, the online-payment discount, off-peak (« heures creuses ») pricing when date and timeSlot are given, and the on-site total. Also returns notIncludedOptions (common needs the basket does not cover, such as seats or pet hair) and thresholdNudge (an option that would unlock the online discount for the same total or less), each possibly empty. An invalid basket returns { error, message } (incompatible_options, missing_formule, service_not_available, online_payment_not_accepted). Promo codes are not accepted here; they are entered on the booking page.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Chosen day, YYYY-MM-DD (Europe/Paris): some slots are cheaper | |
| timeSlot | No | ||
| centerSlug | Yes | Centre slug as returned by find_centers or search_available_slots | |
| serviceIds | Yes | Service ids from get_services: one formule, plus any options | |
| vehicleType | Yes | vehicleTypes.value from get_center_details (s, m, l, xl, moto) — never the label. | |
| paymentMethod | Yes | online = card at booking (often discounted), on_site = at the centre |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: it enumerates return components (per-line prices, online discount, off-peak pricing, on-site total), extra fields (notIncludedOptions, thresholdNudge, possibly empty), and the exact error envelope with four named error codes.
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?
Purpose is front-loaded in the first clause, and the return/error details are packed tightly with no filler. It is somewhat dense and prose-blocked rather than enumerated, but every sentence carries information.
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?
With no output schema, the description fully compensates by describing both success shape (line prices, discounts, totals, optional arrays) and failure shape (error + message with named codes). For a six-parameter quote tool, an agent has everything needed to call and interpret it.
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 already 83%, so the baseline is 3; the description goes further by explaining the conditional interaction (off-peak when date AND timeSlot are given) and tying paymentMethod to the online discount. It does not clarify formatting for the pattern-constrained date/timeSlot beyond the schema, so it is not 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 precise verb+resource: the exact charge a booking would apply to a basket of services at one centre for a vehicle category. It is clearly a pricing/quote operation, distinguishable from siblings like start_booking or get_booking without inspecting either 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?
Gives real context: off-peak pricing applies only when date and timeSlot are supplied, and it explicitly excludes promo codes (entered on the booking page instead). It never names an alternative sibling tool or states the pre-booking timing, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a wash formula for a vehicle given how dirty it is and the season. Pure guidance, no booking.
| Name | Required | Description | Default |
|---|---|---|---|
| season | No | ||
| dirtLevel | Yes | ||
| vehicleType | Yes | e.g. citadine, berline, SUV, utilitaire |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful point that no booking is created, but says nothing about the nature of the recommendation itself (how many options, deterministic or not).
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?
Two tight sentences with zero filler; the action and scope constraint are front-loaded before any detail.
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 burden of describing the return, and 'recommend a wash formula' is only a rough sketch of what comes back. For a low-risk read-only tool this is adequate but thin.
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 only 33% — dirtLevel and season have enums but no prose. The description maps them conceptually ('how dirty it is', 'the season'), which helps interpretation, but adds no enum values or format guidance beyond the schema.
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 (recommend) and resource (wash formula) plus the two driving inputs (dirt level, season). 'Pure guidance, no booking' implicitly separates it from the booking-oriented siblings, though it does not name one explicitly.
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?
'Pure guidance, no booking' implies when this tool is appropriate versus the booking flow, but no alternative tool is named and no prerequisites or exclusions are stated. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open car-wash time slots near a place on a given day: for each centre, its slots with remaining capacity and expected busyness. A slot label such as "09:00 - 11:00" is a 2-hour window whose start is the arrival time. A concrete place (an arrondissement or a town) resolves better than a vague area such as « Paris ouest »; resolvedLocation reports how the place was understood.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Target day in YYYY-MM-DD (Europe/Paris) | |
| location | Yes | City, district, postal code or centre name, e.g. "Paris 16", "Levallois" or "75017" | |
| serviceType | No | Filter: fixed (on-site), mobile, or home service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely new behavioral context: slot labels are 2-hour windows whose start is the arrival time, and resolvedLocation reports how the place was interpreted. That is real added value 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?
Front-loaded with the purpose, then slot-label semantics, then location-resolution guidance. Three sentences, each doing work, with no filler; slightly dense but well ordered.
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?
With no output schema, the description carries the return-value burden and does so: it names remaining capacity, expected busyness, and resolvedLocation. The only untreated gap is pagination or result-count behavior, which is minor for this query 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 goes further by explaining how the location parameter is resolved and how a returned slot label should be interpreted temporally, adding meaning the schema does not carry.
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+resource ('Open car-wash time slots near a place on a given day') and even specifies the granularity of the response ('for each centre, its slots with remaining capacity and expected busyness'). It is unambiguous what the tool does, though it never names a sibling to differentiate from find_centers or recommend_wash.
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?
Usage is implied by the scoping ('near a place on a given day') and there is a useful input-quality hint ('a concrete place resolves better than a vague area such as « Paris ouest »'). However, it gives no when-to-use versus find_centers or recommend_wash routing guidance, so it stops at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepares a booking without creating it: re-checks the slot against live capacity and the basket against the centre, then returns bookingUrl — a washlib.com link that opens the booking form at the contact step with the centre, day, slot, vehicle and services pre-filled — with arrival times and the online / on-site totals. The booking exists only once the customer confirms their phone by SMS and pays, or chooses on-site payment, on Washlib. bookingUrl works only exactly as returned: an altered link loses the pre-fill.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Chosen day, YYYY-MM-DD (Europe/Paris) | |
| timeSlot | Yes | ||
| centerSlug | Yes | Centre slug as returned by find_centers or search_available_slots | |
| serviceIds | Yes | The basket quote_booking priced: one formule, plus options | |
| vehicleType | Yes | vehicleTypes.value from get_center_details (s, m, l, xl, moto) — never the label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds genuinely new behavior beyond them: the booking does not exist until SMS phone confirmation and payment (or on-site payment), the slot and basket are re-validated against live capacity, and bookingUrl is fragile — any alteration breaks the pre-fill. That is the kind of operational detail annotations cannot 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?
Front-loaded with purpose and kept to a handful of dense sentences, each carrying real information. Minor slack in the parenthetical enumeration of pre-filled fields and the arrival/totals clause, but nothing wasted at the sentence level.
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?
With no output schema, the description correctly describes the return payload (bookingUrl, arrival times, online vs on-site totals) and the lifecycle of the booking. The one gap is failure behavior: it says the slot is re-checked against live capacity but never says what the agent gets if the slot or basket no longer holds.
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 80%, so the schema already documents date, centerSlug, serviceIds and vehicleType, including the enum. The description only loosely maps its five inputs onto the pre-filled form fields ('centre, day, slot, vehicle and services') and adds no format, ordering or validation detail beyond the schema, so the baseline 3 applies.
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 gives a specific verb and resource ('prepares a booking without creating it') and immediately scopes what it returns (bookingUrl plus arrival times and totals). It is clearly distinguishable from quote_booking (pricing) and find_centers/search_available_slots (discovery) 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?
Usage context is clear: it belongs at the end of the funnel, consuming the basket that 'quote_booking priced' and re-checking a slot from 'search_available_slots', and it explicitly is not the creation step. However, it never states the ordering as an instruction or names an alternative for when the pre-check fails, so it stops short of explicit when/when-not guidance.
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.
find_centers4 fields changedInput schema / properties / latitudeRemoved value: -{
- "description": "Only a REAL position shared by the user — never a guess",
- "maximum": 90,
- "minimum": -90,
- "type": "number"
-}Input schema / properties / location / descriptionPrevious value: -"Where the customer is or wants the wash, in their words: city, district, postal code, address or centre name, e.g. \"Paris 16\", \"Levallois\", \"75017\". Preferred over coordinates."New value: +"Where the customer wants the wash: city, district, postal code or centre name, e.g. \"Paris 16\", \"Levallois\", \"75017\""Input schema / properties / longitudeRemoved value: -{
- "maximum": 180,
- "minimum": -180,
- "type": "number"
-}Input schema / requiredAdded value: +[
+ "location"
+]search_available_slots1 field changedInput schema / properties / location / descriptionPrevious value: -"City, district, postal code, address or centre name, e.g. \"Paris 16\", \"Levallois\" or \"75017\""New value: +"City, district, postal code or centre name, e.g. \"Paris 16\", \"Levallois\" or \"75017\""get_center_detailsquote_bookingstart_bookingfind_centers4 fields changedInput schema / properties / latitude / descriptionAdded value: +"Only a REAL position shared by the user — never a guess"Input schema / properties / locationAdded value: +{
+ "description": "Where the customer is or wants the wash, in their words: city, district, postal code, address or centre name, e.g. \"Paris 16\", \"Levallois\", \"75017\". Preferred over coordinates.",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / radiusKm / descriptionPrevious value: -"Search radius in kilometres (max 50)"New value: +"Search radius in kilometres (default 20, max 50)"Input schema / requiredRemoved value: -[
- "latitude",
- "longitude",
- "radiusKm"
-]search_available_slots1 field changedInput schema / properties / location / descriptionPrevious value: -"City, postal code, center name or slug, e.g. \"Paris\" or \"75017\""New value: +"City, district, postal code, address or centre name, e.g. \"Paris 16\", \"Levallois\" or \"75017\""find_centersget_bookingget_servicesrecommend_washsearch_available_slotsSearch and book local services in France: real availability, quotes, consented one-tap bookings.
Book parking, car washes, EV charging, gas and auto repair across the US with live pricing.
Find parkings across Europe, get firm prices and ready-to-pay booking links.
French used-car search across LeBonCoin, LaCentrale, L'Argus and more, with price estimates.
Add one secure layer between your agents and this server.
