Ménage Parfait

Book a home cleaning (customer confirms by payment link)

create_booking

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).

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 27, 2026

removedInput schema / properties / condition / default
```
Removed value: -"recent"
```

changedInput schema / properties / condition / description

Previous 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."

changedInput schema / properties / extras / description

Previous 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}]"

addedInput schema / properties / extras_offered

Added value: +{
+  "description": "true = you asked the customer which extras they want (oven, fridge, windows, sheets...), even if they chose none",
+  "type": "boolean"
+}

changedInput schema / required

Previous value: -[
-  "bedrooms",
-  "date",
-  "arrival_window",
-  "customer",
-  "address",
-  "customer_confirmed"
-]New value: +[
+  "bedrooms",
+  "condition",
+  "date",
+  "arrival_window",
+  "customer",
+  "address",
+  "customer_confirmed",
+  "extras_offered"
+]

First observedOct 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Ménage Parfait 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?