PriceWin

Request a Booking (hotel confirms, pay at the hotel)

request_booking

Sends a booking request for a room at an OpenTravel partner hotel. Nothing is charged and no room is held: the hotel confirms the request by email, and the guest pays at the property on arrival. There is no payment step, now or later. Takes the room and rate from get_hotel_detail and the guest's name, phone number and email; when any of these is missing, the result asks for it and, in clients that show widgets, opens a form for it. One request covers several rooms of the same room type (roomCount), with adults and children counted across all of them; each call is a separate request with its own code, so rooms of one type booked call by call reach the hotel as unrelated requests. Returns one confirmation code for the whole request.

Input Schema

Name	Required	Description
`adults`	Yes	Number of adults across ALL rooms of the request — at least one per room
`checkIn`	Yes	Check-in date YYYY-MM-DD. Must be today or later.
`checkOut`	Yes	Check-out date YYYY-MM-DD. Must be after checkIn.
`children`	No	Number of children across ALL rooms of the request (default 0)
`currency`	Yes	Currency of totalAmount, as quoted by get_hotel_detail for the chosen room.
`language`	No	Optional response language hint. Only used when queryText gives no signal.
`guestName`	No	Full name of the primary guest. When omitted, the result asks the user for it.
`queryText`	No	Short excerpt (one sentence at most) of the guest's latest message in their own words, used only to detect the reply language; it is not stored or forwarded. It carries no names, contact details or other parts of the conversation.
`roomCount`	No	How many rooms of this room type the guest wants (default 1). All of them go in this one request, under one confirmation code.
`guestEmail`	No	Email address the confirmation is sent to, as the guest gave it; it cannot be changed after the request is sent. When omitted, the result asks the user for it.
`guestPhone`	No	Guest phone number; the hotel calls it to confirm the request. When omitted, the result asks the user for it.
`propertyId`	Yes	OpenTravel propertyId from get_hotel_detail
`roomTypeId`	Yes	roomTypeId from get_hotel_detail roomTypes array
`totalAmount`	Yes	Total amount for ALL rooms in the property's base currency: the room's price for the stay × roomCount

Output Schema

Name	Required	Description	Default
`status`	Yes
`nextStep`	Yes
`bookingId`	Yes
`roomCount`	Yes
`quotedAmount`	Yes
`assignedRoomId`	Yes
`quotedCurrency`	Yes
`paymentRequired`	Yes
`confirmationCode`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 7, 2026

changedInput schema / properties / adults / description

Previous value: -"Number of adults"New value: +"Number of adults across ALL rooms of the request — at least one per room"

changedInput schema / properties / children / description

Previous value: -"Number of children (default 0)"New value: +"Number of children across ALL rooms of the request (default 0)"

addedInput schema / properties / roomCount

Added value: +{
+  "default": 1,
+  "description": "How many rooms of this room type the guest wants (default 1). All of them go in this one request, under one confirmation code.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / totalAmount / description

Previous value: -"Total amount in the property's base currency"New value: +"Total amount for ALL rooms in the property's base currency: the room's price for the stay × roomCount"

addedOutput schema / properties / roomCount
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / required

Previous value: -[
-  "bookingId",
-  "confirmationCode",
-  "status",
-  "paymentRequired",
-  "nextStep",
-  "assignedRoomId",
-  "quotedAmount",
-  "quotedCurrency"
-]New value: +[
+  "bookingId",
+  "confirmationCode",
+  "status",
+  "paymentRequired",
+  "nextStep",
+  "assignedRoomId",
+  "roomCount",
+  "quotedAmount",
+  "quotedCurrency"
+]

Changed1 schema field changedOct 6, 2026
- addedInput schema / properties / propertyId / format
```
Added value: +"uuid"
```
First observedOct 3, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Far exceeds the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). It discloses the no-charge/no-hold model, that the hotel confirms by email and the guest pays at check-in, that there is no payment step ever, how missing guest fields are prompted (including widget forms), and that email cannot be changed once sent.

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?

Front-loads the most decision-relevant fact (request only, nothing charged, pay at hotel) before mechanics. It is dense and every sentence carries information, though the multi-sentence run-on about call-by-call requests is close to over-explaining.

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 14-parameter, 7-required mutation-ish tool with an output schema present, it covers the missing pieces: charge/confirmation model, dependency on get_hotel_detail, guest-field fallback behavior, and multi-room semantics. Return values are (correctly) left to the output schema aside from noting the single confirmation code.

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 parameters are already well documented; baseline is 3. The description adds useful grouping context (roomCount covers several rooms under one code, adults/children counted across all rooms) but largely restates semantics the schema already carries.

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 ("Sends a booking request for a room at an OpenTravel partner hotel") and immediately frames the transactional model (no charge, hotel confirms, pay on arrival). It names get_hotel_detail as the source of the room/rate, distinguishing it from sibling read/lookup tools and from cancel_booking.

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?

Explains the upstream dependency (take room and rate from get_hotel_detail) and the preconditions for guest fields, and warns that call-by-call bookings of the same room type arrive as unrelated requests. It does not explicitly state when NOT to use it or name the alternative for guest-detail gathering, leaving a small gap.

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

All PriceWin 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?