SzuruSzuru – rezerwacja czyszczenia tapicerki

Moje rezerwacje

get_my_bookings

Read-onlyIdempotent

PURPOSE: Lists the verified customer's bookings from the last 90 days (or one booking by booking_reference): reference, services, date, time, price, status, can_reschedule, can_cancel. WHEN TO USE: When the customer asks about their existing booking(s). WHEN NOT TO USE: Not for new bookings. Without customer_grant it returns error verification_required - then run start_phone_verification -> verify_phone_code. REQUIRED: customer_grant (or a signed-in customer). SIDE EFFECTS: none (read-only). Never shows other customers' data.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`customer_grant`	No	customer_grant returned by verify_phone_code
`booking_reference`	No	Optional: one booking instead of the list

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No
`date`	No	YYYY-MM-DD, Polish time
`time`	No	HH:MM, Polish time
`count`	No
`error`	No	Stable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability
`price`	No
`total`	No
`end_at`	No
`status`	No
`message`	No
`success`	Yes	true = operation done / data returned; false = see error
`bookings`	No
`currency`	No
`start_at`	No
`booking_id`	No	Booking reference to give the customer (same as booking_reference)
`can_cancel`	No
`session_id`	No
`can_reschedule`	No
`missing_fields`	No
`service_summary`	No
`booking_reference`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedInput schema / properties / customer_grant / description

Added value: +"customer_grant returned by verify_phone_code"

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

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"
+      ]
+    },
+    "bookings": {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "can_cancel": {
+      "type": "boolean"
+    },
+    "can_reschedule": {
+      "type": "boolean"
+    },
+    "code": {
+      "type": "string"
+    },
+    "count": {
+      "type": "integer"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "date": {
+      "description": "YYYY-MM-DD, Polish time",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "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"
+}

First observedSep 20, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds the 90-day retention window, the verification_required error contract with its remediation chain, and the data-isolation guarantee ('Never shows other customers' data'). 'SIDE EFFECTS: none (read-only)' duplicates the annotation, which keeps it 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.

Conciseness5/5

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

Labeled blocks (PURPOSE / WHEN TO USE / WHEN NOT TO USE / REQUIRED / SIDE EFFECTS) front-load the decision-relevant information, and every line carries a distinct fact with no filler.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. The remaining gaps an agent would care about, auth path and error recovery, are both stated, so nothing material 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 coverage is 100%, so the schema already documents all three parameters including session_id recovery and the booking_reference pattern. The description only restates the booking_reference list-vs-single switch, adding no syntax or format detail beyond the schema; baseline 3 is correct.

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?

Opens with a specific verb+resource ('Lists the verified customer's bookings') and scopes it to a 90-day window plus the single-booking alternative via booking_reference. The listed return fields (reference, services, date, status, can_reschedule, can_cancel) make the distinction from create_booking/cancel_booking/reschedule_booking unambiguous.

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?

Explicit WHEN TO USE ('customer asks about existing booking(s)') and WHEN NOT TO USE ('not for new bookings'), plus a named recovery path: on verification_required run start_phone_verification -> verify_phone_code. This routes the agent to siblings with the exact triggering condition.

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?