Skip to main content
Glama

SzuruSzuru – rezerwacja czyszczenia tapicerki

by pl.szuruszuru
OverviewDiscussionsAdmin

Sprawdź terminy

check_availability
Read-only

PURPOSE: Returns real, currently free appointment slots for a quote_id (new booking) or for an existing booking_reference (rescheduling, needs customer_grant). WHEN TO USE: When the customer asks when we can come, after calculate_quote. wanted.type: asap (earliest), date (one day), range (from-to), preferred (a day + nearby days, sorted by preferred_time); optional part_of_day. If type is omitted it follows the fields given (date -> date, from/to -> range, nothing -> asap). WHEN NOT TO USE: Never to book - it reserves nothing and holds no slot. REQUIRED: quote_id (or booking_reference + customer_grant). Dates as YYYY-MM-DD, Polish time. SIDE EFFECTS: none (read-only; slot_id values are valid ~15 minutes). RESULT: slots found -> success=true, slots[]. None in the requested period -> success=false, error="no_availability", next_available (date or null) and alternative_slots[] - offer those. Past date -> error date_in_past; beyond the online booking horizon -> error date_out_of_range. Never invent a slot.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wantedNoOptional preference; empty = earliest slots
quote_idNoquote_id from calculate_quote (new booking)
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.
customer_grantNocustomer_grant returned by verify_phone_code
booking_referenceNoExisting booking to reschedule (requires customer_grant)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNo
errorNoStable machine-readable error id when success=false, e.g. missing_required_fields, unsupported_postcode, no_availability
slotsNo
reasonNo
messageNo
successYestrue = operation done / data returned; false = see error
searchedNo
session_idNo
missing_fieldsNo
next_availableNo
alternative_slotsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changed
    • addedInput schema / properties / booking_reference / description
      Added value: +"Existing booking to reschedule (requires customer_grant)"
    • changedInput schema / properties / customer_grant / description
      Previous value: -"From verify_phone_code (only for booking_reference)"New value: +"customer_grant returned by verify_phone_code"
    • addedInput schema / properties / quote_id / description
      Added value: +"quote_id from calculate_quote (new 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 / wanted / description
      Added value: +"Optional preference; empty = earliest slots"
    • addedInput schema / properties / wanted / properties / date / description
      Added value: +"YYYY-MM-DD (for date / preferred)"
    • addedInput schema / properties / wanted / properties / from / description
      Added value: +"YYYY-MM-DD (for range)"
    • addedInput schema / properties / wanted / properties / part_of_day / description
      Added value: +"morning <12:00, afternoon 12-16, evening >=16:00"
    • addedInput schema / properties / wanted / properties / to / description
      Added value: +"YYYY-MM-DD (for range, max 30 days)"
    • removedInput schema / properties / wanted / properties / type / default
      Removed value: -"asap"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "alternative_slots": {
+      "items": {
+        "properties": {
+          "date": {
+            "type": "string"
+          },
+          "priority_fee": {
+            "type": "number"
+          },
+          "slot_id": {
+            "type": "string"
+          },
+          "start_at": {
+            "type": "string"
+          },
+          "time": {
+            "type": "string"
+          },
+          "total": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "code": {
+      "type": "string"
+    },
+    "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"
+    },
+    "next_available": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reason": {
+      "type": "string"
+    },
+    "searched": {
+      "type": "object"
+    },
+    "session_id": {
+      "type": "string"
+    },
+    "slots": {
+      "items": {
+        "properties": {
+          "date": {
+            "type": "string"
+          },
+          "priority_fee": {
+            "type": "number"
+          },
+          "slot_id": {
+            "type": "string"
+          },
+          "start_at": {
+            "type": "string"
+          },
+          "time": {
+            "type": "string"
+          },
+          "total": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "success": {
+      "description": "true = operation done / data returned; false = see error",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the read-only/no-destruction profile, and the description adds genuinely new behavior: no side effects, slot_id validity of ~15 minutes, the full error taxonomy (no_availability, date_in_past, date_out_of_range) and the instruction never to invent a slot. This is rich context beyond structured fields.

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?

Labelled sections (PURPOSE/WHEN TO USE/WHEN NOT TO USE/REQUIRED/SIDE EFFECTS/RESULT) front-load the decision-relevant information and every sentence carries operational content. Dense but zero waste for a tool with this much branching logic.

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?

Covers the request modes, required inputs, side effects, success and failure shapes, and the ordering constraint relative to calculate_quote. With an output schema present, the description correctly focuses on routing and error semantics rather than restating return fields.

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 100% so the baseline is 3, but the description adds meaning the schema does not: how wanted.type selects behavior (asap/date/range/preferred) and the fallback when type is omitted (date->date, from/to->range, nothing->asap), plus the customer_grant requirement for rescheduling. It stops short of documenting preferred_time ordering semantics.

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+resource (returns real, currently free appointment slots) and distinguishes the two calling modes by quote_id (new booking) vs booking_reference (reschedule). An agent can tell it apart from create_booking/reschedule_booking without opening a 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?

Explicit WHEN TO USE (after calculate_quote, when the customer asks when we can come) and WHEN NOT TO USE (never to book - reserves nothing), plus the sequencing relative to a named sibling. Nothing is left to inference.

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