SzuruSzuru – rezerwacja czyszczenia tapicerki

Wyślij kod ponownie

resend_confirmation_code

PURPOSE: Re-sends the SMS code of a prepared booking. WHEN TO USE: Only when the customer says the SMS from prepare_booking did not arrive. WHEN NOT TO USE: Not after a wrong code (ask the customer to re-type it) and not to start a new booking. REQUIRED: confirmation_id. SIDE EFFECTS: sends one SMS (max 1 per minute, 3 per 30 minutes per phone; otherwise error rate_limited with retry_after).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.
`confirmation_id`	Yes	confirmation_id from prepare_booking

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
`message`	No
`success`	Yes	true = operation done / data returned; false = see error
`expires_at`	No
`session_id`	No
`code_sent_to`	No
`missing_fields`	No
`confirmation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedInput schema / properties / confirmation_id / description
```
Added value: +"confirmation_id from prepare_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."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "code": {
+      "type": "string"
+    },
+    "code_sent_to": {
+      "type": "string"
+    },
+    "confirmation_id": {
+      "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"
+    },
+    "success": {
+      "description": "true = operation done / data returned; false = see error",
+      "type": "boolean"
+    }
+  },
+  "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 only declare non-read-only, non-idempotent, non-destructive; the description goes further by disclosing side effects (sends exactly one SMS), concrete rate limits (1/min, 3 per 30 min per phone), and the exact error and recovery field (rate_limited with retry_after). That is behavior an agent must know before calling.

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 NOT TO USE / REQUIRED / SIDE EFFECTS) front-load the routing decision and compress rate-limit detail into one line. Every sentence carries operational weight.

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?

An output schema exists, so return values need not be explained. The description covers the remaining agent-facing gaps: correct trigger conditions, exclusions, required input, and failure/backoff behavior.

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 both parameters are fully documented in the schema itself. The description only restates that confirmation_id is required and cites its source, adding little beyond the structured field, so 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 precise verb+resource: re-sending the SMS code of a prepared booking. This clearly separates it from prepare_booking (initial send) and verify_phone_code (code entry), so an agent can route correctly without opening the 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 (SMS from prepare_booking did not arrive) and WHEN NOT TO USE (not after a wrong code, not to start a new booking), with the corrective action spelled out for the wrong-code case. No inference required.

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?