trip1

Purchase Hotel

purchase_hotel

Destructive

Book a hotel room in chat, by providing guest details and a rate ID from get_hotel_details. Use start_checkout instead, which opens a booking form; call this only when the user says they cannot see or use that form. Creates a guest profile, adds the room to a cart, and initiates checkout. Ask the user how they want to pay before calling, and pass it as payment_service: 'x402' (USDC on Base, paid by an x402 payments tool you have) or 'coingate' (a checkout page the user pays in their browser, any crypto). If you have no x402 payments tool, use coingate. Returns a payment_url and the cart_url where the order can also be paid in a browser. The booking is confirmed once payment settles; poll get_order_details to check status.

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": {
      "rate_id": "<rate_id>",
      "first_name": "<first_name>",
      "last_name": "<last_name>",
      "email": "<email>",
      "phone": "<phone>"
    },
    "name": "purchase_hotel"
  }
}

Input Schema

Name	Required	Description
`email`	Yes	Guest's email address
`phone`	Yes	Guest's phone number (e.g., +44123456789)
`title`	No	Guest's title: MR, MRS, MS, or MISS (default: MR)
`context`	No	Why are you calling this tool? Describe the user's underlying goal in one short sentence — not the tool name. Never include names, emails, phones, or prices. Always pass this. Used for analytics only; never shown to the user.
`rate_id`	Yes	Signed rate ID from get_hotel_details response
`last_name`	Yes	Guest's last name
`first_name`	Yes	Guest's first name
`nationality`	No	Guest's nationality as ISO 3166-1 alpha-2 code (default: GB)
`price_currency`	No	Payment currency (default: USD for x402, EUR for coingate). Supported: EUR, USD, GBP, PLN, CZK, HUF, SEK, NOK, DKK
`payment_service`	No	Payment method the user chose: x402 (USDC on Base, needs an x402 payments tool; default) or coingate (browser checkout, any crypto)

Output Schema

Name	Required	Description
`cart_id`	Yes	Pass to get_order_details to poll the booking
`message`	Yes	How to complete payment for the chosen payment_service
`cart_url`	Yes	The order on trip1, where it can also be paid in a browser
`payment_url`	Yes
`booking_reference`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

changedInput schema / properties / payment_service / description

Previous value: -"Payment method: x402 (USDC on Base, default) or coingate (browser-based crypto)"New value: +"Payment method the user chose: x402 (USDC on Base, needs an x402 payments tool; default) or coingate (browser checkout, any crypto)"

addedOutput schema / properties / cart_url

Added value: +{
+  "description": "The order on trip1, where it can also be paid in a browser",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "cart_id",
-  "booking_reference",
-  "payment_url",
-  "message"
-]New value: +[
+  "cart_id",
+  "booking_reference",
+  "payment_url",
+  "cart_url",
+  "message"
+]

Changed2 schema fields changedSep 22, 2026

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedSep 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "booking_reference": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "cart_id": {
+      "description": "Pass to get_order_details to poll the booking",
+      "type": "string"
+    },
+    "message": {
+      "description": "How to complete payment for the chosen payment_service",
+      "type": "string"
+    },
+    "payment_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "cart_id",
+    "booking_reference",
+    "payment_url",
+    "message"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedAug 21, 2026

changedInput schema / properties / context / description

Previous value: -"One short sentence on what you are trying to accomplish for the user with this call. Used for analytics only; never shown to the user."New value: +"Why are you calling this tool? Describe the user's underlying goal in one short sentence — not the tool name. Never include names, emails, phones, or prices. Always pass this. Used for analytics only; never shown to the user."

addedInput schema / properties / context / maxLength
```
Added value: +200
```

Changed1 schema field changedAug 6, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedAug 3, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "One short sentence on what you are trying to accomplish for the user with this call. Used for analytics only; never shown to the user.",
+  "type": "string"
+}

First observedApr 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations establish a non-read-only, destructive, open-world, non-idempotent write, but the description goes well past them: it discloses the internal sequence (creates guest profile, adds room to cart, initiates checkout), the confirmation condition (payment must settle), and the follow-up action (poll get_order_details). That is behavior beyond what the annotations convey.

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 routing rule and side effects are front-loaded, and most sentences carry decision-relevant facts. It runs long, and the payment explanation repeats a fair amount of what the schema's payment_service description already says.

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 multi-step purchase flow with an output schema, the description supplies everything the agent needs: prerequisites (rate ID source), the ask-the-user step, the payment branch, what the returned URLs mean, and how confirmation is determined.

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 genuine selection logic for payment_service (when each enum applies, what tooling each requires, the default) that the schema only restates. It does not add comparable depth for rate_id, context, or currency beyond what the schema already documents.

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 (book a hotel room) plus the required inputs (guest details, rate ID from get_hotel_details), and explicitly separates itself from the sibling start_checkout. An agent can route between this and start_checkout without opening either 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?

Gives an explicit negative condition: use start_checkout, which opens a form, and call this only when the user says they cannot see or use that form. It also spells out the decision rule for payment_service and the fallback when no x402 payments tool exists.

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

All trip1 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.