1stay

Resend Confirmation

resend_confirmation

Resend a hotel reservation confirmation email. Use either the confirmation number from a successful lookup_booking call, or the guest's full name and email address when they do not know their confirmation number, card last four, or check-in date. The email contains the hotel confirmation number the guest can then use with lookup_booking or cancel_booking. Recovery requests never reveal whether a reservation matched. The confirmation is sent only to the email address already on the booking record; there is no recipient override. Email changes are handled at https://stayker.com/service.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	No	Guest email address. Used only to find a match; confirmation is sent only to the email address already on file.
`last_name`	No	Guest last name. Required with first_name and email when the confirmation number is unavailable.
`first_name`	No	Guest first name. Required with last_name and email when the confirmation number is unavailable.
`confirmation_number`	No	Hotel confirmation number. Use this after a verified lookup.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`message`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 19, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / email / pattern

Added value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed4 schema fields changedAug 25, 2026

changedInput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / email / pattern

Removed value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedOutput schema / $schema

Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"

Changed4 schema fields changedAug 24, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / email / pattern

Added value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed5 schema fields changedAug 18, 2026

changedInput schema / properties / confirmation_number / description

Previous value: -"Hotel confirmation number"New value: +"Hotel confirmation number. Use this after a verified lookup."

addedInput schema / properties / email

Added value: +{
+  "description": "Guest email address. Used only to find a match; confirmation is sent only to the email address already on file.",
+  "format": "email",
+  "type": "string"
+}

addedInput schema / properties / first_name

Added value: +{
+  "description": "Guest first name. Required with last_name and email when the confirmation number is unavailable.",
+  "type": "string"
+}

addedInput schema / properties / last_name

Added value: +{
+  "description": "Guest last name. Required with first_name and email when the confirmation number is unavailable.",
+  "type": "string"
+}

removedInput schema / required

Removed value: -[
-  "confirmation_number"
-]

Changed1 schema field changedAug 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "message"
+  ],
+  "type": "object"
+}

Changed1 schema field changedAug 3, 2026

removedInput schema / properties / updated_email

Removed value: -{
-  "description": "If provided, send confirmation to this email instead of the one on file. Use when guest typo'd their email at booking or can't access the original email.",
-  "type": "string"
-}

AddedMay 26, 2026
RemovedApr 6, 2026
AddedApr 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=false, but the description adds substantial behavioral context: recovery requests never reveal whether a reservation matched, the confirmation is sent only to the already-on-file email with no recipient override, and email changes are handled at a specific URL. These details go beyond the annotations and meaningfully inform the agent about side effects and privacy constraints. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is a focused paragraph that front-loads the core action, then covers parameter selection and key behavioral notes. It is concise and every sentence contributes useful information. It could be slightly tightened, but it remains well-structured and efficient.

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?

Given 4 optional parameters, the presence of an output schema, and annotations, the description fully covers what an agent needs to invoke the tool correctly: when to use it, how to choose parameters, privacy/security behavior, and where to direct email changes. Nothing essential 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 100%, so each parameter is already well-documented in the schema. The description restates the choice between confirmation_number and first_name/last_name/email, and adds the nuance that email is used only to find a match and that the confirmation goes to the on-file address. However, this is largely redundant with the schema descriptions, so the description adds marginal value beyond the schema.

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?

The description states a specific verb and resource: resend a hotel reservation confirmation email. It distinguishes itself from sibling tools by referencing lookup_booking as the source of a valid confirmation number and positioning itself in the booking workflow. It is immediately clear what this tool does and how it differs from lookup, cancel, or book operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

The description gives explicit conditions for parameter usage: use confirmation_number from a successful lookup_booking call, or use first_name, last_name, and email when the guest lacks the confirmation number, card last four, or check-in date. It also notes that the confirmation is sent only to the on-file email and directs email changes to an external URL. While it does not explicitly name when not to use this tool relative to siblings, the guidance is specific and actionable.

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

All 1stay 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.

Resend Confirmation

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources