viajante

Overview Schema Source Related Servers Discussions Admin

Hotel room rates

search_hotel_rooms

Read-onlyIdempotent

Find Skiplagged hotel room rates for finalist stays by hotel ID or exact hotel name and city. Compare total USD prices and room types for your dates before booking.

Instructions

Room rates for one Skiplagged hotel, for 1-3 finalists. Name it by hotel_id (the provider_id of a skiplagged search_hotels offer) or by hotel_name plus city. A name must match exactly (case, accents and punctuation ignored); no match or several matches is no_results, never a guess. Use the name form for a Google finalist: a Google hostel price can be a dorm bed, and these rates say what the room is. Rates are USD, not converted, in provider order. total_price is the whole stay for the party and rooms searched. occupancy_limit is per room type and is not proof that a party fits across rooms. Skiplagged only: do not mix these rows with Google or Booking prices.

Input Schema

Name	Required	Description	Default
`city`	No
`rooms`	No
`adults`	No
`check_in`	Yes
`hotel_id`	No
`check_out`	Yes
`hotel_name`	No

Output Schema

Name	Required	Description	Default
`status`	Yes
`empty_note`	Yes
`error_code`	Yes
`observed_at`	Yes
`retry_after`	Yes
`completeness`	Yes
`empty_reason`	Yes
`observed_at_basis`	Yes
`retry_after_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.5.2Oct 19, 2026

removedInput schema / properties / adults / title
```
Removed value: -"Adults"
```
removedInput schema / properties / check_in / title
```
Removed value: -"Check In"
```
removedInput schema / properties / check_out / title
```
Removed value: -"Check Out"
```
removedInput schema / properties / city / title
```
Removed value: -"City"
```
removedInput schema / properties / hotel_id / title
```
Removed value: -"Hotel Id"
```
removedInput schema / properties / hotel_name / title
```
Removed value: -"Hotel Name"
```
removedInput schema / properties / rooms / title
```
Removed value: -"Rooms"
```

removedInput schema / title

Removed value: -"search_hotel_roomsArguments"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "completeness": {
+      "enum": [
+        "complete",
+        "partial",
+        "blocked"
+      ],
+      "type": "string"
+    },
+    "empty_note": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "empty_reason": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider_empty",
+            "filtered_out",
+            "not_loaded"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "error_code": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "observed_at_basis": {
+      "anyOf": [
+        {
+          "enum": [
+            "provider",
+            "fetch"
+          ],
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "retry_after_seconds": {
+      "anyOf": [
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "status": {
+      "enum": [
+        "ok",
+        "no_results",
+        "rate_limited",
+        "blocked",
+        "timeout",
+        "failed"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "completeness",
+    "empty_reason",
+    "empty_note",
+    "error_code",
+    "retry_after",
+    "retry_after_seconds",
+    "observed_at",
+    "observed_at_basis"
+  ],
+  "type": "object"
+}

Addedv1.4.1Oct 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond them: exact name matching with case/accents/punctuation ignored, ambiguous or absent matches return no_results rather than a guess, prices are unconverted USD in provider order. These are exactly the operational traits an agent cannot infer from the annotations.

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 core statement ('Room rates for one Skiplagged hotel, for 1-3 finalists') and every subsequent sentence carries distinct information (matching rules, provider exclusivity, price semantics). It is dense and some clauses are run-on, but there is little padding to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a rate-lookup tool with an output schema, the description covers the high-risk gotchas: provider mixing, the occupancy_limit-per-room-type caveat, total_price scope, and currency. The remaining gap is that it never clarifies the date parameter formats or the rooms/adults defaults for a 7-param tool, so it falls just short of fully complete.

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 0%, so the description carries the full parameter burden. It does explain hotel_id (provider_id from a skiplagged search_hotels offer), the hotel_name+city pairing, and exact-match semantics, and touches rooms/adults indirectly via 'the party and rooms searched'. However check_in/check_out and the city parameter are never defined, leaving several parameters undocumented in both places.

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 (room rates) scoped to exactly one Skiplagged hotel, and explicitly links its input to 'the provider_id of a skiplagged search_hotels offer', which cleanly separates it from the sibling search_hotels and get_hotel_details. An agent can tell what this returns (rate rows for a single hotel) 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?

Gives concrete when-to-use conditions: intended 'for 1-3 finalists', and the hotel_name form should be used 'for a Google finalist' because Google hostel prices may be dorm beds. It also states an explicit exclusion ('Skiplagged only: do not mix these rows with Google or Booking prices'), so both selection and non-selection are covered.

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