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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "propertyId": "<propertyId>",
      "checkIn": "<checkIn>",
      "checkOut": "<checkOut>",
      "roomTypeId": "<roomTypeId>",
      "adults": "<adults>",
      "totalAmount": "<totalAmount>",
      "currency": "<currency>"
    },
    "name": "request_booking"
  }
}

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.
`quoteId`	No	Server-issued quote identifier for the selected room, dates and party, from get_hotel_detail. Valid for ten minutes.
`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
`confirmedByUser`	No	Explicit guest confirmation of the exact room, dates, party, contact details and total.

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.

Changed2 schema fields changedOct 27, 2026

addedInput schema / properties / confirmedByUser

Added value: +{
+  "description": "Explicit guest confirmation of the exact room, dates, party, contact details and total.",
+  "type": "boolean"
+}

addedInput schema / properties / quoteId

Added value: +{
+  "description": "Server-issued quote identifier for the selected room, dates and party, from get_hotel_detail. Valid for ten minutes.",
+  "format": "uuid",
+  "type": "string"
+}

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.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false/destructiveHint=false; the description adds the crucial behavioral facts an agent cannot infer: no payment step ever, no inventory hold, hotel confirmation arrives by email, one code per request, and that separate calls reach the hotel as unrelated requests. It also discloses what happens when identity fields are missing (result asks for them / widget opens a form).

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-loaded with the most decision-relevant fact (request, not reservation) in the first two sentences, then caller obligations, then the multi-room caveat. Slightly long, and the sentence about missing name/phone/email restates what the schema already says for each field.

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 16-parameter mutating tool with annotations and an output schema, the description covers the decisive items: no financial risk, no hold, source of inputs, multi-room semantics, and return value (one confirmation code). Follow-up/cancellation paths are the only notable omission and are discoverable via siblings (check_booking_status, cancel_booking).

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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining roomCount aggregation across adults/children and the consequence of splitting room bookings across calls. It does not explain quoteId expiry or confirmedByUser, which the schema carries alone.

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') and immediately disambiguates from a real reservation: nothing charged, no room held, hotel confirms by email, guest pays on arrival. An agent can tell this apart from any confirm/pay tool 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 Guidelines4/5

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

Explicitly says the room and rate come from get_hotel_detail, and warns that booking a room type call-by-call produces unrelated requests at the hotel — actionable when-to/why-not guidance. It does not name sibling tools for follow-up (check_booking_status, cancel_booking) or state preconditions like the 10-minute quote validity, so it stops short of full alternative routing.

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?