SzuruSzuru – rezerwacja czyszczenia tapicerki

Przygotuj rezerwację

prepare_booking

Idempotent

PURPOSE: Step 1 of 2 of booking. Holds the chosen slot for 10 minutes and sends a 6-digit SMS code to the customer's Polish mobile. Returns confirmation_id and a summary to show verbatim. Does NOT create a booking. WHEN TO USE: Only after the customer explicitly said they want to book THIS slot, gave first and last name, street address with number and mobile phone, and accepted the terms. WHEN NOT TO USE: Not for price or date questions, not when the customer says "maybe" or only asks how much / when. Never guess or invent missing data - ask. REQUIRED: quote_id, slot_id (from check_availability), customer.name, customer.address, customer.phone, terms_accepted=true. Missing data -> error missing_required_fields with missing_fields[]. SIDE EFFECTS: one SMS to the phone + 10-minute slot hold. The identical call repeated returns the same confirmation_id, no new SMS. NEXT: ask the customer for the SMS code, then call create_booking.

Input Schema

TableJSON Schema

Name	Required	Description
`notes`	No	Optional note for the cleaner (fabric type, stains, parking)
`slot_id`	Yes	slot_id chosen by the customer from check_availability
`customer`	Yes
`quote_id`	Yes	quote_id from calculate_quote
`session_id`	No	Optional. session_id from the previous result, if you have it. The server also recovers the session from quote_id / slot_id / confirmation_id / customer_grant.
`invoice_data`	No	Optional, only if the customer wants a company invoice
`terms_accepted`	Yes	true only if the customer explicitly accepted the terms and consents. false -> the server returns the consent text to show.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No
`error`	No	Stable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability
`total`	No
`status`	No
`message`	No
`success`	Yes	true = operation done / data returned; false = see error
`summary`	No
`currency`	No
`expires_at`	No
`session_id`	No
`code_sent_to`	No
`missing_fields`	No
`booking_created`	No
`confirmation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedOct 1, 2026

changedInput schema / properties / customer / properties / address / description

Previous value: -"Street and house/flat number"New value: +"Street and house/flat number, e.g. \"Grunwaldzka 12/3\""

addedInput schema / properties / customer / properties / city / description
```
Added value: +"Optional; derived from the postal code of the quote"
```

changedInput schema / properties / customer / properties / name / description

Previous value: -"First and last name"New value: +"First and last name, e.g. \"Jan Kowalski\""

changedInput schema / properties / customer / properties / phone / description

Previous value: -"Polish mobile number (optional when the customer is signed in)"New value: +"Polish mobile number (9 digits, optional +48) - receives the SMS code. Required unless the customer is signed in."

addedInput schema / properties / invoice_data / description

Added value: +"Optional, only if the customer wants a company invoice"

addedInput schema / properties / quote_id / description
```
Added value: +"quote_id from calculate_quote"
```

addedInput schema / properties / session_id / description

Added value: +"Optional. session_id from the previous result, if you have it. The server also recovers the session from quote_id / slot_id / confirmation_id / customer_grant."

addedInput schema / properties / slot_id / description

Added value: +"slot_id chosen by the customer from check_availability"

changedInput schema / properties / terms_accepted / description

Previous value: -"Customer accepted the terms and the consent text (must be true)"New value: +"true only if the customer explicitly accepted the terms and consents. false -> the server returns the consent text to show."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "booking_created": {
+      "type": "boolean"
+    },
+    "code": {
+      "type": "string"
+    },
+    "code_sent_to": {
+      "type": "string"
+    },
+    "confirmation_id": {
+      "type": "string"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "error": {
+      "description": "Stable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability",
+      "type": "string"
+    },
+    "expires_at": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "missing_fields": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "session_id": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "success": {
+      "description": "true = operation done / data returned; false = see error",
+      "type": "boolean"
+    },
+    "summary": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

First observedSep 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare destructiveHint=false, idempotentHint=true and openWorldHint=false, but the description adds material behavior beyond them: the 10-minute hold, the outbound SMS side effect to the customer's phone, the idempotency contract (same confirmation_id, no duplicate SMS), and the missing_required_fields error shape. This is a genuinely informative mutation contract.

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?

Labeled sections (PURPOSE/WHEN TO USE/WHEN TO NOT USE/REQUIRED/SIDE EFFECTS/NEXT) put the highest-value facts first with zero filler. Long but every clause carries operational information.

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?

For a stateful two-step booking flow, it supplies preconditions, side effects, error contract, idempotency and the explicit next step (collect SMS code, call create_booking). With an output schema present it correctly avoids describing return values, and nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 quote_id, slot_id, customer fields and terms_accepted. The description mainly restates the required list rather than adding new meaning (e.g. it does not explain the phone-optional-when-signed-in rule that the schema itself carries). Baseline 3 is appropriate.

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?

States a precise verb and resource ('Step 1 of 2 of booking... Holds the chosen slot for 10 minutes and sends a 6-digit SMS code'), and explicitly negates the closest sibling with 'Does NOT create a booking.' An agent can distinguish it from create_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.

Usage Guidelines5/5

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

Provides explicit WHEN TO USE preconditions (customer confirmed this slot, gave name/address/phone, accepted terms) and a WHEN TO NOT USE clause covering price/date questions and vague 'maybe' intent, plus a 'never guess' instruction. Routing against siblings like calculate_quote and check_availability is unambiguous.

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

All SzuruSzuru – rezerwacja czyszczenia tapicerki 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?