Quote and book home cleaning in Paris & Île-de-France; request office-cleaning quotes.
Scored across 7 tools
Most tools have clearly distinct purposes: checking area, fetching services, quoting, selecting time slots, booking, and office/post-construction requests are separable. There is minor overlap around post-construction cleaning, where get_post_construction_estimate gives a price range while request_office_quote can also be used for post-construction quote requests, which could cause some hesitation.
All tool names use a consistent snake_case verb_noun pattern: check_area, create_booking, get_*, request_office_quote. The convention is predictable and readable throughout, with no mixed casing or inconsistent verb styles.
Seven tools is well-scoped for a home-cleaning booking service. Each tool corresponds to a meaningful step in the customer journey, and none appear redundant or purely filler.
The surface covers the core sales and booking flow: area check, services, quote, time slots, booking, and office/post-construction inquiries. However, there is no tool to retrieve, modify, reschedule, or cancel an existing booking, which is a notable lifecycle gap for a booking-oriented server.
Check whether a French postcode is in the service area.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | 5-digit French postcode, e.g. 75011 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and determinism profile is fully covered by structured data. The description adds essentially nothing beyond that profile — no information about how the service area is determined, what the result means, or any call constraints.
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 with no filler or redundancy. Every word earns its place.
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 one-parameter read-only check, the description is nearly sufficient: the operation, input domain, and safety profile are all clear. The one gap is that with no output schema, the description does not indicate what the result looks like (e.g. a boolean served/not-served answer), which would help an agent interpret 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%; the schema itself specifies '5-digit French postcode, e.g. 75011'. The description adds no format, validation, or edge-case detail beyond the schema, so the baseline of 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 (check) and a precise resource (whether a French postcode falls in the service area). This is unambiguous and clearly separable from siblings like create_booking, get_quote, or get_services, which are transactional rather than coverage checks.
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?
There is no statement of when to use this tool, no prerequisites, and no mention of alternatives (e.g. whether it should be called before create_booking or get_quote). The only guidance is the implied purpose in the name and title, which is not the same as explicit when-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a home-cleaning booking for the price, date and arrival window the customer agreed to, and returns a secure Stripe payment_url. The booking is confirmed when the customer opens payment_url and saves a card (charged after the cleaning). The link is also emailed to the customer. Requires customer_confirmed = true and extras_offered = true (ask about extras first).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD (today adds a same-day surcharge) | |
| notes | No | Access, pets, priorities... | |
| extras | No | Extras from get_services. Ask the customer before quoting a first cleaning: most add at least one (inside the oven id 11, inside the fridge id 10, windows id 15 with quantity, changing sheets id 12; move-out: Fin de bail id 18). e.g. [{"id":11},{"id":15,"quantity":4}] | |
| address | Yes | ||
| bedrooms | Yes | Number of bedrooms (studio = 1) | |
| customer | Yes | ||
| bathrooms | No | ||
| condition | Yes | ASK the customer, never assume: when the home last had a thorough (professional) clean. recent (<1 month), one_to_six_months, over_six_months (or never). First cleanings are rarely recent. | |
| frequency | No | once, weekly, biweekly (every 2 weeks) or monthly — recurring plans get a discount | once |
| agent_name | No | Name of the assistant/app making the booking | |
| surface_m2 | No | Living area in m² (optional, improves accuracy) | |
| high_ceilings | No | Haussmann building / ceilings over 3 m | |
| arrival_window | Yes | Start of the 2-hour arrival window from get_time_slots, e.g. "14:00" | |
| extras_offered | Yes | true = you asked the customer which extras they want (oven, fridge, windows, sheets...), even if they chose none | |
| customer_confirmed | Yes | true = the customer saw the price and details and asked to book | |
| furnished_occupied | No | Home is furnished and lived in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the generic profile (write, open-world, non-idempotent, non-destructive); the description adds genuinely new behavior: the booking is not confirmed at call time, it confirms only when the customer opens payment_url and saves a card, the card is charged after the cleaning, and the link is emailed. These are exactly the operational facts an agent needs to explain the flow 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?
Three sentences, front-loaded with the action and return value, then the confirmation semantics, then the preconditions. Every sentence carries distinct information with no restatement of the name or 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?
With 16 parameters, nested objects, no output schema and only 81% schema coverage, the description closes the important gaps: what the call returns (payment_url), that confirmation is deferred, and the mandatory preconditions. Remaining detail (pricing inputs, extras ids) is handled adequately by the 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?
Schema coverage is 81%, so the schema already carries most parameter meaning and the baseline is 3. The description adds value by explaining the purpose of the two boolean gates (customer_confirmed and extras_offered) — they are attestations of prior customer interaction, not data about the job — which is the key semantic the schema alone does not convey.
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 states a specific verb and resource ("Creates a home-cleaning booking") and adds the concrete outcome — a Stripe payment_url — plus the confirmation rule. An agent can distinguish this from get_quote or get_services because it is explicitly the terminal booking step carrying the agreed price, date and arrival window.
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 a clear precondition gate: "Requires customer_confirmed = true and extras_offered = true (ask about extras first)", so the agent knows exactly what must happen before calling. It does not explicitly name sibling alternatives (e.g. use get_quote first to obtain the price, get_time_slots for the window), so routing against the sibling list is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price range for a post-construction cleaning (nettoyage fin de travaux / fin de chantier) in Paris/Île-de-France, same calculation as the estimator on menageparfait.fr: HT and TTC (VAT 20%).
| Name | Required | Description | Default |
|---|---|---|---|
| urgent | No | Within 48 h, at a weekend or outside 7:00–20:00 | |
| windows | No | Windows inside and out | |
| premises | No | apartment | |
| condition | No | light = lightly soiled; standard = renovation; heavy = heavy works or new build | standard |
| surface_m2 | Yes | Floor area in m² | |
| rubble_removal | No | Light rubble removal | |
| floor_stripping | No | Cement film / floor stripping |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds real context beyond that: it returns a price range and explicitly reports HT and TTC with 20% VAT — useful output-shape information given there is no output 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?
A single front-loaded sentence that leads with what is priced before the parenthetical aliases and the HT/TTC detail. Efficient and largely free of filler, though the parenthetical French aliases and tax note make it dense.
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 estimation tool with no output schema, the description usefully explains the returned price range and tax treatment, and annotations cover safety. However it omits any routing versus get_quote/request_office_quote and gives no assumptions behind the calculation, leaving gaps for an agent deciding whether this is the right call.
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 86%, so the schema already documents nearly all parameters (urgent, windows, condition, surface_m2, rubble_removal, floor_stripping). The description mentions none of them and adds no syntax or constraint detail beyond the schema, so the baseline 3 is appropriate.
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 states a specific verb+resource (price range for a post-construction cleaning) plus geographic scope (Paris/Île-de-France) and domain framing (nettoyage fin de travaux/fin de chantier). It is clear what the tool produces, though it does not explicitly distinguish itself from sibling estimate tools like get_quote or request_office_quote.
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?
No when-to-use guidance is given and no alternatives are named. With siblings get_quote and request_office_quote in the set, the agent must guess which estimate tool applies to which situation, and the description offers no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact price (same calculation as menageparfait.fr): TTC (show this to the customer), HT, VAT, and the cost after the 50% tax credit if the customer is eligible.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD (today adds a same-day surcharge) | |
| extras | No | Extras from get_services. Ask the customer before quoting a first cleaning: most add at least one (inside the oven id 11, inside the fridge id 10, windows id 15 with quantity, changing sheets id 12; move-out: Fin de bail id 18). e.g. [{"id":11},{"id":15,"quantity":4}] | |
| bedrooms | Yes | Number of bedrooms (studio = 1) | |
| bathrooms | No | ||
| condition | Yes | ASK the customer, never assume: when the home last had a thorough (professional) clean. recent (<1 month), one_to_six_months, over_six_months (or never). First cleanings are rarely recent. | |
| frequency | No | once, weekly, biweekly (every 2 weeks) or monthly — recurring plans get a discount | once |
| surface_m2 | No | Living area in m² (optional, improves accuracy) | |
| high_ceilings | No | Haussmann building / ceilings over 3 m | |
| furnished_occupied | No | Home is furnished and lived in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context by naming the calculation source, listing the returned price components, and noting customer-facing use, but it does not disclose edge cases such as tax-credit eligibility conditions or same-day surcharge behavior beyond what the schema already says.
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 a single compact sentence that front-loads the core purpose and then lists the returned components. There is no filler or repetition.
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 usefully lists the key returned values: TTC, HT, VAT, and the after-tax-credit cost. It is nearly complete for a quote tool, though it could specify output structure or eligibility conditions for the tax credit.
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 high at 89%, so the schema already carries most parameter meaning, including the detailed extras guidance and condition prompt. The description itself adds no parameter-specific semantics, so the baseline of 3 is appropriate.
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 clearly states that this tool returns an exact cleaning price, with TTC, HT, VAT, and post-tax-credit amounts. It is specific about the resource and output, but it does not explicitly distinguish this tool from siblings like get_post_construction_estimate or request_office_quote.
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 only says to show the TTC amount to the customer; it gives no when-to-use guidance, no exclusions, and no comparison to alternative quote or estimate tools. An agent must infer the selection criteria from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ménage Parfait home-cleaning offer in Paris/Île-de-France: price grid (TTC and HT), extras with ids, frequency discounts, area, payment, and when the 50% tax credit may apply.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 useful scope (that tax-credit eligibility is conditionally described), but says nothing about return shape, currency/locale handling, or pagination, despite there being no output 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?
One dense sentence with no filler; the domain and geographic scope come first, followed by the content inventory. Nothing is wasted.
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 parameters and no output schema, the enumeration of returned categories does real work in telling the agent what a response will contain. Missing is any hint of structure or how tiers/extras ids relate, but for a static reference read this is close to sufficient.
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?
The tool takes zero parameters, so the baseline is 4 — there is no argument semantics for the description to carry. The enumerated content list appropriately substitutes for parameter explanation.
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?
Names a specific resource and enumerates its contents precisely (TTC/HT price grid, extras with ids, frequency discounts, area, payment, 50% tax credit). It is clearly a static catalog/introspection tool, distinguishable in substance from quote-generating siblings, though it never says so 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 only implied: the enumeration suggests an agent calls this to learn pricing and conditions before quoting or booking. It never states when to call it versus get_quote, get_post_construction_estimate, or request_office_quote, which is the real ambiguity given four pricing-adjacent siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dates and 2-hour arrival windows that can be requested (up to 90 days ahead). Windows start between 10:00 and 16:00; no evening bookings.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| from_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds genuine domain constraints beyond that: a 90-day booking horizon, 10:00–16:00 window starts, and no evening bookings. It stops short of saying what happens when no slots are available or how results are ordered.
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, front-loaded with the resource returned and followed by the operating constraints. No filler or restated metadata.
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, and the description only loosely sketches the return shape ('dates and 2-hour arrival windows'). Combined with undocumented parameters and no guidance on empty results, the definition is adequate but has clear gaps for a booking-availability lookup.
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%, so the description must explain both parameters, and it explains neither: it never mentions `days` (1–31, default 14) or `from_date` (the search start date). Worse, 'up to 90 days ahead' can be read against the schema's 31-day maximum for `days`, leaving the distinction between search range and booking horizon unresolved.
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 states the resource (dates and 2-hour arrival windows that can be requested), so an agent knows it returns availability rather than performing a booking. It does not explicitly differentiate itself from siblings like create_booking, but the resource noun is specific enough to distinguish it.
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 phrase 'that can be requested' hints this is a pre-booking lookup step, but the description never says when to call it versus create_booking or get_quote, and names no alternatives. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a quote request to Ménage Parfait for office cleaning or post-construction cleaning (reply within 1 business day).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| Yes | |||
| level | No | For post_construction: light, standard or heavy | |
| phone | Yes | ||
| address | No | ||
| company | No | Required for office cleaning | |
| details | No | ||
| service | No | office_regular | |
| postcode | Yes | ||
| frequency | No | e.g. daily, 3x/week, weekly, one-off after works | |
| agent_name | No | ||
| start_date | No | ||
| surface_m2 | No | ||
| contact_name | Yes | ||
| preferred_hours | No | e.g. early morning, evening |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/side-effect profile (readOnly=false, openWorld=true, idempotent=false, destructive=false). The description usefully adds the reply-time expectation (1 business day), but doesn't explain what actually happens on send (e.g. whether it emails the business, whether the request can be resubmitted, or how the different service types behave).
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 efficient sentence, front-loaded with the action and recipient. Nothing is wasted, though the brevity comes at the cost of the details an agent needs.
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 15-parameter mutation tool with low schema coverage and no output schema, the description is far too thin. It omits the conditional field rules, the service-type branches, and any indication of what a caller receives or how to proceed after submission.
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 only 27% schema description coverage across 15 parameters, the description needs to compensate and provides no parameter meaning at all. Required fields (contact_name, email, phone, postcode), the service enum, and conditional requirements like company-for-office are left entirely to 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 (sends a quote request) and resource (office or post-construction cleaning) with the recipient named. It is reasonably distinguishable from get_quote (retrieval) and create_booking (booking), though it doesn't explicitly name those siblings to disambiguate.
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?
No guidance on when to choose this over get_quote, get_post_construction_estimate, or create_booking, and no prerequisites or exclusions are stated. The agent must infer usage entirely from the name and title.
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_booking5 fields changedInput schema / properties / condition / defaultRemoved value: -"recent"Input schema / properties / condition / descriptionPrevious value: -"When the home last had a thorough clean: recent (<1 month), one_to_six_months, over_six_months (or never)"New value: +"ASK the customer, never assume: when the home last had a thorough (professional) clean. recent (<1 month), one_to_six_months, over_six_months (or never). First cleanings are rarely recent."Input schema / properties / extras / descriptionPrevious value: -"Optional extras from get_services, e.g. [{\"id\":11},{\"id\":15,\"quantity\":4}]"New value: +"Extras from get_services. Ask the customer before quoting a first cleaning: most add at least one (inside the oven id 11, inside the fridge id 10, windows id 15 with quantity, changing sheets id 12; move-out: Fin de bail id 18). e.g. [{\"id\":11},{\"id\":15,\"quantity\":4}]"Input schema / properties / extras_offeredAdded value: +{
+ "description": "true = you asked the customer which extras they want (oven, fridge, windows, sheets...), even if they chose none",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "bedrooms",
- "date",
- "arrival_window",
- "customer",
- "address",
- "customer_confirmed"
-]New value: +[
+ "bedrooms",
+ "condition",
+ "date",
+ "arrival_window",
+ "customer",
+ "address",
+ "customer_confirmed",
+ "extras_offered"
+]get_quote4 fields changedInput schema / properties / condition / defaultRemoved value: -"recent"Input schema / properties / condition / descriptionPrevious value: -"When the home last had a thorough clean: recent (<1 month), one_to_six_months, over_six_months (or never)"New value: +"ASK the customer, never assume: when the home last had a thorough (professional) clean. recent (<1 month), one_to_six_months, over_six_months (or never). First cleanings are rarely recent."Input schema / properties / extras / descriptionPrevious value: -"Optional extras from get_services, e.g. [{\"id\":11},{\"id\":15,\"quantity\":4}]"New value: +"Extras from get_services. Ask the customer before quoting a first cleaning: most add at least one (inside the oven id 11, inside the fridge id 10, windows id 15 with quantity, changing sheets id 12; move-out: Fin de bail id 18). e.g. [{\"id\":11},{\"id\":15,\"quantity\":4}]"Input schema / requiredPrevious value: -[
- "bedrooms"
-]New value: +[
+ "bedrooms",
+ "condition"
+]get_post_construction_estimaterequest_office_quote4 fields changedInput schema / properties / company / descriptionAdded value: +"Required for office cleaning"Input schema / properties / levelAdded value: +{
+ "description": "For post_construction: light, standard or heavy",
+ "type": "string"
+}Input schema / properties / serviceAdded value: +{
+ "default": "office_regular",
+ "enum": [
+ "office_regular",
+ "post_construction",
+ "other"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "company",
- "contact_name",
- "email",
- "phone",
- "postcode"
-]New value: +[
+ "contact_name",
+ "email",
+ "phone",
+ "postcode"
+]check_areacreate_bookingget_quoteget_servicesget_time_slotsrequest_office_quoteCalculate and send commercial cleaning offers with your company rates; find customers and sites.
Quote, hold and book US house cleaning jobs on a customer's behalf, at each business's own prices.
Search and book local services in France: real availability, quotes, consented one-tap bookings.
Book a private driver in Paris: live quotes, airport transfers, tours, VIP Meet & Greet. No auth.
Add one secure layer between your agents and this server.
