Skip to main content
Glama

SzuruSzuru – rezerwacja czyszczenia tapicerki

by pl.szuruszuru
OverviewDiscussionsAdmin

Potwierdź rezerwację

create_booking
Idempotent

PURPOSE: Step 2 of 2 of booking. Creates the real, confirmed SzuruSzuru booking for a confirmation_id from prepare_booking, using the 6-digit SMS code the customer received. WHEN TO USE: Only after prepare_booking succeeded and the customer has typed the SMS code in the conversation. WHEN NOT TO USE: Never to check price or availability, never without a code from the customer, never with a guessed or example code. REQUIRED: confirmation_id, sms_code. idempotency_key optional. Missing data -> error missing_required_fields; nothing is created. SIDE EFFECTS: creates a booking (a technician is scheduled) and sends SMS/e-mail confirmation to the customer. Idempotent: repeating the call with the same confirmation_id and code returns the SAME booking - it never creates a second one. RESULT: success=true, booking_id, status, date, time (Polish time), price, currency. Give these to the customer. Wrong code -> error verification_failed with attempts_left.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sms_codeYes6-digit code the customer received by SMS
session_idNoOptional. 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.
confirmation_idYesconfirmation_id from prepare_booking
idempotency_keyNoOptional. Same value when retrying the same request. If omitted, the server derives the key from the request, so a retry never creates a second booking.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
dateNoYYYY-MM-DD, Polish time
timeNoHH:MM, Polish time
errorNoStable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability
priceNo
totalNo
end_atNo
statusNo
messageNo
successYestrue = operation done / data returned; false = see error
currencyNo
start_atNo
duplicateNo
booking_idNoBooking reference to give the customer (same as booking_reference)
can_cancelNo
session_idNo
can_rescheduleNo
missing_fieldsNo
service_summaryNo
booking_referenceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / confirmation_id / description
      Added value: +"confirmation_id from prepare_booking"
    • addedInput schema / properties / idempotency_key / description
      Added value: +"Optional. Same value when retrying the same request. If omitted, the server derives the key from the request, so a retry never creates a second booking."
    • 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 / sms_code / description
      Added value: +"6-digit code the customer received by SMS"
    • changedInput schema / required
      Previous value: -[
-  "confirmation_id",
-  "sms_code",
-  "idempotency_key"
-]New value: +[
+  "confirmation_id",
+  "sms_code"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "booking_id": {
+      "description": "Booking reference to give the customer (same as booking_reference)",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "booking_reference": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "can_cancel": {
+      "type": "boolean"
+    },
+    "can_reschedule": {
+      "type": "boolean"
+    },
+    "code": {
+      "type": "string"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "date": {
+      "description": "YYYY-MM-DD, Polish time",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "duplicate": {
+      "type": "boolean"
+    },
+    "end_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Stable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability",
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "missing_fields": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "price": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "service_summary": {
+      "type": "string"
+    },
+    "session_id": {
+      "type": "string"
+    },
+    "start_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "type": "string"
+    },
+    "success": {
+      "description": "true = operation done / data returned; false = see error",
+      "type": "boolean"
+    },
+    "time": {
+      "description": "HH:MM, Polish time",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "total": {
+      "type": [
+        "number",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing side effects (technician scheduled, SMS/e-mail sent to customer), the idempotency mechanism, and named error modes (missing_required_fields, verification_failed with attempts_left). The annotations confirm idempotentHint/destructiveHint, and the prose adds the operational detail they 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.

Conciseness5/5

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

Front-loaded with labeled sections (PURPOSE, WHEN TO USE/NOT, REQUIRED, SIDE EFFECTS, RESULT) that let an agent skim in priority order. Length is justified by a two-step, side-effecting, idempotent booking flow.

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 mutation tool with output schema present, the description supplies everything needed: prerequisites, failure modes, idempotency guarantees, and what success returns. No gaps remain for correct invocation.

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 100%, so the schema already documents all four parameters, including the retry semantics of idempotency_key. The description restates required vs optional but adds no syntax or format 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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Creates the real, confirmed SzuruSzuru booking') and explicitly frames it as step 2 of 2 tied to prepare_booking, which cleanly separates it from the sibling that produces the confirmation_id.

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?

Contains dedicated WHEN TO USE and WHEN NOT TO USE sections, including the specific precondition (prepare_booking succeeded and the customer typed the SMS code) and explicit exclusions ('never to check price or availability, never without a code').

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 toolsInspect
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